> For the complete documentation index, see [llms.txt](https://docs.feast.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.feast.dev/master/getting-started/components/authz_manager.md). # 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 [permission](/master/getting-started/concepts/permission.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 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](https://github.com/feast-dev/feast/tree/master/sdk/python/feast/permissions/server/README.md). Few of the key models, classes to understand the authorization implementation on the client side can be found [here](https://github.com/feast-dev/feast/tree/master/sdk/python/feast/permissions/client/README.md). ## Default Authorization Behavior ### Feast Operator (Kubernetes Deployments) When deploying Feast using the [Feast operator](https://github.com/feast-dev/feast/tree/master/infra/feast-operator/docs/api/markdown/ref.md), **Kubernetes authentication is enabled by default**. If no `authz` section is specified in the `FeatureStore` CR, the operator automatically configures `kubernetes` auth for all deployed services. This follows an **"Authenticated by Default, Authorized Gradually"** security model: * All Feast endpoints require a valid Kubernetes bearer token by default. * If no explicit `Permission` objects are defined (via `permissions.py` + `feast apply`), **all authenticated users are granted full access**. A warning is logged to remind administrators to define fine-grained permissions. * Unauthenticated requests are rejected. This ensures that Feast deployments are never accidentally exposed without authentication, while allowing teams to incrementally adopt fine-grained RBAC. #### Disabling Authentication with `noAuth` For development, testing, or environments where authentication is handled externally, you can explicitly disable authentication using the `noAuth` option in the `FeatureStore` CR: ```yaml apiVersion: feast.dev/v1 kind: FeatureStore metadata: name: my-feature-store spec: feastProject: my_project authz: noAuth: true ``` {% hint style="warning" %} Setting `noAuth: true` disables all authentication and authorization. All endpoints become publicly accessible without any identity checks. Only use this for local development or testing environments. For production, use `kubernetes` or `oidc` authentication. {% endhint %} #### Explicit Kubernetes Auth (Default) This is equivalent to the default behavior when no `authz` section is provided: ```yaml apiVersion: feast.dev/v1 kind: FeatureStore metadata: name: my-feature-store spec: feastProject: my_project authz: kubernetes: {} ``` #### OIDC Auth via Operator ```yaml apiVersion: feast.dev/v1 kind: FeatureStore metadata: name: my-feature-store spec: feastProject: my_project authz: oidc: secretRef: name: feast-oidc-secret ``` ### Standalone Deployments (feature\_store.yaml) ## 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](https://github.com/feast-dev/feast/tree/master/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 `no_auth` authorization: ```yaml project: my-project auth: type: no_auth ... ``` {% hint style="warning" %} Running with `auth.type: no_auth` leaves all endpoints unauthenticated. This is suitable for local development only. For production deployments, configure `kubernetes` or `oidc` authentication. {% endhint %} ### 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 user details — including username, roles, and groups — 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 under `resource_access..roles` (Keycloak) or in the top-level `roles` claim (Entra ID app roles). Roles found in both are merged. * The JWT token is expected to have a verified signature and not be expired. The Feast OIDC token parser logic validates for `verify_signature` and `verify_exp` so make sure that the given OIDC provider is configured to meet these requirements. The token's audience and issuer claims are **not** verified by default; both checks can be enabled with the `audience` and `issuer` options (see [Server-Side Configuration](#server-side-configuration)). * The username is read from the first of `preferred_username`, `upn`, `azp`, `appid`, `sub` present in the token. Entra ID client-credentials (app-only) tokens carry no user claim, so they authenticate as the calling application. * For `GroupBasedPolicy` support, the `groups` claim should be present in the access token (requires a "Group Membership" protocol mapper in Keycloak). * **Entra ID limitation**: Group claims use object IDs (GUIDs) instead of names, and are omitted entirely when a user exceeds the group overage threshold. GroupBasedPolicy must reference GUIDs and cannot be used for principals with large group memberships. (\*) 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 and membership in the `data-team` group should have the following claims: ```json { "preferred_username": "alice", "resource_access": { "app": { "roles": [ "reader" ] } }, "groups": [ "data-team" ] } ``` A Microsoft Entra ID (Azure AD) client-credentials (app-only) token has no user claim; the application authenticates as itself, and its app roles arrive in the top-level `roles` claim: ```json { "azp": "11111111-2222-3333-4444-555555555555", "roles": [ "reader" ] } ``` #### Server-Side Configuration The server requires `auth_discovery_url` and `client_id` to validate incoming JWT tokens via JWKS: ```yaml project: my-project auth: type: oidc client_id: _CLIENT_ID_ auth_discovery_url: _OIDC_SERVER_URL_/realms/master/.well-known/openid-configuration ... ``` When the OIDC provider uses a self-signed or untrusted TLS certificate (e.g. internal Keycloak on OpenShift), set `verify_ssl` to `false` to disable certificate verification: ```yaml auth: type: oidc client_id: _CLIENT_ID_ auth_discovery_url: https://keycloak.internal/realms/master/.well-known/openid-configuration verify_ssl: false ``` {% hint style="warning" %} Setting `verify_ssl: false` disables TLS certificate verification for all OIDC provider communication (discovery, JWKS, token endpoint). Only use this in development or internal environments where you accept the security risk. {% endhint %} By default the server verifies only the token's signature and expiry: any validly-signed, unexpired token from the configured provider is accepted regardless of the audience it was minted for, and authorization (role matching) is the only remaining gate. For defense in depth, set `audience` and/or `issuer` to additionally require a matching `aud` / `iss` claim: ```yaml auth: type: oidc client_id: _CLIENT_ID_ auth_discovery_url: https://login.example.com/.well-known/openid-configuration audience: api://feast-feature-server issuer: https://login.example.com/realms/master ``` A token whose `aud` (or `iss`) claim does not match is rejected at authentication. The two options are independent; leave one unset to skip that check. {% hint style="warning" %} Set these to the values your IdP puts **in the token itself**, which are not always the ones in the discovery document. For example, Microsoft Entra ID commonly issues v1.0 tokens (`iss: https://sts.windows.net//`, `aud: api://`) even when `auth_discovery_url` points at the v2.0 endpoint. That setup keeps working with these options unset, or set to the v1.0 values — but copying the v2.0 issuer from the discovery document would reject every v1.0 token. {% endhint %} To validate token signatures the server fetches the provider's JWKS document and caches it, refetching when the cache expires or when a token presents an unknown key id. Two options tune that behavior: ```yaml auth: type: oidc client_id: _CLIENT_ID_ auth_discovery_url: https://login.example.com/.well-known/openid-configuration jwks_cache_lifespan_seconds: 300 # default; how long the fetched key set is reused jwks_request_timeout_seconds: 10 # default; network timeout for the JWKS fetch ``` `jwks_cache_lifespan_seconds` also bounds how long a key the provider has **revoked** continues to validate tokens, so lower it if your provider rotates or revokes aggressively; each reduction costs proportionally more JWKS fetches. Key rotations that introduce a new key id are picked up immediately regardless of this setting, because an unknown key id triggers a refetch. `jwks_request_timeout_seconds` bounds how long an unresponsive provider can block request serving. Both must be greater than zero. #### Client-Side Configuration The client supports multiple token source modes. The SDK resolves tokens in the following priority order: 1. **Intra-communication token** — internal server-to-server calls (via `INTRA_COMMUNICATION_BASE64` env var) 2. **`token`** — a static JWT string provided directly in the configuration 3. **`token_env_var`** — the name of an environment variable containing the JWT 4. **`client_secret`** — fetches a token from the OIDC provider using client credentials or ROPC flow (requires `auth_discovery_url` and `client_id`) 5. **`FEAST_OIDC_TOKEN`** — default fallback environment variable 6. **Kubernetes service account token** — read from `/var/run/secrets/kubernetes.io/serviceaccount/token` when running inside a pod **Token passthrough** (for use with external token providers like [kube-authkit](https://github.com/opendatahub-io/kube-authkit)): ```yaml project: my-project auth: type: oidc token_env_var: FEAST_OIDC_TOKEN ``` Or with a bare `type: oidc` (no other fields) — the SDK falls back to the `FEAST_OIDC_TOKEN` environment variable or a mounted Kubernetes service account token: ```yaml project: my-project auth: type: oidc ``` **Client credentials / ROPC flow** (existing behavior, unchanged): ```yaml project: my-project auth: type: oidc client_id: test_client_id client_secret: test_client_secret username: test_user_name password: test_password auth_discovery_url: http://localhost:8080/realms/master/.well-known/openid-configuration ``` When using client credentials or ROPC flows, the `verify_ssl` setting also applies to the discovery and token endpoint requests. #### Multi-Token Support (OIDC + Kubernetes Service Account) When the Feast server is configured with OIDC auth and deployed on Kubernetes, the `OidcTokenParser` can handle both Keycloak JWT tokens and Kubernetes service account tokens. Incoming tokens that contain a `kubernetes.io` claim are validated via the Kubernetes Token Access Review API and the namespace is extracted from the authenticated identity — no RBAC queries are performed, so the server service account only needs `tokenreviews/create` permission. All other tokens follow the standard OIDC/Keycloak JWKS validation path. This enables `NamespaceBasedPolicy` enforcement for service account tokens while using `GroupBasedPolicy` and `RoleBasedPolicy` for OIDC user tokens. ### 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. 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. 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 user\_token: #Optional, else service account token Or env var is used for getting the token ... \`\`\` 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/groups/namespaces. More details can be found in [Setting up kubernetes doc](/master/reference/kubernetes_auth_setup.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.feast.dev/master/getting-started/components/authz_manager.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.