feat: Feast Security Model (aka RBAC) #4380

dmartinol · 2024-08-05T15:33:00Z

What this PR does / why we need it:

This PR proposes a permission model to enable the store administrator to identify which users are allowed to execute operations on each managed resource.

Granular permission enforcement identifies user roles (*) allowed to execute requested operations on
resources matched by type, optional name patterns, and tags:

Permission(
    name="reader",
    types=[FeatureView],
    name_pattern=".*risky.*",
    policy=RoleBasedPolicy(roles=["trusted"]),
    actions=[AuthzedAction.QUERY_OFFLINE],
)

Such resource partitioning allows teams working on the same set of features to share the same feature store, mitigating the risk of unexpected changes due to unauthorized operations.

The PR also adds support for managing authorization tokens from either OIDC or Kubernetes, in a configurable way.

Permission authorization enforcement is performed when requests are executed through one of the Feast (Python) servers:

The online feature server (REST)
The offline feature server (Arrow Flight)
The registry server (grpc)

project: foo
registry: "registry.db"
provider: local
online_store:
  path: foo
entity_key_serialization_version: 2
auth:
  type: kubernetes

To avoid backward incompatibility with existing installations, the default authorization is not enabled (e.g., auth type
is set to no-auth) .

Feast clients can use the same configuration options to automatically retrieve the token from the authorization server
and transparently secure all the remote requests. This pattern allows the client to use the authorization infrastructure without affecting the business code.

By design, only the client requests are validated: once the endpoint execution is permitted for the original client request,
all the next service-to-service requests generated by the execution flow are automatically allowed.

Validation is typically implemented within the endpoint functions using an assertion-like style:

        assert_permissions(
            resource=FeatureView.from_proto(request.feature_view),
            actions=[AuthzedAction.WRITE_ONLINE],
        )

The PR also includes:

Docs update to provide general description of the feature
Unit test for all the new modules
Integration tests to verify the server behavior while adding the authorization components
New permission CLI command with sub-commands to explore and troubleshoot the permissions settings

Fully working examples both Kubernetes and OIDC authorization will be in another next PR.

(*) Match by role is the predefined option, but it can be customized to support any other user validation.

Other features coming soon

