Merge pull request feast-dev#23 from dmartinol/feast-rbac

User guide

docs/SUMMARY.md

@@ -16,6 +16,7 @@
   * [Feature retrieval](getting-started/concepts/feature-retrieval.md)
   * [Point-in-time joins](getting-started/concepts/point-in-time-joins.md)
   * [Registry](getting-started/concepts/registry.md)
+  * [Permissions](getting-started/concepts/permissions.md)
   * [\[Alpha\] Saved dataset](getting-started/concepts/dataset.md)
 * [Architecture](getting-started/architecture-and-components/README.md)
   * [Overview](getting-started/architecture-and-components/overview.md)

docs/getting-started/architecture-and-components/README.md

@@ -27,3 +27,7 @@
 {% content-ref url="provider.md" %}
 [provider.md](provider.md)
 {% endcontent-ref %}
+
+{% content-ref url="authz_manager.md" %}
+[authz_manager.md](authz_manager.md)
+{% endcontent-ref %}

docs/getting-started/architecture-and-components/authz_manager.md

@@ -0,0 +1,18 @@
+# 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.
+
+{% 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.
+
+**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 
+

docs/getting-started/architecture-and-components/overview.md

@@ -28,6 +28,7 @@ A complete Feast deployment contains the following components:
 * **Batch Materialization Engine:** The [Batch Materialization Engine](batch-materialization-engine.md) component launches a process which loads data into the online store from the offline store. By default, Feast uses a local in-process engine implementation to materialize data. However, additional infrastructure can be used for a more scalable materialization process.
 * **Online Store:** The online store is a database that stores only the latest feature values for each entity. The online store is either populated through materialization jobs or through [stream ingestion](../../reference/data-sources/push.md).
 * **Offline Store:** The offline store persists batch data that has been ingested into Feast. This data is used for producing training datasets. For feature retrieval and materialization, Feast does not manage the offline store directly, but runs queries against it. However, offline stores can be configured to support writes if Feast configures logging functionality of served features.
+* **Authorization manager**: The authorization manager detects authentication tokens from client requests to Feast servers and uses this information to enforce permission policies on the requested services.
 
 {% hint style="info" %}
 Java and Go Clients are also available for online feature retrieval. 

docs/getting-started/concepts/README.md

@@ -31,3 +31,7 @@
 {% content-ref url="dataset.md" %}
 [dataset.md](dataset.md)
 {% endcontent-ref %}
+
+{% content-ref url="permission.md" %}
+[permission.md](permission.md)
+{% endcontent-ref %}

docs/getting-started/concepts/permission.md

@@ -0,0 +1,121 @@
+# Permission
+
+## Overview
+
+The Feast permissions model allows to configure granular permission policies to all the resources defined in a feature store.
+
+The configured permissions are stored in the Feast registry and accessible through the CLI and the registry APIs.
+
+The 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)
+
+On the contrary, there is no permission enforcement when accessing the Feast API with a local provider.
+
+## Concepts
+
+The permission model is based on the following components:
+- A `resource` is a Feast object that we want to secure against unauthorized access.
+  - 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.
+  - `update`: Update the instance state.
+  - `delete`: Delete an instance.
+  - `query`:  Query both online and offline stores.
+  - `query_online`:  Query the online store.
+  - `query_offline`:  Query the o ffline store.
+  - `write`:  Query on any store.
+  - `write_online`:  Write to the online store.
+  - `write_offline`:  Write to the offline store.
+- A `policy` identifies the rule for enforcing authorization decisions on secured resources, based on the current user.
+  - A default implementation is provided for role-based policies, using the user roles to grant or deny access to the requested actions
+  on the secured resources.
+
+The `Permission` class identifies a single permission configured on the feature store and is identified by these attributes:
+- `name`: The permission name.
+- `types`: The list of protected resource  types. Defaults to all managed types, e.g. the `ALL_RESOURCE_TYPES` alias
+- `with_subclasses`: Specify if sub-classes are included in the resource match or not. Defaults to `True`.
+- `name_pattern`: A regex to match the resource name. Defaults to `None`, meaning that no name filtering is applied
+- `required_tags`: Dictionary of key-value pairs that must match the resource tags. Defaults to `None`, meaning that no tags filtering is applied.
+- `actions`: The actions authorized by this permission. Defaults to `AuthzedAction.ALL`.
+- `policy`: The policy to be applied to validate a client request.
+
+Given the above definitions, the feature store can be configured with granular control over each resource, enabling partitioned access by 
+teams to meet organizational requirements for service and data sharing, and protection of sensitive information.
+
+The `feast` CLI includes a new `permissions` command to list the registered permissions, with options to identify the matching resources for each configured permission and the existing resources that are not covered by any permission.
+
+{% hint style="info" %}
+**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 to access the resource state and 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],
+)
+```
+Please note that all sub-classes of `FeatureView` are also included since the default for the `with_subclasses` parameter is `True`.
+
+This example grants permission to write on all the data sources with `risk_level` tag set to `hi` only to users with role `admin` or `data_team`:
+```py
+Permission(
+    name="ds-writer",
+    types=[DataSource],
+    required_tags={"risk_level": "hi"},
+    policy=RoleBasedPolicy(roles=["admin", "data_team"]),
+    actions=[AuthzedAction.WRITE],
+)
+```
+
+{% hint style="info" %}
+**Note**: When using multiple roles in a role-based policy, the user must be granted at least one of the specified roles.
+{% endhint %}
+
+
+The following permission grants authorization to query the offline store of all the feature views including `risky` in the name, to users with role `trusted`:
+```py
+Permission(
+    name="reader",
+    types=[FeatureView],
+    with_subclasses=False, # exclude sub-classes
+    name_pattern=".*risky.*",
+    policy=RoleBasedPolicy(roles=["trusted"]),
+    actions=[AuthzedAction.QUERY_OFFLINE],
+)
+```
+
+## Authorizing Feast clients
+**TODO**
+Initial proposals:
+* Kubernetes RBAC:
+```yaml
+offline_store:
+    type: remote
+    host: localhost
+    port: 8815
+    auth:
+        type: kubernetes
+```
+* OIDC authorization:
+```yaml
+offline_store:
+    type: remote
+    host: localhost
+    port: 8815
+    auth:
+        type: oidc
+        server: 'http://0.0.0.0:8080'
+        realm: 'OIDC_REALM'
+        client-id: 'CLIENT_ID'
+        client-secret: 'CLIENT_SECRET'
+        username: 'USERNAME'
+        password: 'PASSWORD'
+```

docs/reference/feast-cli-commands.md

@@ -24,6 +24,7 @@ Commands:
   init                     Create a new Feast repository
   materialize              Run a (non-incremental) materialization job to...
   materialize-incremental  Run an incremental materialization job to ingest...
+  permissions              Access permissions
   registry-dump            Print contents of the metadata registry
   teardown                 Tear down deployed feature store infrastructure
   version                  Display Feast SDK version
@@ -155,6 +156,28 @@ Load data from feature views into the online store, beginning from either the pr
 feast materialize-incremental 2022-01-01T00:00:00
 ```
 
+## Permissions
+***TODO*** Update
+```text
+feast permissions --help
+...
+```
+
+### List permissions
+***TODO*** Description and output examples
+
+```text
+feast permissions list
+...
+```
+
+### Describe a permission
+***TODO*** Description and output examples
+```text
+feast permissions describe permission-name
+...
+```
+
 ## Teardown
 
 Tear down deployed feature store infrastructure

sdk/python/docs/source/feast.infra.feature_servers.rst

@@ -7,8 +7,6 @@ Subpackages
 .. toctree::
    :maxdepth: 4
 
-   feast.infra.feature_servers.aws_lambda
-   feast.infra.feature_servers.gcp_cloudrun
    feast.infra.feature_servers.local_process
    feast.infra.feature_servers.multicloud
 

sdk/python/docs/source/feast.rst

@@ -12,6 +12,7 @@ Subpackages
    feast.embedded_go
    feast.infra
    feast.loaders
+   feast.permissions
    feast.protos
    feast.transformation
    feast.ui