Role-Based Access Control (RBAC)¶

RBAC Model¶

Access to resources is managed very much like AWS IAM.

There are five basic components to the system:

1. Users - Representing entities that access and use the system. A user is given one or more Access Credentials for authentication.
2. Actions - Representing a logical action within the system - reading a file, creating a repository, etc.
3. Resources - A unique identifier representing a specific resource in the system - a repository, an object, a user, etc.
4. Policies - Representing a set of Actions, a Resource and an effect: whether or not these actions are allowed or denied for the given resource(s).
5. Groups - A named collection of users. Users can belong to multiple groups.

Controlling access is done by attaching Policies, either directly to Users, or to Groups they belong to.

Authorization process¶

Every action in the system - be it an API request, UI interaction, S3 Gateway call, or CLI command - requires a set of actions to be allowed for one or more resources.

When a user makes a request to perform that action, the following process takes place:

1. Authentication - the credentials passed in the request are evaluated and the user's identity is extracted.
2. Action permission resolution - lakeFS then calculates the set of allowed actions and resources that this request requires.
3. Effective policy resolution - the user's policies (either attached directly or through group memberships) are calculated.
4. Policy/Permission evaluation - lakeFS will compare the given user policies with the request actions and determine whether or not the request is allowed to continue.

Policy Precedence¶

Each policy attached to a user or a group has an Effect - either allow or deny. During evaluation of a request, deny would take precedence over any other allow policy.

This helps us compose policies together. For example, we could attach a very permissive policy to a user and use deny rules to then selectively restrict what that user can do.

Policy Conditions¶

lakeFS policies support optional conditions that provide additional control over when a policy statement is in effect.

Conditions are specified using condition operators that evaluate to true or false based on the request context. When a condition evaluates to false, the policy statement does not apply.

Condition Structure¶

Conditions are added to policy statements using the optional condition field:

{
  "statement": [
    {
      "action": ["fs:ReadObject"],
      "effect": "allow",
      "resource": "arn:lakefs:fs:::repository/myrepo/object/*",
      "condition": {
        "IpAddress": {
          "SourceIp": ["203.0.113.0/24", "198.51.100.25/32"]
        }
      }
    }
  ]
}

Supported Condition Operators¶

IpAddress / NotIpAddress¶

The IpAddress condition operator matches the client's source IP address against one or more IP addresses or CIDR blocks. The NotIpAddress condition operator matches when the client's source IP address does NOT match any of the specified IP addresses or CIDR blocks (negation of IpAddress).

Supported Fields:

• SourceIp - The IP address of the client making the request

Value Format: - Single IP address: "203.0.113.5" - CIDR notation: "203.0.113.0/24" - Array of IPs and/or CIDRs: ["203.0.113.0/24", "198.51.100.25/32"]

Example - Allow access only from specific IP range:

{
  "statement": [
    {
      "action": ["fs:*"],
      "effect": "allow",
      "resource": "*",
      "condition": {
        "IpAddress": {
          "SourceIp": ["10.0.0.0/8", "172.16.0.0/12"]
        }
      }
    }
  ]
}

Example - Deny access from specific IPs:

{
  "statement": [
    {
      "action": ["fs:*"],
      "effect": "deny",
      "resource": "*",
      "condition": {
        "IpAddress": {
          "SourceIp": ["192.0.2.0/24"]
        }
      }
    }
  ]
}

Example - Deny access from IPs NOT in allowed ranges:

{
  "statement": [
    {
      "action": ["fs:*"],
      "effect": "deny",
      "resource": "*",
      "condition": {
        "NotIpAddress": {
          "SourceIp": ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"]
        }
      }
    }
  ]
}

IP Address Extraction:

The address that SourceIp evaluates is the client IP lakeFS resolves for the request, which is configured under Client IP resolution.

StringEquals / StringNotEquals¶

The StringEquals condition operator matches a context value against one or more exact strings. The StringNotEquals condition operator matches when the context value does NOT equal any of the specified strings (negation of StringEquals).

