feat: Implement permission trie for RBAC authorization optimization

[husenkuresh1]

This PR implements a permission trie structure to replace the nested loop-based RBAC authorization system, reducing authorization time.

Fixes Issue

Closes #58

Changes proposed

• Created permissiontrie.go with new hierarchical permission structure
• Updated authorizer.go with the new RBAC implementation
• Enhanced clustermanager.go for permission checking integration
• Removed legacy authorizer from cluster.go
• Added comprehensive tests in authorizer_test.go and permissiontrie_test.go

Backward Compatibility

• Maintains existing API interfaces
• Supports all existing RBAC configurations
• No breaking changes to external APIs
• Preserves all functionality while improving performance

Check List (Check all the applicable boxes)

• My code follows the code style of this project.
• My change requires changes to the documentation.
• I have updated the documentation accordingly.
• All new and existing tests passed.
• This PR does not contain plagiarized content.
• The title of my pull request is a short description of the requested changes.

Screenshots

Note to reviewers

[deltasquare4]

I do not understand how this is a Trie. Can you please explain what happens here? Thanks.

[husenkuresh1]

The PermissionTrie acts as a high-speed index for RBAC rules. Understood it as a hierarchical lookup tree where each level represents a different dimension of a Kubernetes permission. It uses the core principle of a trie: a path through the structure represents a key. In this case, the "key" is the combination of Subject, Cluster, Namespace, APIGroup, and Resource. This avoids re-evaluating a long list of rules for every single API request.

How It Works

Storing Permissions

When an RBAC rule is loaded, we create a path in the tree to represent it. Let's say we add a permission for user "bob" to "delete" "pods" in the "dev" namespace on cluster "production":

1. Subject Level: Find/create the node for User: "bob".
2. Cluster Level: Find/create the node for Cluster: "production".
3. Namespace Level: Find/create the node for Namespace: "dev".
4. API Group Level: Find/create the node for API group "" (the core API).
5. Resource Level: Find/create the final node for Resource: "pods".
6. Store Verb: At this final node, we update a bitmask to add the delete permission.

Checking Permissions

When checking if user "bob" can "delete" a pod in the "dev" namespace:

1. Traversal: The code rapidly traverses the tree following the request's attributes: User: "bob" -> Cluster: "production" -> Namespace: "dev" -> API Group: "" -> Resource: "pods".
2. Check: At the final node, it checks if the delete verb is present in the permission bitmask. In this case, it is. ✅ Access Granted.

If no rule were found for the "dev" namespace, the lookup would automatically fall back and check again using the cluster-wide namespace ("") to see if permission was granted or not.

Example Tree Structure

Here is a visual representation with annotations explaining what each path represents.

     PermissionTrie
     ├── User:alice (SubjectNode)
     │   └── cluster1 (ClusterNode)
     │       ├── "" (NamespaceNode) // Cluster-wide rule
     │       │   └── apps (APIGroupNode)
     │       │       └── deployments (ResourceNode)
     │       │           └── verbs: [get, list]
     │       └── default (NamespaceNode) // Namespace-specific rule from a Role
     │           └── "" (APIGroupNode - core API)
     │               └── pods (ResourceNode)
     │                   └── verbs: [get, list, watch]
     │
     └── Group:dev-team (SubjectNode)
         └── cluster1 (ClusterNode)
             └── * (URLNode) // Non-resource URL rule (e.g., for /healthz)
                 └── verbs: [get]