Feature flag to override the store configuration and disable any permission validation
Export validation metrics to telemetry collectors (related to feat: Instrument Feast using Prometheus and OpenTelemetry #4366)

Which issue(s) this PR fixes:

Fixes #4198

tokoko · 2024-08-05T17:32:12Z

This is gonna take a while 😄

sdk/python/feast/registry_server.py

setup.py

protos/feast/core/Permission.proto

examples/rbac/client/admin_user_resources.yaml

docs/getting-started/concepts/permission.md

docs/reference/registry/registry-permissions.md

HaoXuAI · 2024-08-06T19:27:28Z

Hey, this is a great feature and also a big PR. Maybe it's better to walk us through the design, implementation, demo etc. in the next standup to get us understanding it better?

redhatHameed · 2024-08-06T21:30:55Z

Hey, this is a great feature and also a big PR. Maybe it's better to walk us through the design, implementation, demo etc. in the next standup to get us understanding it better?

sure, this will be a good idea.
cc @jeremyary @dmartinol

dmartinol · 2024-08-07T14:21:46Z

@tokoko we realized that when the remote registry (transparently) invokes a server API, there's no way to catch a FeatureViewNotFoundException as in this example, because the server raises an InactiveRpcError instead.

Should we create an issue to extend the registry server to add error details and the registry client to convert the grpc error into the original Exception? I don't think this has to be part of the RBAC commit.

@redhatHameed FYI this is also the root cause of the error in the demo setup

An error occurred: <_InactiveRpcError of RPC that terminated with:
        status = StatusCode.UNKNOWN
        details = "Exception calling application: Feature view driver_hourly_stats_fresh does not exist in project server"
        debug_error_string = "UNKNOWN:Error received from peer  {grpc_message:"Exception calling application: Feature view driver_hourly_stats_fresh does not exist in project server", grpc_status:2, created_time:"2024-08-07T15:00:29.930731564+00:00"}"
>

tokoko · 2024-08-07T15:34:28Z

@dmartinol sure, sounds like a bug to me. That should be tested in registry tests as well, I think. please go ahead and create a ticket.

franciscojavierarceo · 2024-08-07T17:12:05Z

In the PR template you say

"To avoid backward compatibilities with existing installations, the default authorization is not enabled (e.g., auth type is set to no-auth) ."

Did you mean "To avoid backward incompatibility with.."

docs/SUMMARY.md

docs/getting-started/concepts/permission.md

franciscojavierarceo · 2024-08-20T19:34:41Z

docs/getting-started/architecture/rbac.md

+
+## 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 Feature Store, RBAC ensures that only authorized users or groups can access or modify specific resources, thereby maintaining data security and operational integrity.


Suggested change

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 Feature Store, 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 of individual users within an organization. In the context of the Feast Feature Store, RBAC ensures that only authorized users or groups can access or modify specific resources, thereby maintaining data security and operational integrity.

Suggested change

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 Feature Store, 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 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.

franciscojavierarceo · 2024-08-20T19:34:57Z

docs/getting-started/architecture/rbac.md

+
+## Functional Requirements
+
+The RBAC implementation in Feast Feature Store is designed to:


Suggested change

The RBAC implementation in Feast Feature Store is designed to:

The RBAC implementation in Feast is designed to:

franciscojavierarceo · 2024-08-20T19:35:21Z

docs/getting-started/architecture/rbac.md

+
+## Business Goals
+
+The primary business goals of implementing RBAC in the Feast Feature Store are:


Suggested change

The primary business goals of implementing RBAC in the Feast Feature Store are:

The primary business goals of implementing RBAC in the Feast are:

franciscojavierarceo · 2024-08-20T19:35:42Z

docs/getting-started/architecture/rbac.md

+
+The primary business goals of implementing RBAC in the Feast Feature Store are:
+
+1. **Feature Sharing**: Enable multiple teams to share the feature store while ensuring controlled access to data partitions. This allows for collaborative work without compromising data security.


Suggested change

1. **Feature Sharing**: Enable multiple teams to share the feature store while ensuring controlled access to data partitions. This allows for collaborative work without compromising data security.

1. **Feature Sharing**: Enable multiple teams to share the feature store while ensuring controlled access. This allows for collaborative work without compromising data security.

franciscojavierarceo · 2024-08-20T19:36:09Z

docs/getting-started/architecture/rbac.md

+
+## Reference Architecture
+
+The Feast Feature Store operates as a collection of connected services, each enforcing authorization permissions. The architecture is designed as a distributed microservices system with the following key components:


Suggested change

The Feast Feature Store operates as a collection of connected services, each enforcing authorization permissions. The architecture is designed as a distributed microservices system with the following key components:

Feast operates as a collection of connected services, each enforcing authorization permissions. The architecture is designed as a distributed microservices system with the following key components:

franciscojavierarceo · 2024-08-20T19:36:52Z

docs/getting-started/architecture/rbac.md

+
+The Feast Feature Store operates as a collection of connected services, each enforcing authorization permissions. The architecture is designed as a distributed microservices system with the following key components:
+
+- **Service Endpoints**: These enforce authorization permissions, ensuring that only authorized requests are processed.


Can you confirm that these three are correct? i know this was generated with an LLM (which is fine!) but I think some of this may not be right.

that's correct, simplified it more .

note Service-to-Service Communication this feature not yet part of this PR will be implementation next PRs.

franciscojavierarceo · 2024-08-20T19:37:43Z

docs/getting-started/architecture/rbac.md

+- **Action**: A logical operation performed on a resource, such as Create, Describe, Update, Delete, query, or write operations.
+- **Policy**: A set of rules that enforce authorization decisions on resources. The default implementation uses role-based policies.
+
+### Configuring Permissions


Please remove this section as the architecture is meant to give a motivation and not the implementation details.

franciscojavierarceo

Last changes. The architecture section should be pretty high level. I believe some of what you added to a PR is included in other documentation. If it's not, can you add it to the components section? I like the documentation, I just think it's better served under the components section.

After that I think we're good.

franciscojavierarceo · 2024-08-20T19:37:53Z

docs/getting-started/architecture/rbac.md

+)
+```
+
+### Enforcing Permission Policy


Please remove this section as well.

franciscojavierarceo · 2024-08-20T19:38:01Z

docs/getting-started/architecture/rbac.md

+```python
+assert_permissions(
+    resource=feature_service,
+    actions=[AuthzedAction.QUERY_ONLINE]
+)
+```
+
+## Use Cases
+
+### Tag-Based Permission


Please remove this section as well.

franciscojavierarceo · 2024-08-20T19:38:06Z

docs/getting-started/architecture/rbac.md

+)
+```
+
+### Name-Based Permission


