Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename READ action to DESCRIBE #81

Merged
merged 2 commits into from
Aug 19, 2024
Merged

Rename READ action to DESCRIBE #81

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0f747fb
renamed READ action to DESCRIBE
dmartinol Aug 19, 2024
4f90ed2
Specified authorization manager and authorization configuration
dmartinol Aug 19, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
105 changes: 95 additions & 10 deletions docs/getting-started/components/authz_manager.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,17 +1,102 @@
# Authorization manager
**TODO** Complete and validate once the code is consolidated

An authorization manager is an implementation of the `AuthManager` interface that is plugged into one of the Feast servers to extract user details from the current request and inject them into the [permissions](../../getting-started/concepts/permissions.md) framework.
# Authorization Manager
An Authorization Manager is an instance of the `AuthManager` class that is plugged into one of the Feast servers to extract user details from the current request and inject them into the [permissions](../../getting-started/concepts/permissions.md) framework.

{% hint style="info" %}
**Note**: Feast does not provide authentication capabilities; it is the client's responsibility to manage the authentication token and pass it to
the Feast server, which then validates the token and extracts user details from the configured authentication server.
{% endhint %}

Two implementations are provided out-of-the-box:
* The `OidcAuthManager` implementation, using a configurable OIDC server to extract the user details.
* The `KubernetesAuthManager` implementation, using the Kubernetes RBAC resources to extract the user details.
Two authorization managers are supported out-of-the-box:
* One using a configurable OIDC server to extract the user details.
* One using the Kubernetes RBAC resources to extract the user details.

These instances are created when the Feast servers are initialized, according to the authorization configuration defined in
their own `feature_store.yaml`.

Feast servers and clients must have consistent authorization configuration, so that the client proxies can automatically inject
the authorization tokens that the server can properly identify and use to enforce permission validations.


## Design notes
The server-side implementation of the authorization functionality is defined [here](./../../../sdk/python/feast/permissions/server).
Few of the key models, classes to understand the authorization implementation on the client side can be found [here](./../../../sdk/python/feast/permissions/client).

## Configuring Authorization
The authorization is configured using a dedicated `auth` section in the `feature_store.yaml` configuration.

**Note**: As a consequence, when deploying the Feast servers with the Helm [charts](../../../infra/charts/feast-feature-server/README.md),
the `feature_store_yaml_base64` value must include the `auth` section to specify the authorization configuration.

### No Authorization
This configuration applies the default `no_auth` authorization:
```yaml
project: my-project
auth:
type: no_auth
...
```

