← 返回首页
Kubernetes auth setup | Feast: the Open Source Feature Store
Ctrlk
GitBook Assistant
GitBook Assistant
GitBook Assistant
arrow-up-right-and-arrow-down-left-from-center
GitBook Assistant
Good night

I'm here to help you with the docs.

What is this page about?What should I read next?Can you give an example?
Ctrli
AI Based on your context
Send
v0.64-branch
Powered by GitBook
On this page
For the complete documentation index, see llms.txt. This page is also available as Markdown.
GitBook AssistantAsk
On this page
  1. Reference

Kubernetes auth setup

This document describes the authentication and authorization capabilities in Feast that support groups, namespaces and roles extraction from Kubernetes tokens.

Overview

Feast supports extracting user groups, namespaces and roles of both Service Account and User from Kubernetes authentication tokens. This allows for more granular access control based on:

  • Groups: User groups associated directly with User/SA and from associated namespace

  • Namespaces: Kubernetes namespaces associated with User/SA

  • Roles: Kubernetes roles associated with User/SA

Key Features

Setting Up Kubernetes RBAC for Feast

Role based auth setup

To ensure the Kubernetes RBAC environment aligns with Feast's RBAC configuration, follow these guidelines:

  • The roles defined in Feast Permission instances must have corresponding Kubernetes RBAC Role names.

  • The Kubernetes RBAC Role must reside in the same namespace as the Feast service.

  • The client application can run in a different namespace, using its own dedicated ServiceAccount.

  • Finally, the RoleBinding that links the client ServiceAccount to the RBAC Role must be defined in the namespace of the Feast service.

Group and Namespace based auth setup

To ensure the Kubernetes RBAC environment aligns with Feast's RBAC configuration, follow these guidelines:

  • The groups and namespaces defined in Feast Permission instances must have corresponding Kubernetes Group and Namespace names.

  • The user or service account must reside in the group or namespace defined in the Feast Permission instances.

  • The client application can run in a different namespace, using its own dedicated ServiceAccount or user.

  • Finally, the feast service grants access based on the group and namespace association defined in the Feast Permission instances.

Policy Types

RoleBasedPolicy

Grants access based on user role membership.

GroupBasedPolicy

Grants access based on user group membership.

NamespaceBasedPolicy

Grants access based on user namespace association.

CombinedGroupNamespacePolicy

Grants access only when user is added into either permitted groups OR namespaces.

Configuration

Server Configuration

The server automatically extracts groups, namespaces and roles when using Kubernetes authentication. No additional configuration is required beyond the existing Kubernetes auth setup.

Client Configuration

For external users (not service accounts), you can provide a user token in the configuration:

Refer examples of providing the token are described in doc User Token Provisioning

Usage Examples

Basic Permission Setup

Applying Permissions

Run feast apply from CLI/API/SDK on server or from client(if permitted) to apply the permissions.

Troubleshooting

Common Issues

  1. Token Access Review Fails

    • Check that the Feast server has the required RBAC permissions

    • Verify the token is valid and not expired

    • Check server logs for detailed error messages in debug mode

  2. Groups/Namespaces Not Extracted

    • Verify the token contains the expected claims

    • Check that the user is properly configured in Kubernetes/ODH/RHOAI

  3. Permission Denied

    • Verify the user is added to required groups/namespaces Or has the required role assigned

    • Check that the policy is correctly configured

    • Review the permission evaluation logs

Migration Guide

From Role-Based to Group/Namespace-Based

  1. Identify User Groups: Determine which groups your users belong to

  2. Map Namespaces: Identify which namespaces users should have access to

  3. Create New Policies: Define group-based and namespace-based policies

  4. Test Gradually: Start with read-only permissions and gradually expand

  5. Monitor: Watch logs to ensure proper authentication and authorization

Best Practices

  1. Principle of Least Privilege: Grant only the minimum required permissions

  2. Group Organization: Organize users into logical groups based on their responsibilities

  3. Namespace Isolation: Use namespaces to isolate different environments or teams

  4. Regular Audits: Periodically review and audit permissions

Related Documentation

PreviousRegistration inferencingNextUser token provisioning

Last updated 22 days ago

Was this helpful?