Role-Based Access Control (RBAC)

lakeFS Cloud

lakeFS Enterprise

RBAC is available on lakeFS Cloud and lakeFS Enterprise.

If you’re using the open source version of lakeFS then the ACL-based authorization mechanism is an alternative to 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.

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:

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

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, in order 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.

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",
                "fs:CreateMetaRange"
            ],
            "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": "*"
        }
    ]
}

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": "*"
        }
    ]
}

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.

If you are using self-managed lakeFS and do not have a remote authentication server then you should set auth.ui_config.rbac to simplified and refer to the access control list documentation instead.