feat: Feast Security Model (aka RBAC)

[dmartinol]

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]

This is gonna take a while 😄

[HaoXuAI]

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]

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]

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

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

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

[franciscojavierarceo]

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]

Suggested change

	The RBAC implementation in Feast Feature Store is designed to:
	The RBAC implementation in Feast is designed to:

[franciscojavierarceo]

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]

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]

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]

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.

[redhatHameed]

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]

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]

Please remove this section as well.

[franciscojavierarceo]

Please remove this section as well.

[franciscojavierarceo]

Please remove this section as well.

[franciscojavierarceo]

Please remove this section as well.

[franciscojavierarceo]

Please remove this section as well.

[redhatHameed]

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]

Can you revert this change?

[redhatHameed]

Done.

[franciscojavierarceo]

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

/lgtm

[redhatHameed]

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

Next PRs will handle:

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

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

cc @jeremyary @dandawg