Review comments addressed

Signed-off-by: jyejare <jyejare@redhat.com>
feast-dev · franciscojavierarceo · Oct 10, 2025 · Sep 16, 2025 · Sep 18, 2025 · Oct 7, 2025
commit fa12ca7f5bf4a724de381507e515afc1946280a3
@@ -18,6 +18,6 @@ typically your Offline Store). We are exploring adding a default streaming engin
 
 * We recommend [using Python](language.md) for your Feature Store microservice. As mentioned in the document, precomputing features is the recommended optimal path to ensure low latency performance. Reducing feature serving to a lightweight database lookup is the ideal pattern, which means the marginal overhead of Python should be tolerable. Because of this we believe the pros of Python outweigh the costs, as reimplementing feature logic is undesirable. Java and Go Clients are also available for online feature retrieval.
 
-* [Role-Based Access Control (RBAC)](rbac.md) is a security mechanism that restricts access to resources based on the roles of individual users within an organization. In the context of the Feast, RBAC ensures that only authorized users or groups can access or modify specific resources, thereby maintaining data security and operational integrity.
+* [Role-Based Access Control (RBAC)](rbac.md) is a security mechanism that restricts access to resources based on the roles/groups/namespaces of individual users within an organization. In the context of the Feast, RBAC ensures that only authorized users or groups can access or modify specific resources, thereby maintaining data security and operational integrity.
 
 
@@ -99,7 +99,7 @@ auth:
 
 ### Kubernetes RBAC Authorization
 With Kubernetes RBAC Authorization, the client uses the service account token as the authorizarion bearer token, and the
-server fetches the associated roles/groups/namespaces from the Kubernetes RBAC resources.
+server fetches the associated roles from the Kubernetes RBAC resources. Feast supports advanced authorization by extracting user groups and namespaces from Kubernetes tokens, enabling fine-grained access control beyond simple role matching. This is achieved by leveraging Kubernetes Token Access Review, which allows Feast to determine the groups and namespaces associated with a user or service account.
 
 An example of Kubernetes RBAC authorization configuration is the following: 
 {% hint style="info" %}
@@ -109,26 +109,12 @@ An example of Kubernetes RBAC authorization configuration is the following:
 project: my-project
 auth:
   type: kubernetes
+  user_token: <user_token> #Optional, else service account token Or env var is used for getting the token
 ...
 ```
 
 In case the client cannot run on the same cluster as the servers, the client token can be injected using the `LOCAL_K8S_TOKEN` 
 environment variable on the client side. The value must refer to the token of a service account created on the servers cluster
 and linked to the desired RBAC roles/groups/namespaces.
 
-#### Setting Up Kubernetes RBAC for Feast
-
-To ensure the Kubernetes RBAC environment aligns with Feast's RBAC configuration, follow these guidelines:
-* The roles defined in Feast `Permission` instances must have corresponding Kubernetes RBAC `Role` names.
-* The Kubernetes RBAC `Role` must reside in the same namespace as the Feast service.
-* The client application can run in a different namespace, using its own dedicated `ServiceAccount`.
-* Finally, the `RoleBinding` that links the client `ServiceAccount` to the RBAC `Role` must be defined in the namespace of the Feast service.
-
-#### Kubernetes RBAC Authorization with Groups and Namespaces
-
-Feast supports advanced authorization by extracting user groups and namespaces from Kubernetes tokens, enabling fine-grained access control beyond simple role matching. This is achieved by leveraging Kubernetes Token Access Review, which allows Feast to determine the groups and namespaces associated with a user or service account.
-
-More details can be found in [Groups and Namespaces based Auth](../../reference/auth/groups_namespaces_auth.md)
-
-
-If the above rules are satisfied, the Feast service must be  granted permissions to fetch `RoleBinding` instances from the local namespace.
+More details can be found in [Setting up kubernetes doc](../../reference/auth/kubernetes_auth_setup.md)
@@ -101,6 +101,15 @@ Permission(
 )
 ```
 
+## Permission granting order
+
+When mixing and matching policies in permissions script, the permission granting order is as follows:
+
+1. The first matching policy wins in the list of policies and the permission is granted based on the matching policy rules and rest policies are ignored.
+2. If any policy matches from the list of policies, the permission is granted based on the matching policy rules and rest policies are ignored
+3. If no policy matches, the permission is denied
+
+
 ## Authorization configuration
 In order to leverage the permission functionality, the `auth` section is needed in the `feature_store.yaml` configuration.
 Currently, Feast supports OIDC and Kubernetes RBAC authorization protocols.

@@ -1,34 +1,47 @@
-# Groups and Namespaces Authentication Support
+# Setting up the kubernetes Auth
 
-This document describes the enhanced authentication and authorization capabilities in Feast that support groups and namespaces extraction from Kubernetes tokens, extending the existing role-based access control (RBAC) system.
+This document describes the authentication and authorization capabilities in Feast that support groups, namespaces and roles extraction from Kubernetes tokens.
 
 ## Overview
 
