Skip to content

Commit 48b166b

Browse files
authored
Merge branch 'master' into support-table-format
2 parents 021f164 + 3aec5d5 commit 48b166b

File tree

83 files changed

+15720
-10401
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

83 files changed

+15720
-10401
lines changed

CHANGELOG.md

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,21 @@
11
# Changelog
22

3+
# [0.55.0](https://github.com/feast-dev/feast/compare/v0.54.0...v0.55.0) (2025-10-14)
4+
5+
6+
### Bug Fixes
7+
8+
* Added unix_timestamp_val in _serialize_val ([#5659](https://github.com/feast-dev/feast/issues/5659)) ([35a8423](https://github.com/feast-dev/feast/commit/35a84237bb15c5582ffa432f13fe5e4948a1c19c))
9+
* BatchFeatureView transformation should persist in Registry Ser/Deserialization ([3364bad](https://github.com/feast-dev/feast/commit/3364bad2be06556d20f6ff509068372c5f880561))
10+
* Check if DynamoDB table exists before create ([#5658](https://github.com/feast-dev/feast/issues/5658)) ([e7fd506](https://github.com/feast-dev/feast/commit/e7fd506f7320b0e3d9d62d247387ec21c1fe8c0f))
11+
* Fix the link to Expedia in the Go Feature Server readme. ([3ed0163](https://github.com/feast-dev/feast/commit/3ed01636d8476d2abc93c1396d33a877241a3091))
12+
13+
14+
### Features
15+
16+
* Add Claude instructions ([#5651](https://github.com/feast-dev/feast/issues/5651)) ([4807a52](https://github.com/feast-dev/feast/commit/4807a524129535ab26e76879cf95fc6513dbec74))
17+
* Groups and Namespaces based authorization, for Users and Service Accounts ([#5619](https://github.com/feast-dev/feast/issues/5619)) ([da6257c](https://github.com/feast-dev/feast/commit/da6257c757b2286f030acb31ea505090cf472442))
18+
319
# [0.54.0](https://github.com/feast-dev/feast/compare/v0.53.0...v0.54.0) (2025-09-30)
420

521

Makefile

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -620,6 +620,11 @@ build-feature-server-dev-docker: ## Build Feature Server Dev Docker image
620620
-t $(REGISTRY)/feature-server:$(VERSION) \
621621
-f sdk/python/feast/infra/feature_servers/multicloud/Dockerfile.dev --load .
622622

623+
build-feature-server-dev-docker_on_mac: ## Build Feature Server Dev Docker image on Mac
624+
docker buildx build --platform linux/amd64 \
625+
-t $(REGISTRY)/feature-server:$(VERSION) \
626+
-f sdk/python/feast/infra/feature_servers/multicloud/Dockerfile.dev --load .
627+
623628
push-feature-server-dev-docker: ## Push Feature Server Dev Docker image
624629
docker push $(REGISTRY)/feature-server:$(VERSION)
625630

Lines changed: 129 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,129 @@
1+
# Groups and Namespaces Based Authorization Implementation Summary
2+
3+
## Overview
4+
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.
5+
6+
## Changes Made
7+
8+
### 1. Enhanced User Model (`sdk/python/feast/permissions/user.py`)
9+
- **Extended User class** to include `groups` and `namespaces` attributes
10+
- **Added methods**:
11+
- `has_matching_group()`: Check if user has required groups
12+
- `has_matching_namespace()`: Check if user has required namespaces
13+
- **Maintained backward compatibility** with existing role-based functionality
14+
15+
### 2. New Policy Types (`sdk/python/feast/permissions/policy.py`)
16+
- **GroupBasedPolicy**: Grants access based on user group membership
17+
- **NamespaceBasedPolicy**: Grants access based on user namespace association
18+
- **CombinedGroupNamespacePolicy**: Requires both group OR namespace match
19+
- **Updated Policy.from_proto()** to handle new policy types
20+
- **Maintained backward compatibility** with existing RoleBasedPolicy
21+
22+
### 3. Protobuf Definitions (`protos/feast/core/Policy.proto`)
23+
- **Added GroupBasedPolicy message** with groups field
24+
- **Added NamespaceBasedPolicy message** with namespaces field
25+
- **Extended Policy message** to include new policy types in oneof
26+
- **[Love] Regenerated Python protobuf files** using `make compile-protos-python`
27+
28+
### 4. Token Access Review Integration (`sdk/python/feast/permissions/auth/kubernetes_token_parser.py`)
29+
- **Added AuthenticationV1Api client** for Token Access Review
30+
- **Implemented `_extract_groups_and_namespaces_from_token()`**:
31+
- Uses Kubernetes Token Access Review API
32+
- Extracts groups and namespaces from token response
33+
- Handles both service accounts and regular users
34+
- **Updated `user_details_from_access_token()`** to include groups and namespaces
35+
36+
### 5. Client SDK Updates (`sdk/python/feast/permissions/client/kubernetes_auth_client_manager.py`)
37+
- **Extended KubernetesAuthConfig** to support user tokens
38+
- **Updated `get_token()` method** to check for user_token in config
39+
- **Maintained backward compatibility** with service account tokens
40+
41+
### 6. Configuration Model (`sdk/python/feast/permissions/auth_model.py`)
42+
- **Added user_token field** to KubernetesAuthConfig for external users
43+
- **Maintained backward compatibility** with existing configurations
44+
45+
### 7. Comprehensive Tests (`sdk/python/tests/permissions/test_groups_namespaces_auth.py`)
46+
- **15 test cases** covering all new functionality
47+
- **Tests for**:
48+
- User creation with groups/namespaces
49+
- Group matching functionality
50+
- Namespace matching functionality
51+
- All new policy types
52+
- Backward compatibility
53+
54+
### 8. Documentation (`docs/getting-started/components/groups_namespaces_auth.md`)
55+
- **Usage examples** and configuration guides
56+
- **Security considerations** and best practices
57+
- **Troubleshooting guide** and migration instructions
58+
59+
60+
## Key Features Implemented
61+
62+
### ✅ Token Access Review Integration
63+
- Uses Kubernetes Token Access Review API to extract user details
64+
- Handles both service accounts and external users
65+
66+
### ✅ Groups and Namespaces Extraction
67+
- Extracts groups and namespaces from token response
68+
- Supports both service account and regular user tokens
69+
70+
### ✅ New Policy Types
71+
- **GroupBasedPolicy**: Access based on group membership
72+
- **NamespaceBasedPolicy**: Access based on namespace association
73+
- **CombinedGroupNamespacePolicy**: Requires either group OR namespace
74+
75+
### ✅ Client SDK Support
76+
- Extended to support user tokens for external users
77+
- Maintains backward compatibility with service account tokens
78+
- New parameter in KubernetesAuthConfig for user tokens
79+
80+
81+
## Usage Examples
82+
83+
### Basic Group-Based Permission
84+
```python
85+
from feast.permissions.policy import GroupBasedPolicy
86+
from feast.permissions.permission import Permission
87+
88+
policy = GroupBasedPolicy(groups=["data-team", "ml-engineers"])
89+
permission = Permission(
90+
name="data_team_access",
91+
types=ALL_RESOURCE_TYPES,
92+
policy=policy,
93+
actions=[AuthzedAction.DESCRIBE] + READ
94+
)
95+
```
96+
97+
### Basic Namespace-Based Permission
98+
```python
99+
from feast.permissions.policy import NamespaceBasedPolicy
100+
from feast.permissions.permission import Permission
101+
102+
policy = NamespaceBasedPolicy(namespaces=["de-dsp", "ml-dsp"])
103+
permission = Permission(
104+
name="data_team_access",
105+
types=ALL_RESOURCE_TYPES,
106+
policy=policy,
107+
actions=[AuthzedAction.DESCRIBE] + READ
108+
)
109+
```
110+
111+
### Combined Group + Namespace Permission
112+
```python
113+
from feast.permissions.policy import CombinedGroupNamespacePolicy
114+
115+
policy = CombinedGroupNamespacePolicy(
116+
groups=["data-team"],
117+
namespaces=["production"]
118+
)
119+
```
120+
121+
### Client Configuration with User Token
122+
```python
123+
from feast.permissions.auth_model import KubernetesAuthConfig
124+
125+
auth_config = KubernetesAuthConfig(
126+
type="kubernetes",
127+
user_token="your-kubernetes-user-token" # For external users
128+
)
129+
```

docs/getting-started/architecture/overview.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -18,6 +18,6 @@ typically your Offline Store). We are exploring adding a default streaming engin
1818

1919
* 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.
2020

21-
* [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.
21+
* [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.
2222

2323

docs/getting-started/architecture/rbac.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -2,13 +2,13 @@
22

33
## Introduction
44

5-
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.
5+
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.
66

77
## Functional Requirements
88

99
The RBAC implementation in Feast is designed to:
1010

11-
- **Assign Permissions**: Allow administrators to assign permissions for various operations and resources to users or groups based on their roles.
11+
- **Assign Permissions**: Allow administrators to assign permissions for various operations and resources to users or groups/namespaces.
1212
- **Seamless Integration**: Integrate smoothly with existing business code without requiring significant modifications.
1313
- **Backward Compatibility**: Maintain support for non-authorized models as the default to ensure backward compatibility.
1414

@@ -35,7 +35,7 @@ The RBAC system in Feast uses a permission model that defines the following conc
3535

3636
- **Resource**: An object within Feast that needs to be secured against unauthorized access.
3737
- **Action**: A logical operation performed on a resource, such as Create, Describe, Update, Delete, Read, or write operations.
38-
- **Policy**: A set of rules that enforce authorization decisions on resources. The default implementation uses role-based policies.
38+
- **Policy**: A set of rules that enforce authorization decisions on resources. The polices are based on user roles or groups or namespaces or combined.
3939

4040

4141

docs/getting-started/components/authz_manager.md

Lines changed: 4 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -99,7 +99,7 @@ auth:
9999
100100
### Kubernetes RBAC Authorization
101101
With Kubernetes RBAC Authorization, the client uses the service account token as the authorizarion bearer token, and the
102-
server fetches the associated roles from the Kubernetes RBAC resources.
102+
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.
103103
104104
An example of Kubernetes RBAC authorization configuration is the following:
105105
{% hint style="info" %}
@@ -109,19 +109,12 @@ An example of Kubernetes RBAC authorization configuration is the following:
109109
project: my-project
110110
auth:
111111
type: kubernetes
112+
user_token: <user_token> #Optional, else service account token Or env var is used for getting the token
112113
...
113114
```
114115

115116
In case the client cannot run on the same cluster as the servers, the client token can be injected using the `LOCAL_K8S_TOKEN`
116117
environment variable on the client side. The value must refer to the token of a service account created on the servers cluster
117-
and linked to the desired RBAC roles.
118+
and linked to the desired RBAC roles/groups/namespaces.
118119

119-
#### Setting Up Kubernetes RBAC for Feast
120-
121-
To ensure the Kubernetes RBAC environment aligns with Feast's RBAC configuration, follow these guidelines:
122-
* The roles defined in Feast `Permission` instances must have corresponding Kubernetes RBAC `Role` names.
123-
* The Kubernetes RBAC `Role` must reside in the same namespace as the Feast service.
124-
* The client application can run in a different namespace, using its own dedicated `ServiceAccount`.
125-
* Finally, the `RoleBinding` that links the client `ServiceAccount` to the RBAC `Role` must be defined in the namespace of the Feast service.
126-
127-
If the above rules are satisfied, the Feast service must be granted permissions to fetch `RoleBinding` instances from the local namespace.
120+
More details can be found in [Setting up kubernetes doc](../../reference/auth/kubernetes_auth_setup.md)

docs/getting-started/concepts/permission.md

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -101,6 +101,15 @@ Permission(
101101
)
102102
```
103103

104+
## Permission granting order
105+
106+
When mixing and matching policies in permissions script, the permission granting order is as follows:
107+
108+
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.
109+
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
110+
3. If no policy matches, the permission is denied
111+
112+
104113
## Authorization configuration
105114
In order to leverage the permission functionality, the `auth` section is needed in the `feature_store.yaml` configuration.
106115
Currently, Feast supports OIDC and Kubernetes RBAC authorization protocols.

0 commit comments

Comments
 (0)