Role-based access control

Configure Flyte project and domain permissions, map OIDC claims to Flyte roles, and manage admin-level vs project-level access.

Flyte’s access control model is organized around projects and domains. Each project can have multiple domains (e.g., development, staging, production). Authentication is enforced via OIDC, and authorization maps identity claims to Flyte roles.

Access control model

Flyte has two levels of access:

Level	Description
Admin	Full access to all projects and domains. Can create/delete projects, manage system configuration.
Project	Access scoped to one or more projects. Can register and execute workflows within assigned projects.

Fine-grained row-level authorization (e.g., restricting specific workflows) is not currently supported out-of-the-box in open-source Flyte. Authorization control is at the project level.

Configuring admin access

Admin-level access is granted by setting the appAuth.thirdPartyConfig.flyteClient in the FlyteAdmin config. Any user whose OIDC token contains an admin claim is granted full access.

flyte-binary

Add to configuration.inline in your values.yaml:

configuration:
  inline:
    auth:
      appAuth:
        thirdPartyConfig:
          flyteClient:
            clientId: flytectl
            redirectUri: http://localhost:53593/callback
            scopes:
              - offline
              - all

Project-level access via OIDC claims

Flyte can extract user identity from OIDC token claims and use them to determine project access. The relevant config is in userAuth.openId:

configuration:
  inline:
    auth:
      userAuth:
        openId:
          baseUrl: https://dev-<org-id>.okta.com/oauth2/default
          clientId: <client_ID>
          scopes:
            - profile
            - openid
            - groups    # Request group claims from the IdP

Setting the claims field

FlyteAdmin extracts the user’s identity from the OIDC sub claim by default. To use a different claim (e.g., email or preferred_username):

configuration:
  inline:
    auth:
      userAuth:
        openId:
          # Claim to use as the principal identity
          claimsFieldPath: email

Configuring resource attributes per project/domain

Flyte supports setting resource attributes (CPU limits, memory limits, IAM roles) at the project and domain level using matchable_resources. These are configured via flytectl:

# Set default CPU/memory limits for a project domain
flytectl update task-resource-attribute \
  --project flytesnacks \
  --domain production \
  --cpuRequest 500m \
  --cpuLimit 2 \
  --memoryRequest 256Mi \
  --memoryLimit 4Gi

# Assign an IAM role to all tasks in a project domain (AWS)
flytectl update cluster-resource-attribute \
  --project flytesnacks \
  --domain production \
  --attributes '{"defaultIamRole": "arn:aws:iam::123456:role/task-role"}'

Creating and managing projects

By default, Flyte creates a flytesnacks project at startup. Create additional projects:

flytectl create project \
  --id ml-team \
  --name "ML Team" \
  --description "Machine learning team workflows"

To pre-create projects via Helm:

flyte-core-components:
  admin:
    seedProjects:
      - flytesnacks
      - ml-team
      - data-engineering
    seedProjectsWithDetails:
      - name: ml-team
        description: Machine learning team workflows
      - name: data-engineering
        description: Data engineering pipelines

Kubernetes RBAC for Flyte namespaces

Flyte automatically creates Kubernetes namespaces in the format <project>-<domain> (e.g., ml-team-production). Task pods run in these namespaces.

The clusterResourceTemplates in Helm values controls what Kubernetes resources get created in each namespace:

clusterResourceTemplates:
  inline:
    001_namespace.yaml: |
      apiVersion: v1
      kind: Namespace
      metadata:
        name: '{{ namespace }}'
    # Optional: create a RoleBinding granting team members access
    003_rolebinding.yaml: |
      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: team-members
        namespace: '{{ namespace }}'
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: ClusterRole
        name: view
      subjects:
        - kind: Group
          name: ml-team
          apiGroup: rbac.authorization.k8s.io

Service account per project domain

Each project-domain namespace gets a default service account, which is used by task pods. Annotate this account for cloud IAM integration:

clusterResourceTemplates:
  inline:
    002_serviceaccount.yaml: |
      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: default
        namespace: '{{ namespace }}'
        annotations:
          eks.amazonaws.com/role-arn: '{{ defaultIamRole }}'  # AWS
          # iam.gke.io/gcp-service-account: '{{ gsa }}'       # GCP

Listing and inspecting access

# List all projects
flytectl get project

# Get project details
flytectl get project ml-team

# List execution access attributes
flytectl get task-resource-attribute --project ml-team --domain production

# List cluster resource attributes
flytectl get cluster-resource-attribute --project ml-team --domain production