-Feast now supports extracting user groups and namespaces of both Service Account and User from Kubernetes authentication tokens using Token Access Review, in addition to the existing role-based authentication. This allows for more granular access control based on:
+Feast supports extracting user groups, namespaces and roles of both Service Account and User from Kubernetes authentication tokens. This allows for more granular access control based on:
 
 - **Groups**: User groups associated directly with User/SA and from associated namespace 
 - **Namespaces**: Kubernetes namespaces associated with User/SA
+- **Roles**: Kubernetes roles associated with User/SA
 
 ## Key Features
 
-### 1. Token Access Review Integration
+### Setting Up Kubernetes RBAC for Feast
 
-The system now uses Kubernetes Token Access Review API to extract detailed user information from tokens, including:
-- User groups
-- Associated namespaces
-- User identity information
+#### Role based auth setup
 
-### 2. Enhanced User Model
+To ensure the Kubernetes RBAC environment aligns with Feast's RBAC configuration, follow these guidelines:
+* The roles defined in Feast `Permission` instances must have corresponding Kubernetes RBAC `Role` names. 
+* The Kubernetes RBAC `Role` must reside in the same namespace as the Feast service.
+* The client application can run in a different namespace, using its own dedicated `ServiceAccount`.
+* Finally, the `RoleBinding` that links the client `ServiceAccount` to the RBAC `Role` must be defined in the namespace of the Feast service.
 
-The `User` class has been extended along with roles to include:
-- `groups`: List of user groups
-- `namespaces`: List of associated namespaces
+#### Group and Namespace based auth setup
 
-### 3. New Policy Types
+To ensure the Kubernetes RBAC environment aligns with Feast's RBAC configuration, follow these guidelines:
+* The groups and namespaces defined in Feast `Permission` instances must have corresponding Kubernetes `Group` and `Namespace` names.
+* The user or service account must reside in the group or namespace defined in the Feast `Permission` instances.
+* The client application can run in a different namespace, using its own dedicated `ServiceAccount` or user.
+* Finally, the feast service grants access based on the group and namespace association defined in the Feast `Permission` instances.
 
-Three new policy types have been introduced:
+## Policy Types
 
-#### GroupBasedPolicy
+### RoleBasedPolicy
+Grants access based on user role membership.
+
+```python
+from feast.permissions.policy import RoleBasedPolicy
+
+policy = RoleBasedPolicy(roles=["data-team", "ml-engineers"])
+```
+
+### GroupBasedPolicy
 Grants access based on user group membership.
 
 ```python
@@ -47,7 +60,7 @@ policy = NamespaceBasedPolicy(namespaces=["production", "staging"])
 ```
 
 #### CombinedGroupNamespacePolicy