### OIDC Authorization
With OIDC authorization, the Feast client proxies retrieve the JWT token from an OIDC server (or [Identity Provider](https://openid.net/developers/how-connect-works/))
and append it in every request to a Feast server, using an [Authorization Bearer Token](https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication#bearer).

The server, in turn, uses the same OIDC server to validate the token and extract the user roles from the token itself.

Some assumptions are made in the OIDC server configuration:
* The OIDC token refers to a client with roles matching the RBAC roles of the configured `Permission`s (*)
* The roles are exposed in the access token passed to the server

(*) Please note that **the role match is case-sensitive**, e.g. the name of the role in the OIDC server and in the `Permission` configuration
must be exactly the same.

For example, the access token for a client `app` of a user with `reader` role should have the following `resource_access` section:
```json
{
"resource_access": {
"app": {
"roles": [
"reader"
]
},
}
```

An example of OIDC authorization configuration is the following:
```yaml
project: my-project
auth:
type: oidc
client_id: _CLIENT_ID__
client_secret: _CLIENT_SECRET__
realm: _REALM__
auth_server_url: _OIDC_SERVER_URL_
auth_discovery_url: _OIDC_SERVER_URL_/realms/master/.well-known/openid-configuration
...
```

In case of client configuration, the following settings must be added to specify the current user:
```yaml
auth:
...
username: _USERNAME_
password: _PASSWORD_
```

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

An example of Kubernetes RBAC authorization configuration is the following:
{% hint style="info" %}
**NOTE**: This configuration will only work if you deploy feast on Openshift or a Kubernetes platform.
{% endhint %}
```yaml
project: my-project
auth:
type: kubernetes
...
```

**TODO** Working assumptions for the auth manager implementations (e.g. bearer tokens)
**TODO** Instruct how to configure it in the servers
**TODO** Instruct how to configure it in the helm releases
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.
66 changes: 13 additions & 53 deletions docs/getting-started/concepts/permission.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ The permission model is based on the following components:
- We assume that the resource has a `name` attribute and optional dictionary of associated key-value `tags`.
- An `action` is a logical operation executed on the secured resource, like:
- `create`: Create an instance.
- `read`: Access the instance state.
- `describe`: Access the instance state.
- `update`: Update the instance state.
- `delete`: Delete an instance.
- `query`: Query both online and offline stores.
Expand Down Expand Up @@ -61,15 +61,15 @@ The `feast` CLI includes a new `permissions` command to list the registered perm
**Note**: Feast resources that do not match any of the configured permissions are not secured by any authorization policy, meaning any user can execute any action on such resources.
{% endhint %}

## Configuration examples
This permission configuration allows access to the resource state and the ability to query all the stores for any feature view or feature service
to all users with role `super-reader`:
## Definition examples
This permission definition grants access to the resource state and the ability to query all the stores for any feature view or
feature service to all users with role `super-reader`:
```py
Permission(
name="feature-reader",
types=[FeatureView, FeatureService],
policy=RoleBasedPolicy(roles=["super-reader"]),
actions=[AuthzedAction.READ, QUERY],
actions=[AuthzedAction.DESCRIBE, QUERY],
)
```

Expand Down Expand Up @@ -100,52 +100,12 @@ Permission(
)
```

## Authorizing Feast clients
If you would like to leverage the permissions' functionality then `auth` config block should be added to feature_store.yaml. Currently, feast supports oidc and kubernetes rbac authentication/authorization.

The default configuration if you don't mention the auth configuration is no_auth configuration.

* No auth configuration example:
```yaml
project: foo
registry: "registry.db"
provider: local
online_store:
path: foo
entity_key_serialization_version: 2
auth:
type: no_auth
```
## 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.

* Kubernetes rbac authentication/authorization example:
{% hint style="info" %}
**NOTE**: This configuration will only work if you deploy feast on Openshift or a Kubernetes platform.
{% endhint %}
```yaml
project: foo
registry: "registry.db"
provider: local
online_store:
path: foo
entity_key_serialization_version: 2
auth:
type: kubernetes
```
* OIDC authorization: Below configuration is an example for OIDC authorization example.
```yaml
project: foo
auth:
type: oidc
client_id: test_client_id
client_secret: test_client_secret
username: test_user_name
password: test_password
realm: master
auth_discovery_url: http://localhost:8080/realms/master/.well-known/openid-configuration
registry: "registry.db"
provider: local
online_store:
path: foo
entity_key_serialization_version: 2
```
Few of the key models, classes to understand the authorization implementation from the clients can be found [here](./../../../sdk/python/feast/permissions/client).
The default configuration, if you don't specify the `auth` configuration section, is `no_auth`, indicating that no permission
enforcement is applied.

The `auth` section includes a `type` field specifying the actual authorization protocol, and protocol-specific fields that
are specified in [Authorization Manager](../components/authz_manager.md).
22 changes: 11 additions & 11 deletions docs/reference/feast-cli-commands.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -174,11 +174,11 @@ Options:
+-----------------------+-------------+-----------------------+-----------+----------------+-------------------------+
| NAME | TYPES | NAME_PATTERN | ACTIONS | ROLES | REQUIRED_TAGS |
+=======================+=============+=======================+===========+================+================+========+
| reader_permission1234 | FeatureView | transformed_conv_rate | READ | reader | - |
| reader_permission1234 | FeatureView | transformed_conv_rate | DESCRIBE | reader | - |
+-----------------------+-------------+-----------------------+-----------+----------------+-------------------------+
| writer_permission1234 | FeatureView | transformed_conv_rate | CREATE | writer | - |
+-----------------------+-------------+-----------------------+-----------+----------------+-------------------------+
| special | FeatureView | special.* | READ | admin | test-key2 : test-value2 |
| special | FeatureView | special.* | DESCRIBE | admin | test-key2 : test-value2 |
| | | | UPDATE | special-reader | test-key : test-value |
+-----------------------+-------------+-----------------------+-----------+----------------+-------------------------+
```
Expand Down Expand Up @@ -215,7 +215,7 @@ requiredTags:
required1: required-value1
required2: required-value2
actions:
- READ
- DESCRIBE
policy:
roleBasedPolicy:
roles:
Expand Down Expand Up @@ -256,40 +256,40 @@ admin driver_hourly_stats_source FileSource CREATE
DELETE
QUERY_OFFLINE
QUERY_ONLINE
READ
DESCRIBE
UPDATE
admin vals_to_add RequestSource CREATE
DELETE
QUERY_OFFLINE
QUERY_ONLINE
READ
DESCRIBE
UPDATE
admin driver_stats_push_source PushSource CREATE
DELETE
QUERY_OFFLINE
QUERY_ONLINE
READ
DESCRIBE
UPDATE
admin driver_hourly_stats_source FileSource CREATE
DELETE
QUERY_OFFLINE
QUERY_ONLINE
READ
DESCRIBE
UPDATE
admin vals_to_add RequestSource CREATE
DELETE
QUERY_OFFLINE
QUERY_ONLINE
READ
DESCRIBE
UPDATE
admin driver_stats_push_source PushSource CREATE
DELETE
QUERY_OFFLINE
QUERY_ONLINE
READ
DESCRIBE
UPDATE
reader driver_hourly_stats FeatureView READ
reader driver_hourly_stats_fresh FeatureView READ
reader driver_hourly_stats FeatureView DESCRIBE
reader driver_hourly_stats_fresh FeatureView DESCRIBE
...
```

Expand Down
2 changes: 1 addition & 1 deletion protos/feast/core/Permission.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@ message Permission {
message PermissionSpec {
enum AuthzedAction {
CREATE = 0;
READ = 1;
DESCRIBE = 1;
UPDATE = 2;
DELETE = 3;
QUERY_ONLINE = 4;
Expand Down
4 changes: 2 additions & 2 deletions sdk/python/feast/permissions/action.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ class AuthzedAction(enum.Enum):
"""

CREATE = "create" # Create an instance
READ = "read" # Access the instance state
DESCRIBE = "describe" # Access the instance state
UPDATE = "update" # Update the instance state
DELETE = "delete" # Deelete an instance
QUERY_ONLINE = "query_online" # Query the online store only
Expand All @@ -34,7 +34,7 @@ class AuthzedAction(enum.Enum):
# Alias for CRUD actions
CRUD = [
AuthzedAction.CREATE,
AuthzedAction.READ,
AuthzedAction.DESCRIBE,
AuthzedAction.UPDATE,
AuthzedAction.DELETE,
]
Loading
Loading