feast-dev · franciscojavierarceo · Oct 10, 2025 · Sep 16, 2025 · Sep 18, 2025 · Oct 7, 2025
diff --git a/Makefile b/Makefile
@@ -620,6 +620,11 @@ build-feature-server-dev-docker: ## Build Feature Server Dev Docker image
 		-t $(REGISTRY)/feature-server:$(VERSION) \
 		-f sdk/python/feast/infra/feature_servers/multicloud/Dockerfile.dev --load .
 
+build-feature-server-dev-docker_on_mac: ## Build Feature Server Dev Docker image on Mac
+	docker buildx build --platform linux/amd64 \
+		-t $(REGISTRY)/feature-server:$(VERSION) \
+		-f sdk/python/feast/infra/feature_servers/multicloud/Dockerfile.dev --load .
+
 push-feature-server-dev-docker: ## Push Feature Server Dev Docker image
 	docker push $(REGISTRY)/feature-server:$(VERSION)
 

@@ -0,0 +1,129 @@
+# Groups and Namespaces Based Authorization Implementation Summary
+
+## Overview
+This document summarizes the implementation of groups and namespaces extraction support in Feast for user authentication in Pull Request https://github.com/feast-dev/feast/pull/5619.
+
+## Changes Made
+
+### 1. Enhanced User Model (`sdk/python/feast/permissions/user.py`)
+- **Extended User class** to include `groups` and `namespaces` attributes
+- **Added methods**:
+  - `has_matching_group()`: Check if user has required groups
+  - `has_matching_namespace()`: Check if user has required namespaces
+- **Maintained backward compatibility** with existing role-based functionality
+
+### 2. New Policy Types (`sdk/python/feast/permissions/policy.py`)
+- **GroupBasedPolicy**: Grants access based on user group membership
+- **NamespaceBasedPolicy**: Grants access based on user namespace association  
+- **CombinedGroupNamespacePolicy**: Requires both group OR namespace match
+- **Updated Policy.from_proto()** to handle new policy types
+- **Maintained backward compatibility** with existing RoleBasedPolicy
+
+### 3. Protobuf Definitions (`protos/feast/core/Policy.proto`)
+- **Added GroupBasedPolicy message** with groups field
+- **Added NamespaceBasedPolicy message** with namespaces field
+- **Extended Policy message** to include new policy types in oneof
+- **[Love] Regenerated Python protobuf files** using `make compile-protos-python`
+
+### 4. Token Access Review Integration (`sdk/python/feast/permissions/auth/kubernetes_token_parser.py`)
+- **Added AuthenticationV1Api client** for Token Access Review
+- **Implemented `_extract_groups_and_namespaces_from_token()`**:
+  - Uses Kubernetes Token Access Review API
+  - Extracts groups and namespaces from token response
+  - Handles both service accounts and regular users
+- **Updated `user_details_from_access_token()`** to include groups and namespaces
+
+### 5. Client SDK Updates (`sdk/python/feast/permissions/client/kubernetes_auth_client_manager.py`)
+- **Extended KubernetesAuthConfig** to support user tokens
+- **Updated `get_token()` method** to check for user_token in config
+- **Maintained backward compatibility** with service account tokens
+
+### 6. Configuration Model (`sdk/python/feast/permissions/auth_model.py`)
+- **Added user_token field** to KubernetesAuthConfig for external users
+- **Maintained backward compatibility** with existing configurations
+
+### 7. Comprehensive Tests (`sdk/python/tests/permissions/test_groups_namespaces_auth.py`)
+- **15 test cases** covering all new functionality
+- **Tests for**:
+  - User creation with groups/namespaces
+  - Group matching functionality
+  - Namespace matching functionality
+  - All new policy types
+  - Backward compatibility
+
+### 8. Documentation (`docs/getting-started/components/groups_namespaces_auth.md`)
+- **Usage examples** and configuration guides
+- **Security considerations** and best practices
+- **Troubleshooting guide** and migration instructions
+
+
+## Key Features Implemented
+
+### ✅ Token Access Review Integration
+- Uses Kubernetes Token Access Review API to extract user details
+- Handles both service accounts and external users
+
+### ✅ Groups and Namespaces Extraction
+- Extracts groups and namespaces from token response
+- Supports both service account and regular user tokens
+
+### ✅ New Policy Types
+- **GroupBasedPolicy**: Access based on group membership
+- **NamespaceBasedPolicy**: Access based on namespace association
+- **CombinedGroupNamespacePolicy**: Requires either group OR namespace
+
+### ✅ Client SDK Support
+- Extended to support user tokens for external users
+- Maintains backward compatibility with service account tokens
+- New parameter in KubernetesAuthConfig for user tokens
+
+
+## Usage Examples
+
+### Basic Group-Based Permission
+```python
+from feast.permissions.policy import GroupBasedPolicy
+from feast.permissions.permission import Permission
+
+policy = GroupBasedPolicy(groups=["data-team", "ml-engineers"])
+permission = Permission(
+    name="data_team_access",
+    types=ALL_RESOURCE_TYPES,
+    policy=policy,
+    actions=[AuthzedAction.DESCRIBE] + READ
+)
+```
+
+### Basic Namespace-Based Permission
+```python
+from feast.permissions.policy import NamespaceBasedPolicy
+from feast.permissions.permission import Permission
+
+policy = NamespaceBasedPolicy(namespaces=["de-dsp", "ml-dsp"])
+permission = Permission(
+    name="data_team_access",
+    types=ALL_RESOURCE_TYPES,
+    policy=policy,
+    actions=[AuthzedAction.DESCRIBE] + READ
+)
+```
+
+### Combined Group + Namespace Permission
+```python
+from feast.permissions.policy import CombinedGroupNamespacePolicy
+
+policy = CombinedGroupNamespacePolicy(
+    groups=["data-team"],
+    namespaces=["production"]
+)
+```
+
+### Client Configuration with User Token
+```python
+from feast.permissions.auth_model import KubernetesAuthConfig
+
+auth_config = KubernetesAuthConfig(
+    type="kubernetes",
+    user_token="your-kubernetes-user-token"  # For external users
+)
+```
@@ -2,13 +2,13 @@
 
 ## Introduction
 
