Feast Authentication and Authorization Options: OIDC, Kubernetes RBAC, and No-Auth Configuration

Feast supports three built-in authentication modes—no authentication (no_auth), OpenID Connect (OIDC), and Kubernetes RBAC—that integrate with a pluggable authorization manager to enforce role, group, or namespace-based permissions at the API level.

The feast-dev/feast repository implements a flexible authentication framework configured through feature_store.yaml. This system extracts user identity from incoming requests and evaluates it against registry-stored permissions before allowing access to feature data.

Built-in Authentication Modes

Feast provides three distinct authentication strategies, each defined in sdk/python/feast/permissions/auth_model.py and validated through ALLOWED_AUTH_TYPES in sdk/python/feast/repo_config.py.

No Authentication (no_auth)

no_auth disables all token handling and permission checks, accepting every request without validation.

• Configuration: Set auth: {type: no_auth} in feature_store.yaml
• Implementation: NoAuthConfig class in sdk/python/feast/permissions/auth_model.py
• Use case: Local development, CI/CD pipelines, and single-node testing environments

OpenID Connect (OIDC) Authorization

OIDC authentication enables JWT-based security using external identity providers such as Keycloak, Auth0, or Azure AD. Clients obtain access tokens from the provider and transmit them as bearer tokens on each request.

• Server-side configuration: auth: {type: oidc, auth_discovery_url: "...", client_id: "..."}
• Client-side configuration: Supports three credential flows via OidcClientAuthConfig:
  1. Static token: Directly provide a token field
  2. Client-credentials flow: Provide client_secret (machine-to-machine)
  3. Resource Owner Password Grant (ROPG): Provide username, password, and client_secret
• Token processing: OidcTokenParser in sdk/python/feast/permissions/auth/oidc_token_parser.py validates JWT signatures, expiration, and extracts roles from the resource_access claim
• Client management: OidcAuthClientManager handles token exchange and refresh

Kubernetes RBAC Authorization

Kubernetes authentication leverages service-account tokens automatically mounted in pods. Feast calls the Kubernetes TokenAccessReview API to discover the service-account's groups, namespaces, and bound roles.

• Configuration: auth: {type: kubernetes, user_token: <optional>} (omit user_token to use the pod's default service-account token)
• Implementation: KubernetesAuthConfig class in sdk/python/feast/permissions/auth_model.py
• Use case: Production deployments inside Kubernetes clusters where you want to reuse existing RBAC policies for intra-cluster services

How the Authorization Pipeline Works

Feast authorizes requests through a multi-stage pipeline implemented in the permissions server utilities:

1. Configuration parsing: When a Feast server starts, RepoConfig reads the auth block from feature_store.yaml and instantiates the appropriate auth configuration class.

2. Token extraction: The AuthManager delegates to a TokenExtractor implementation (e.g., OidcTokenExtractor or KubernetesTokenExtractor) to retrieve the bearer token from the HTTP request headers.

3. Token parsing:

   • For OIDC, OidcTokenParser verifies the JWT against the discovery URL and extracts role information.
   • For Kubernetes, the parser executes a TokenAccessReview to retrieve the service-account's group memberships and namespace bindings.

4. Permission evaluation: The extracted user attributes feed into the Permission Engine (feast.permissions.server.utils). This engine compares the requester's roles against Permission objects stored in the registry (documented in docs/reference/registry/registry-permissions.md).

5. Enforcement: Every API endpoint in the Feast server checks the current request's permission context before performing create, read, update, or delete operations on feature views, entities, or data sources.

Configuration Examples

Server-Side OIDC Configuration

project: my-project
registry:
  path: data/registry.db
online_store:
  type: sqlite
auth:
  type: oidc
  auth_discovery_url: https://keycloak.example.com/realms/feast/.well-known/openid-configuration
  client_id: feast-server

The server creates an OidcAuthManager at startup and validates every incoming bearer token against the specified discovery endpoint.

Server-Side Kubernetes RBAC Configuration

project: my-project
registry:
  path: data/registry.db
online_store:
  type: sqlite
auth:
  type: kubernetes

If you omit user_token, Feast automatically extracts the token from /var/run/secrets/kubernetes.io/serviceaccount/token inside the pod.

Client-Side OIDC (Client-Credentials Flow)

project: my-project
registry:
  registry_type: remote
  path: feast-registry.example.com:80
online_store:
  type: remote
  path: http://feast-feature-server.example.com:80
auth:
  type: oidc
  auth_discovery_url: https://keycloak.example.com/realms/feast/.well-known/openid-configuration
  client_id: feast-client
  client_secret: <secret-value>

from feast import FeatureStore

store = FeatureStore(repo_path=".")

# The client automatically exchanges client_secret for a token

features = store.get_online_features(
    feature_refs=["driver:rating"],
    entity_rows=[{"driver_id": 1001}]
).to_df()

Client-Side Kubernetes (In-Cluster)

project: my-project
registry:
  registry_type: remote
  path: feast-registry.default.svc:80
online_store:
  type: remote
  path: http://feast-feature-server.default.svc:80
auth:
  type: kubernetes

from feast import FeatureStore

store = FeatureStore(repo_path=".")

# No explicit credentials; SDK reads the pod's service-account token

features = store.get_online_features(
    feature_refs=["driver:rating"],
    entity_rows=[{"driver_id": 1001}]
).to_df()

Disabling Authentication

project: quick-start
registry:
  path: data/registry.db
online_store:
  type: sqlite
auth:
  type: no_auth

Summary

• Feast implements a pluggable authorization manager that supports no_auth, OIDC, and Kubernetes RBAC modes configured via feature_store.yaml.
• OIDC integration in sdk/python/feast/permissions/auth/oidc_token_parser.py validates external JWTs and extracts role claims for cross-cluster authentication.
• Kubernetes RBAC leverages in-cluster service-account tokens and the TokenAccessReview API to enforce namespace and group-based permissions.
• The Permission Engine evaluates every API request against registry-stored permissions after extracting and parsing the authentication token.
• For mixed environments, use OIDC for external clients and Kubernetes auth for intra-cluster services, configuring each component's auth block independently.

Frequently Asked Questions

What is the default authentication mode in Feast?

If you do not specify an auth block in feature_store.yaml, Feast defaults to no_auth, which disables all permission checks and accepts every request. This is suitable for development but should be explicitly changed to oidc or kubernetes for production deployments.

Can OIDC and Kubernetes authentication be used simultaneously?

Yes. You can configure different Feast components with different auth types depending on their deployment context. For example, configure the feature server with type: oidc to accept external client tokens, while clients running inside the Kubernetes cluster use type: kubernetes to authenticate with their service-account tokens. Each component reads its own feature_store.yaml configuration independently.

How does Feast validate OIDC tokens?

Feast validates OIDC tokens in sdk/python/feast/permissions/auth/oidc_token_parser.py. The parser fetches the JSON Web Key Set (JWKS) from the auth_discovery_url, verifies the JWT signature and expiration, and extracts the resource_access claim to determine the user's roles. These roles are then matched against Feast Permission objects to authorize the requested operation.

Where are permissions defined in Feast?

Permissions are stored in the Feast registry and evaluated by the Permission Engine at runtime. As documented in docs/reference/registry/registry-permissions.md, you define permissions that map roles, groups, or namespaces to specific resources (feature views, data sources, entities) and actions (read, write, delete). The server checks these permissions after authenticating the request but before executing the operation.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}