feat: Groups and Namespaces based authorization, for Users and Service Accounts

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)
 

docs/changelogs/Groups_Namespaces_Auth_implmentation_summary.md

@@ -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
+)
+```

docs/getting-started/architecture/overview.md

@@ -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.
 
 

docs/getting-started/architecture/rbac.md

@@ -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.
 
 
 

docs/getting-started/components/authz_manager.md

@@ -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 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,19 +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.
+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.
-
-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)

docs/getting-started/concepts/permission.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.