Please remove this section as well.

franciscojavierarceo · 2024-08-20T19:38:13Z

docs/getting-started/architecture/rbac.md

+3. **Policy Enforcer**: Validates the secured endpoint against the retrieved user details.
+4. **Token Injector**: Adds the authorization token to each secured request header.
+
+### OIDC Authorization


Please remove this section as well.

franciscojavierarceo · 2024-08-20T19:38:18Z

docs/getting-started/architecture/rbac.md

+  auth_server_url: _OIDC_SERVER_URL_
+```
+
+### Kubernetes Authorization


Please remove this section as well.

…emory. Signed-off-by: Lokesh Rangineni <[email protected]>

redhatHameed · 2024-08-20T20:44:45Z

Last changes. The architecture section should be pretty high level. I believe some of what you added to a PR is included in other documentation. If it's not, can you add it to the components section? I like the documentation, I just think it's better served under the components section.

After that I think we're good.

Agreed was repetition these are already aded into components section, hence removed from here.

franciscojavierarceo · 2024-08-20T21:12:54Z

README.md

 [![License](https://img.shields.io/badge/License-Apache%202.0-blue)](https://github.com/feast-dev/feast/blob/master/LICENSE)
 [![GitHub Release](https://img.shields.io/github/v/release/feast-dev/feast.svg?style=flat&sort=semver&color=blue)](https://github.com/feast-dev/feast/releases)

-## Join us on Slack!


Can you revert this change?

Signed-off-by: Abdul Hameed <[email protected]>

docs/getting-started/concepts/permission.md

docs/reference/feature-servers/offline-feature-server.md

Signed-off-by: Abdul Hameed <[email protected]>

franciscojavierarceo

Amazing work here, thanks for taking in all of the changes!

/lgtm

redhatHameed · 2024-08-21T14:08:35Z

@tokoko @franciscojavierarceo Thanks for taking time to review and approve this

Next PRs will handle:

Working examples of RBAC configuration with OIDC and Kubernetes.
Solution for intra-service communication
Fix the dependencies to make it not required in setup.py
Refactoring the OIDC authentication to use discovery URL

Also if there is no any further concern can you merge this Thanks

cc @jeremyary @dandawg

dmartinol changed the title ~~Feast Security Model (aka RBAC)~~ feat: Feast Security Model (aka RBAC) Aug 5, 2024

redhatHameed force-pushed the feast-rbac branch 3 times, most recently from 13c57d4 to c456222 Compare August 5, 2024 16:27

dmartinol marked this pull request as ready for review August 5, 2024 17:24

tokoko reviewed Aug 5, 2024

View reviewed changes

sdk/python/feast/registry_server.py Outdated Show resolved Hide resolved

tokoko reviewed Aug 5, 2024

View reviewed changes

setup.py Outdated Show resolved Hide resolved

tokoko reviewed Aug 5, 2024

View reviewed changes

protos/feast/core/Permission.proto Outdated Show resolved Hide resolved

redhatHameed reviewed Aug 5, 2024

View reviewed changes

examples/rbac/client/admin_user_resources.yaml Outdated Show resolved Hide resolved

redhatHameed reviewed Aug 5, 2024

View reviewed changes

docs/getting-started/concepts/permission.md Outdated Show resolved Hide resolved

redhatHameed reviewed Aug 5, 2024

View reviewed changes

docs/reference/registry/registry-permissions.md Show resolved Hide resolved

jeremyary added the ok-to-test label Aug 6, 2024

tmihalac force-pushed the feast-rbac branch from 1ed6477 to 377fce1 Compare August 6, 2024 16:41

redhatHameed force-pushed the feast-rbac branch from e7b67ce to 5674629 Compare August 6, 2024 17:45

redhatHameed force-pushed the feast-rbac branch 2 times, most recently from 9b8f88d to 0a3a3ba Compare August 7, 2024 13:13

franciscojavierarceo reviewed Aug 7, 2024

View reviewed changes

docs/SUMMARY.md Outdated Show resolved Hide resolved