-Role-Based Access Control (RBAC) 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) 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/namespaces can access or modify specific resources, thereby maintaining data security and operational integrity.
 
 ## Functional Requirements
 
 The RBAC implementation in Feast is designed to:
 
-- **Assign Permissions**: Allow administrators to assign permissions for various operations and resources to users or groups based on their roles.
+- **Assign Permissions**: Allow administrators to assign permissions for various operations and resources to users or groups/namespaces.
 - **Seamless Integration**: Integrate smoothly with existing business code without requiring significant modifications.
 - **Backward Compatibility**: Maintain support for non-authorized models as the default to ensure backward compatibility.
 
@@ -35,7 +35,7 @@ The RBAC system in Feast uses a permission model that defines the following conc
 
 - **Resource**: An object within Feast that needs to be secured against unauthorized access.
 - **Action**: A logical operation performed on a resource, such as Create, Describe, Update, Delete, Read, or write operations.
-- **Policy**: A set of rules that enforce authorization decisions on resources. The default implementation uses role-based policies.
+- **Policy**: A set of rules that enforce authorization decisions on resources. The polices are based on user roles or groups or namespaces or combined.
 
 
 

@@ -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 from the Kubernetes RBAC resources.
+server fetches the associated roles/groups/namespaces from the Kubernetes RBAC resources.
 
 An example of Kubernetes RBAC authorization configuration is the following: 
 {% hint style="info" %}
@@ -114,7 +114,7 @@ auth:
 
 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.
+and linked to the desired RBAC roles/groups/namespaces.
 
 #### Setting Up Kubernetes RBAC for Feast
 
@@ -124,4 +124,11 @@ To ensure the Kubernetes RBAC environment aligns with Feast's RBAC configuration
 * 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.