-Grants access only when user is added into either permitted groups AND namespaces.
+Grants access only when user is added into either permitted groups OR namespaces.
 
 ```python
 from feast.permissions.policy import CombinedGroupNamespacePolicy
@@ -62,13 +75,12 @@ policy = CombinedGroupNamespacePolicy(
 
 ### Server Configuration
 
-The server automatically extracts groups and namespaces when using Kubernetes authentication. No additional configuration is required beyond the existing Kubernetes auth setup.
+The server automatically extracts groups, namespaces and roles when using Kubernetes authentication. No additional configuration is required beyond the existing Kubernetes auth setup.
 
 ### Client Configuration
 
 For external users (not service accounts), you can provide a user token in the configuration:
 
-
 Refer examples of providing the token are described in doc [User Token Provisioning](./user_token_provisioning.md)
 
 ## Usage Examples
@@ -80,11 +92,20 @@ from feast.feast_object import ALL_RESOURCE_TYPES
 from feast.permissions.action import READ, AuthzedAction, ALL_ACTIONS
 from feast.permissions.permission import Permission
 from feast.permissions.policy import (
+    RoleBasedPolicy,
     GroupBasedPolicy,
     NamespaceBasedPolicy,
     CombinedGroupNamespacePolicy
 )
 
+# Role-based permission
+role_perm = Permission(
+    name="role_permission",
+    types=ALL_RESOURCE_TYPES,
+    policy=RoleBasedPolicy(roles=["reader-role"]),
+    actions=[AuthzedAction.DESCRIBE] + READ
+)
+
 # Group-based permission (new)
 data_team_perm = Permission(
     name="data_team_permission",
@@ -117,14 +138,6 @@ dev_staging_perm = Permission(
 
 Run `feast apply` from CLI/API/SDK on server or from client(if permitted) to apply the permissions.
 
-## Token Access Review Process
-
-1. **Token Extraction**: The system extracts the authentication token from the request
-2. **Token Validation**: Uses Kubernetes Token Access Review API to validate the token
-3. **Information Extraction**: Extracts groups, namespaces, and user information
-4. **User Creation**: Creates a User object with roles, groups, and namespaces
-5. **Policy Evaluation**: Evaluates permissions against the user's attributes
-
 ## Troubleshooting
 
 ### Common Issues
@@ -139,7 +152,7 @@ Run `feast apply` from CLI/API/SDK on server or from client(if permitted) to app
    - Check that the user is properly configured in Kubernetes/ODH/RHOAI
 
 3. **Permission Denied**
-   - Verify the user is added to required groups/namespaces
+   - Verify the user is added to required groups/namespaces Or has the required role assigned
    - Check that the policy is correctly configured
    - Review the permission evaluation logs
 
@@ -167,6 +180,3 @@ Run `feast apply` from CLI/API/SDK on server or from client(if permitted) to app
 - [Permission Model](../concepts/permission.md)
 - [RBAC Architecture](../architecture/rbac.md)
 - [Kubernetes RBAC Authorization](./authz_manager.md#kubernetes-rbac-authorization)
-
-
-
@@ -91,9 +91,9 @@ async def user_details_from_access_token(self, access_token: str) -> User:
 
             logger.info(f"Request received from User: {username}")
 
-            # For user tokens, we don't have traditional roles, but we have groups and namespaces
-            # You might want to map groups to roles or use a different role assignment strategy
-            roles = []  # Users don't have traditional service account roles
+            # Extract roles for the user from RoleBindings and ClusterRoleBindings
+            logger.info(f"Extracting roles for user {username} with groups: {groups}")
+            roles = self.get_user_roles(username, groups)
 
             return User(
                 username=username, roles=roles, groups=groups, namespaces=namespaces
@@ -136,6 +136,53 @@ def get_roles(
 
         return list(roles)
 
+    def get_user_roles(self, username: str, groups: list[str]) -> list[str]:
+        """
+        Fetches the Kubernetes `Role`s and `ClusterRole`s associated to the given user and their groups.
+
+        This method checks both namespaced RoleBindings and ClusterRoleBindings for:
+        - Direct user assignments
+        - Group-based assignments where the user is a member
+
+        Returns:
+            list[str]: Names of the `Role`s and `ClusterRole`s associated to the user.
+        """
+        roles: set[str] = set()
+
+        try:
+            # Get all namespaced RoleBindings across all namespaces
+            all_role_bindings = self.rbac_v1.list_role_binding_for_all_namespaces()
+
+            for binding in all_role_bindings.items:
+                if binding.subjects is not None:
+                    for subject in binding.subjects:
+                        # Check for direct user assignment
+                        if subject.kind == "User" and subject.name == username:
+                            roles.add(binding.role_ref.name)
+                        # Check for group-based assignment
+                        elif subject.kind == "Group" and subject.name in groups:
+                            roles.add(binding.role_ref.name)
+
+            # Get all ClusterRoleBindings
+            cluster_role_bindings = self.rbac_v1.list_cluster_role_binding()
+
+            for binding in cluster_role_bindings.items:
+                if binding.subjects is not None:
+                    for subject in binding.subjects:
+                        # Check for direct user assignment
+                        if subject.kind == "User" and subject.name == username:
+                            roles.add(binding.role_ref.name)
+                        # Check for group-based assignment
+                        elif subject.kind == "Group" and subject.name in groups:
+                            roles.add(binding.role_ref.name)
+
+            logger.info(f"Found {len(roles)} roles for user {username}: {list(roles)}")
+
+        except Exception as e:
+            logger.error(f"Failed to extract user roles for {username}: {e}")
+
+        return list(roles)
+
     def _extract_groups_and_namespaces_from_token(
         self, access_token: str
     ) -> tuple[list[str], list[str]]:
@@ -189,7 +236,7 @@ def _extract_groups_and_namespaces_from_token(
                             groups.extend(namespace_groups)
                     else:
                         # Regular user logic - extract namespaces from dashboard-permissions RoleBindings
-                        user_namespaces = self._extract_user_data_science_projects(
+                        user_namespaces = self._extract_user_project_namespaces(
                             username
                         )
                         namespaces.extend(user_namespaces)
@@ -269,7 +316,7 @@ def _extract_namespace_access_groups(self, namespace: str) -> list[str]:
 
         return groups
 
-    def _extract_user_data_science_projects(self, username: str) -> list[str]:
+    def _extract_user_project_namespaces(self, username: str) -> list[str]:
         """
         Extract data science project namespaces where a user has been added via dashboard-permissions RoleBindings.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -18,6 +18,6 @@ typically your Offline Store). We are exploring adding a default streaming engin

		* We recommend [using Python](language.md) for your Feature Store microservice. As mentioned in the document, precomputing features is the recommended optimal path to ensure low latency performance. Reducing feature serving to a lightweight database lookup is the ideal pattern, which means the marginal overhead of Python should be tolerable. Because of this we believe the pros of Python outweigh the costs, as reimplementing feature logic is undesirable. Java and Go Clients are also available for online feature retrieval.

		* [Role-Based Access Control (RBAC)](rbac.md) is a security mechanism that restricts access to resources based on the roles of individual users within an organization. In the context of the Feast, RBAC ensures that only authorized users or groups can access or modify specific resources, thereby maintaining data security and operational integrity.
		* [Role-Based Access Control (RBAC)](rbac.md) is a security mechanism that restricts access to resources based on the roles/groups/namespaces of individual users within an organization. In the context of the Feast, RBAC ensures that only authorized users or groups can access or modify specific resources, thereby maintaining data security and operational integrity.