StringLike / StringNotLike¶

The StringLike condition operator matches a context value against one or more wildcard patterns. The StringNotLike condition operator matches when the context value does NOT match any of the specified patterns (negation of StringLike).

Wildcard characters: * matches zero or more characters, ? matches exactly one character.

Attribute-Based Access Control for Repositories¶

Beyond role-based access, lakeFS supports attribute-based access control (ABAC): policy conditions that gate access based on attributes of the repository being accessed. This lets you enforce data governance policies automatically — for example, restricting access to PII or production repositories — without managing a separate policy per repository.

ABAC conditions can use user-defined metadata on repositories to filter. You attach key-value tags to repositories (e.g. env=staging, team=data-platform, classification=pii) and then reference those tags in policy conditions.

Managing repository metadata¶

Set (merge) metadata on a repository using the lakeFS REST API. Keys not included in the request are preserved — this is a merge, not a replacement:

curl -X POST https://<lakefs-host>/api/v1/repositories/<repo>/metadata \
  -H "Content-Type: application/json" \
  -u ${LAKECTL_CREDENTIALS_ACCESS_KEY_ID}:${LAKECTL_CREDENTIALS_SECRET_ACCESS_KEY} \
  -d '{"metadata": {"env": "staging", "team": "data-platform", "classification": "pii"}}'

Read metadata back to verify what is set:

curl -X POST https://$LAKECTL_SERVER_ENDPOINT/api/v1/repositories/<repo>/metadata \
  -u ${LAKECTL_CREDENTIALS_ACCESS_KEY_ID}:${LAKECTL_CREDENTIALS_SECRET_ACCESS_KEY} \

Delete specific metadata keys:

curl -X DELETE https://<lakefs-host>/api/v1/repositories/<repo>/metadata \
  -H "Content-Type: application/json" \
  -u ${LAKECTL_CREDENTIALS_ACCESS_KEY_ID}:${LAKECTL_CREDENTIALS_SECRET_ACCESS_KEY} \
  -d '{"keys": ["classification"]}'

Condition key format¶

lakefs:RepositoryMetadata/<metadata-key>

The <metadata-key> maps directly to a key in the repository's metadata. Matching is case-sensitive — lakefs:RepositoryMetadata/env matches only the metadata key env.

Examples¶

Allow read access only to repositories tagged env=staging¶

{
  "statement": [
    {
      "action": ["fs:ReadObject", "fs:ListObjects", "fs:ReadRepository"],
      "effect": "allow",
      "resource": "arn:lakefs:fs:::repository/*",
      "condition": {
        "StringLike": {
          "lakefs:RepositoryMetadata/env": ["staging"]
        }
      }
    }
  ]
}

Deny access to PII repositories, combined with a broad allow¶

The most common ABAC pattern is to grant a user a broad role (e.g. FSReadAll) and then attach an additional policy that denies access to sensitive repositories. Since deny takes precedence over allow, this ensures the restriction holds regardless of what other policies the user has.

{
  "statement": [
    {
      "action": ["fs:*"],
      "effect": "deny",
      "resource": "arn:lakefs:fs:::repository/*",
      "condition": {
        "StringLike": {
          "lakefs:RepositoryMetadata/classification": ["pii"]
        }
      }
    }
  ]
}

Attach this policy alongside FSReadAll (or any other broad policy): the user can access all repositories except those tagged classification=pii.

Combine multiple metadata keys¶

When a condition block contains multiple keys, all of them must match for the statement to apply. Multiple values within a single key are evaluated as OR (any match is sufficient):

{
  "statement": [
    {
      "action": ["fs:ReadObject", "fs:ListObjects"],
      "effect": "allow",
      "resource": "arn:lakefs:fs:::repository/*",
      "condition": {
        "StringLike": {
          "lakefs:RepositoryMetadata/team": ["ml"],
          "lakefs:RepositoryMetadata/env": ["staging", "dev"],
          "lakefs:RepositoryMetadata/classification": ["public"]
        }
      }
    }
  ]
}