diff --git a/docs/reference/auth/groups_namespaces_auth.md b/docs/reference/auth/groups_namespaces_auth.md
@@ -0,0 +1,172 @@
+# Groups and Namespaces Authentication Support
+
+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.
+
+## 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:
+
+- **Groups**: User groups associated directly with User/SA and from associated namespace 
+- **Namespaces**: Kubernetes namespaces associated with User/SA
+
+## Key Features
+
+### 1. Token Access Review Integration
+
+The system now uses Kubernetes Token Access Review API to extract detailed user information from tokens, including:
+- User groups
+- Associated namespaces
+- User identity information
+
+### 2. Enhanced User Model
+
+The `User` class has been extended along with roles to include:
+- `groups`: List of user groups
+- `namespaces`: List of associated namespaces
+
+### 3. New Policy Types
+
+Three new policy types have been introduced:
+
+#### GroupBasedPolicy
+Grants access based on user group membership.
+
+```python
+from feast.permissions.policy import GroupBasedPolicy
+
+policy = GroupBasedPolicy(groups=["data-team", "ml-engineers"])
+```
+
+#### NamespaceBasedPolicy
+Grants access based on user namespace association.
+
+```python
+from feast.permissions.policy import NamespaceBasedPolicy
+
+policy = NamespaceBasedPolicy(namespaces=["production", "staging"])
+```
+
+#### CombinedGroupNamespacePolicy
+Grants access only when user is added into either permitted groups AND namespaces.
+
+```python
+from feast.permissions.policy import CombinedGroupNamespacePolicy
+
+policy = CombinedGroupNamespacePolicy(
+    groups=["data-team"],
+    namespaces=["production"]
+)
+```
+
+## Configuration
+
+### Server Configuration
+
+The server automatically extracts groups and namespaces 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
+
+### Basic Permission Setup
+
+```python
+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 (
+    GroupBasedPolicy,
+    NamespaceBasedPolicy,
+    CombinedGroupNamespacePolicy
+)
+
+# Group-based permission (new)
+data_team_perm = Permission(
+    name="data_team_permission",
+    types=ALL_RESOURCE_TYPES,
+    policy=GroupBasedPolicy(groups=["data-team", "ml-engineers"]),
+    actions=[AuthzedAction.DESCRIBE] + READ
+)
+
+# Namespace-based permission (new)
+prod_perm = Permission(
+    name="production_permission",
+    types=ALL_RESOURCE_TYPES,
+    policy=NamespaceBasedPolicy(namespaces=["production"]),
+    actions=[AuthzedAction.DESCRIBE] + READ
+)
+
+# Combined permission (new)
+dev_staging_perm = Permission(
+    name="dev_staging_permission",
+    types=ALL_RESOURCE_TYPES,
+    policy=CombinedGroupNamespacePolicy(
+        groups=["dev-team"],
+        namespaces=["staging"]
+    ),
+    actions=ALL_ACTIONS
+)
+```
+
+### Applying Permissions
+
+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
+
+1. **Token Access Review Fails**
+   - Check that the Feast server has the required RBAC permissions
+   - Verify the token is valid and not expired
+   - Check server logs for detailed error messages in debug mode
+
+2. **Groups/Namespaces Not Extracted**
+   - Verify the token contains the expected claims
+   - Check that the user is properly configured in Kubernetes/ODH/RHOAI
+
+3. **Permission Denied**
+   - Verify the user is added to required groups/namespaces
+   - Check that the policy is correctly configured
+   - Review the permission evaluation logs
+
+## Migration Guide
+
+### From Role-Based to Group/Namespace-Based
+
+1. **Identify User Groups**: Determine which groups your users belong to
+2. **Map Namespaces**: Identify which namespaces users should have access to
+3. **Create New Policies**: Define group-based and namespace-based policies
+4. **Test Gradually**: Start with read-only permissions and gradually expand
+5. **Monitor**: Watch logs to ensure proper authentication and authorization
+
+
+## Best Practices
+
+1. **Principle of Least Privilege**: Grant only the minimum required permissions
+2. **Group Organization**: Organize users into logical groups based on their responsibilities
+3. **Namespace Isolation**: Use namespaces to isolate different environments or teams
+4. **Regular Audits**: Periodically review and audit permissions
+
+## Related Documentation
+
+- [Authorization Manager](./authz_manager.md)
+- [Permission Model](../concepts/permission.md)
+- [RBAC Architecture](../architecture/rbac.md)
+- [Kubernetes RBAC Authorization](./authz_manager.md#kubernetes-rbac-authorization)
+
+
+