This grants access only to repositories where team=ml and (env=staging or env=dev) and classification=public.

Behavior notes¶

• If a repository has no metadata, or if the requested key is absent, the condition evaluates to false and the statement does not apply.
• Condition keys are case-sensitive: lakefs:RepositoryMetadata/ENV does not match the metadata key env.

Attribute-Based Access Control for Objects¶

lakeFS also supports attribute-based access control (ABAC) for objects: policy conditions that gate access based on user-defined metadata attached to the object itself, rather than the repository as a whole. This lets you scope access more precisely than a repository-wide tag allows — for example, matching objects tagged classification=public while leaving the rest of the same repository untouched.

Object-level ABAC applies to read operations only — fs:ReadObject on GetObject, HeadObject, StatObject, and GetUnderlyingProperties, as well as the read side of object copy operations. It does not apply to writes or deletes, and fs:ListObjects does not filter listing results by object metadata (see the behavior notes below for how presigned listings interact with per-object conditions).

Setting object metadata¶

Object metadata is set at upload time using x-lakefs-meta-* request headers; each header becomes one metadata key on the object (keys are lower-cased):

curl -X POST "https://<lakefs-host>/api/v1/repositories/<repo>/branches/<branch>/objects?path=<path>" \
  -H "x-lakefs-meta-classification: public" \
  -H "x-lakefs-meta-owner: data-platform" \
  -u ${LAKECTL_CREDENTIALS_ACCESS_KEY_ID}:${LAKECTL_CREDENTIALS_SECRET_ACCESS_KEY} \
  --data-binary @localfile

Metadata set this way is returned in the metadata field of StatObject and GetObject responses, and in ListObjects results unless the request sets user_metadata=false. The S3 gateway uses the standard x-amz-meta-* header convention instead of x-lakefs-meta-*, returned the same way on GetObject/HeadObject responses. Note that S3-gateway metadata keys are stored with the X-Amz-Meta- prefix and a lower-cased key part (e.g. X-Amz-Meta-classification), so the matching condition key is lakefs:ObjectMetadata/X-Amz-Meta-classification — not the bare key you get from the REST API convention above.

Condition key format¶

lakefs:ObjectMetadata/<metadata-key>

The <metadata-key> maps directly to a key in the object's metadata. Matching is case-sensitive — lakefs:ObjectMetadata/classification matches only the metadata key classification.

Object metadata conditions accept the same condition operators as any other policy condition — StringEquals, StringNotEquals, StringLike, and StringNotLike.

Metadata keys that lakeFS manages internally (mtime tracking, symlink targets, POSIX permissions, shallow-copy provenance) are never exposed through lakefs:ObjectMetadata/, even though they live in the same metadata map as your own tags — only metadata you set yourself is available to conditions.

Examples¶

Allow read access only to objects tagged classification=public¶

{
  "statement": [
    {
      "action": ["fs:ReadObject"],
      "effect": "allow",
      "resource": "arn:lakefs:fs:::repository/myrepo/object/*",
      "condition": {
        "StringEquals": {
          "lakefs:ObjectMetadata/classification": ["public"]
        }
      }
    }
  ]
}

Deny read access to objects tagged contains_pii=true, combined with a broad allow¶

{
  "statement": [
    {
      "action": ["fs:ReadObject"],
      "effect": "deny",
      "resource": "arn:lakefs:fs:::repository/myrepo/object/*",
      "condition": {
        "StringEquals": {
          "lakefs:ObjectMetadata/contains_pii": ["true"]
        }
      }
    }
  ]
}

Attach this policy alongside a broader read policy: the user can read every object in myrepo except those tagged contains_pii=true. Note that this shape lets a caller distinguish a tagged object from one that does not exist; see the behavior notes below.

Combine repository and object metadata conditions¶

Repository-level and object-level ABAC conditions can be used together in the same statement — all specified keys must match:

{
  "statement": [
    {
      "action": ["fs:ReadObject"],
      "effect": "allow",
      "resource": "arn:lakefs:fs:::repository/*/object/*",
      "condition": {
        "StringEquals": {
          "lakefs:RepositoryMetadata/env": ["staging"],
          "lakefs:ObjectMetadata/classification": ["public"]
        }
      }
    }
  ]
}

Behavior notes¶

• Object-level ABAC is scoped to reads. fs:ListObjects does not evaluate object-metadata conditions — a listing returns every object the caller has repository-level access to, regardless of any per-object condition. Listing with presign=true is the exception: each result's presigned URL is minted under fs:ReadObject, so a condition-denied object still appears in the listing but receives no presigned URL.
• If an object has no metadata, or the requested key is absent, the condition evaluates to false and the statement does not apply. A key that exists with an empty string value is different: it's an ordinary match target, so "StringEquals": {"lakefs:ObjectMetadata/tag": [""]} matches an object where tag is set to an empty value.
• Whether a denial reveals that an object exists depends on the policy shape. Under a conditioned allow, a missing object has no metadata to satisfy the condition, so it is denied exactly like an object the caller may not read. Under a broad allow paired with a conditioned deny, the deny cannot match an object that does not exist, so a missing path returns not-found (404, or NoSuchKey on the S3 gateway) while a denied one returns access-denied, revealing both that the object exists and that it carries the denied value. Use a conditioned allow where existence must not be disclosed.
• Condition keys are case-sensitive: lakefs:ObjectMetadata/CLASSIFICATION does not match the metadata key classification.
• Object-level ABAC is designed for read actions; conditioning a write action (e.g. fs:WriteObject) on lakefs:ObjectMetadata/* is not a supported combination. On the S3 gateway's copy path (a PUT carrying x-amz-copy-source), the destination-write and source-read permissions are checked together against one set of attributes, so a write-side object-metadata condition used there would be evaluated against the copy source's metadata, not the destination's.
• On the S3 gateway copy path, repository attributes come from the destination repository. If the copy source is in a different repository, a lakefs:RepositoryMetadata/* condition is checked against the destination repository's metadata, not the source's. To block copying out of a repository, use a resource ARN instead of a repository-metadata condition.

Resource naming - ARNs¶

lakeFS uses ARN identifier - very similar in structure to those used by AWS. The resource segment of the ARN supports wildcards: use * to match 0 or more characters, or ? to match exactly one character.

Here are a some examples of valid ARNs within lakeFS and their meaning:

Note that Iceberg catalog ARNs are branch-agnostic, the branch is not part of the ARN. A policy granting access to a namespace, a table or a view applies to that resource on every branch in the repository.

Additionally, the current user's ID is interpolated in runtime into the ARN using the ${user} placeholder.

Scoping a policy to a tenant¶

The fifth colon-separated field of an ARN is the account segment, which is empty in all of the examples above. On fs: ARNs that segment carries the name of a tenant, so a policy can be pinned to one tenant's data. It behaves as follows:

An omitted segment means every tenant rather than the root tenant, which is what keeps policies written before tenants were in use working exactly as they did. Write root in the segment only when you specifically want a grant that applies to the root tenant and to no other. Keep in mind that pinning a policy to a tenant narrows a grant but does not confer access on its own, since reaching a tenant's data also requires membership of that tenant.

The account segment carries tenant meaning for fs: ARNs only. Tenants themselves are auth: resources whose ARNs identify a tenant through the resource path, as in arn:lakefs:auth:::tenant/team-a, and the account segment stays empty there.

This allows us to create fine-grained policies affecting only a specific subset of resources.

See below for a full reference of ARNs and actions.

Actions and Permissions¶

For the full list of actions and their required permissions, see the following table:

Some APIs may require more than one action. For instance, to create a repository (POST /repositories), you need permission to fs:CreateRepository for the name of the repository and also fs:AttachStorageNamespace for the storage namespace used.

Per-branch scoping for ListBranches¶

fs:ListBranches accepts either a repo ARN (arn:lakefs:fs:::repository/{repositoryId}, admits every branch in the repository) or a per-branch ARN (arn:lakefs:fs:::repository/{repositoryId}/branch/{branchId}, admits only matching branches), so policies can scope listings to a subset of branches. Listing first requires authorization to list that repository, then filters the branches you may see: a Deny on the repo ARN (or no Allow scoped to the repository) is an operation-level rejection, while a Deny on a branch ARN only hides the matching branches.

Allows are additive — adding a narrower Allow alongside a broader one does not tighten the result set. To restrict what a user sees, either replace the broad Allow with the narrower one, or keep the broad Allow and add a Deny for the subset to hide.

Confine a user to one team's branches:

{
  "Effect":   "Allow",
  "Action":   ["fs:ListBranches", "fs:ReadBranch"],
  "Resource": "arn:lakefs:fs:::repository/myrepo/branch/team-a-*"
}

Allow every branch except a subset (broad allow on the repo, targeted deny on the pattern to hide):

[
  {
    "Effect":   "Allow",
    "Action":   ["fs:ListBranches"],
    "Resource": "arn:lakefs:fs:::repository/myrepo"
  },
  {
    "Effect":   "Deny",
    "Action":   ["fs:ListBranches"],
    "Resource": "arn:lakefs:fs:::repository/myrepo/branch/secret-*"
  }
]

Notes.

• A user authorized to list the repository whose filter admits no branch — for example an allow on …/branch/team-z-* with no matching branch — receives 200 OK with an empty list.
• The 401/403 response is the same whether or not the repository exists, so the listing cannot be used to discover repository names.
• A user whose only allows are per-branch ARNs that don't match the repo's default branch will not see the default branch in the listing (default_branch on GetRepository still reports its name).
• The S3 gateway's bucket-root listing (aws s3 ls s3://{repo}/) uses the same evaluation and does not require a separate fs:ListObjects permission for the branch-listing case.

Preconfigured Policies¶

The following Policies are created during initial setup:

FSFullAccess¶

{
  "statement": [
    {
      "action": [
        "fs:*"
      ],
      "effect": "allow",
      "resource": "*"
    }
  ]
}

FSReadAll¶

{
  "statement": [
    {
      "action": [
        "fs:List*",
        "fs:Read*"
      ],
      "effect": "allow",
      "resource": "*"
    }
  ]
}

FSReadWriteAll¶

{
    "statement": [
        {
            "action": [
                "fs:Read*",
                "fs:List*",
                "fs:WriteObject",
                "fs:DeleteObject",
                "fs:RevertBranch",
                "fs:CreateBranch",
                "fs:CreateTag",
                "fs:DeleteBranch",
                "fs:DeleteTag",
                "fs:CreateCommit"
            ],
            "effect": "allow",
            "resource": "*"
        }
    ]
}

AuthFullAccess¶

{
  "statement": [
    {
      "action": [
        "auth:*"
      ],
      "effect": "allow",
      "resource": "*"
    }
  ]
}

AuthManageOwnCredentials¶

{
  "statement": [
    {
      "action": [
        "auth:CreateCredentials",
        "auth:DeleteCredentials",
        "auth:ListCredentials",
        "auth:ReadCredentials"
      ],
      "effect": "allow",
      "resource": "arn:lakefs:auth:::user/${user}"
    }
  ]
}

RepoManagementFullAccess¶

{
    "statement": [
        {
            "action": [
                "ci:*"
            ],
            "effect": "allow",
            "resource": "*"
        },
        {
            "action": [
                "retention:*"
            ],
            "effect": "allow",
            "resource": "*"
        }
    ]
}

RepoManagementReadAll¶

{
    "statement": [
        {
            "action": [
                "ci:Read*"
            ],
            "effect": "allow",
            "resource": "*"
        },
        {
            "action": [
                "retention:Get*"
            ],
            "effect": "allow",
            "resource": "*"
        }
    ]
}

AdminFullAccess (lakeFS Cloud only)¶

{
  "statement": [
    {
      "action": [
        "admin:*"
      ],
      "effect": "allow",
      "resource": "*"
    }
  ]
}

AuditLogRead¶

Grants read access to the lakeFS audit log. Attached to the Admins group by default. Attach it to other groups or users to delegate audit-log visibility.

{
    "statement": [
        {
            "action": [
                "audit:ReadAuditLog"
            ],
            "effect": "allow",
            "resource": "arn:lakefs:audit:::log"
        }
    ]
}

DatasetsFullAccess¶

Grants full access to all dataset operations. See Datasets.

{
  "statement": [
    {
      "action": [
        "dataset:*"
      ],
      "effect": "allow",
      "resource": "arn:lakefs:dataset:::dataset/*"
    }
  ]
}

DatasetsReadWriteAll¶

Grants list, read, create, update, and delete access to datasets, plus read access to metadata keys.

{
  "statement": [
    {
      "action": [
        "dataset:ListDatasets",
        "dataset:ReadDataset",
        "dataset:CreateDataset",
        "dataset:UpdateDataset",
        "dataset:DeleteDataset",
        "dataset:ListMetadataKeys",
        "dataset:ReadMetadataKey"
      ],
      "effect": "allow",
      "resource": "arn:lakefs:dataset:::dataset/*"
    }
  ]
}

DatasetsReadAll¶

Grants read-only access to datasets and metadata keys.

{
  "statement": [
    {
      "action": [
        "dataset:ListDatasets",
        "dataset:ReadDataset",
        "dataset:ListMetadataKeys",
        "dataset:ReadMetadataKey"
      ],
      "effect": "allow",
      "resource": "arn:lakefs:dataset:::dataset/*"
    }
  ]
}

DatasetsManageMetadataKeys¶

Grants full CRUD on dataset metadata key definitions.

{
  "statement": [
    {
      "action": [
        "dataset:ListMetadataKeys",
        "dataset:ReadMetadataKey",
        "dataset:CreateMetadataKey",
        "dataset:UpdateMetadataKey",
        "dataset:DeleteMetadataKey"
      ],
      "effect": "allow",
      "resource": "arn:lakefs:dataset:::dataset/*"
    }
  ]
}

Tenant Administration Policies¶

Managing tenants is governed by the auth:*Tenant* actions on tenant ARNs, and the two policies below are recipes that put them to use. Unlike the policies listed above, neither one is created during setup, so you author whichever of them you need: a per-tenant grant has to name the tenant it applies to, and there is no placeholder that stands for "the tenant this user administers" the way ${user} stands for the current user, so per-tenant delegation is one policy per tenant.

Note that these policies govern tenant administration only. Reaching a tenant's repositories additionally requires membership of that tenant, so an administrator who also works with the data has to be attached to the tenant like any other user.

TenantsAdmin¶

Grants management of every tenant in the installation, including creating and deleting them. The default administrator's AuthFullAccess already covers all of this, so reach for TenantsAdmin when you want to hand installation-wide tenant management to someone without also handing over the rest of auth:*:

{
  "statement": [
    {
      "action": [
        "auth:*Tenant*"
      ],
      "effect": "allow",
      "resource": "arn:lakefs:auth:::tenant/*"
    }
  ]
}

Granting every tenant is also the only way to grant an attachment that covers all of them at once, which is how an installation-wide identity such as the one used by standalone garbage collection reaches every tenant including tenants created later.

TenantAdmin-{tenant}¶

Grants administration of a single tenant, which is the policy to attach to a team's group so the team runs its own tenant. It deliberately omits auth:CreateTenant and auth:DeleteTenant, leaving the tenant lifecycle with the installation administrator, and it names the tenant in the resource so a separate copy exists per tenant. The name is a convention that keeps a long policy list readable rather than something lakeFS parses:

{
  "statement": [
    {
      "action": [
        "auth:ReadTenant",
        "auth:ListTenants",
        "auth:UpdateTenant",
        "auth:AttachTenantUser",
        "auth:DetachTenantUser",
        "auth:AttachTenantGroup",
        "auth:DetachTenantGroup"
      ],
      "effect": "allow",
      "resource": "arn:lakefs:auth:::tenant/team-a"
    }
  ]
}

Attaching that policy to a group completes the delegation, and the resulting administrator can manage their own tenant's membership and description.

Listing tenants admits each record separately, so the listing contains only the tenants their policies allow, and any tenant outside that set answers as though it did not exist rather than reporting that access was denied.

A delegated administrator therefore cannot use the API to find out which other tenants the installation holds.

Additional Policies¶

You can create additional policies to further limit user access. Use the web UI or the lakectl auth command to create policies.

Here is an example to define read/write access for a specific repository:

{
    "statement": [
        {
            "action": [
                "fs:ReadRepository",
                "fs:ReadCommit",
                "fs:ListBranches",
                "fs:ListTags",
                "fs:ListObjects"
            ],
            "effect": "allow",
            "resource": "arn:lakefs:fs:::repository/<repository-name>"
        },
        {
            "action": [
                "fs:RevertBranch",
                "fs:ReadBranch",
                "fs:CreateBranch",
                "fs:DeleteBranch",
                "fs:CreateCommit"
            ],
            "effect": "allow",
            "resource": "arn:lakefs:fs:::repository/<repository-name>/branch/*"
        },
                {
            "action": [
                "fs:ListObjects",
                "fs:ReadObject",
                "fs:WriteObject",
                "fs:DeleteObject"
            ],
            "effect": "allow",
            "resource": "arn:lakefs:fs:::repository/<repository-name>/object/*"
        },
                {
            "action": [
                "fs:ReadTag",
                "fs:CreateTag",
                "fs:DeleteTag"
            ],
            "effect": "allow",
            "resource": "arn:lakefs:fs:::repository/<repository-name>/tag/*"
        },
        {
            "action": ["fs:ReadConfig"],
            "effect": "allow",
            "resource": "*"
        }
    ]
}

Multiple Resources Statements¶

lakeFS supports specifying multiple resources in a single RBAC statement. This is available on lakeFS Cloud, or on lakeFS Enterprise if starting at version lakeFS v1.54.0 and Fluffy v0.12.0 In addition to a single resource. The resource field can contain a string representing a JSON-encoded list of resources.

{
    "statement": [
        {
            "action": [
                "fs:Read*"
            ],
            "effect": "allow",
            "resource": "[\"arn:lakefs:fs:::repository/repo1\",\"arn:lakefs:fs:::repository/repo2\"]"
        }
    ]
}

The list must be properly encoded as a JSON string: quote each resource, and escape those quotes as shown. Otherwise, the policy cannot be parsed.

Multi-Resource Policy Creation Using Python SDK¶

Here is how you can leverage Python SDK to create a multiple resource policy:

import lakefs_sdk
from lakefs_sdk.client import LakeFSClient
from lakefs_sdk import models

configuration = lakefs_sdk.Configuration(
        host=lakefsEndPoint,
        username=lakefsAccessKey,
        password=lakefsSecretKey,
)
clt = LakeFSClient(configuration)

clt.auth_api.create_policy(
    policy=models.Policy(
        id='FSReadTwoRepos',
        statement=[models.Statement(
            effect="deny",
            resource=json.dumps(["arn:lakefs:fs:::repository/repo1","arn:lakefs:fs:::repository/repo2"]),
            action=["fs:ReadRepository"],
        ),
        ]
    )
)

Preconfigured Groups¶

lakeFS has four preconfigured groups:

• Admins
• SuperUsers
• Developers
• Viewers

They have the following policies granted to them:

Pluggable Authentication and Authorization¶

Authorization and authentication is pluggable in lakeFS.

If lakeFS is attached to a remote authentication server (or you are using lakeFS Cloud) then the role-based access control user interface can be used.

If you are using RBAC with your self-managed lakeFS then the lakeFS configuration element auth.ui_config.rbac should be set to external.

An enterprise (paid) solution of lakeFS should set auth.ui_config.rbac as internal.