Access Control in lakeFS Community¶

lakeFS Community runs with a single administrator user that holds a single set of credentials. The user is created during the initial setup of the server, and its credentials are valid for logging into the web UI as well as for authenticating requests to the API server and the S3 gateway. Additional users, groups and policies, together with single sign-on, are part of Role-Based Access Control in lakeFS Enterprise.

The configuration keys that once connected lakeFS to an external authorization service, auth.api.* and auth.ui_config.rbac, are deprecated. lakeFS still accepts them so that existing configuration files keep loading, but it logs a warning for each key that is set and ignores its value. The configuration reference lists the affected keys.

Replacing the credentials¶

Because there is a single user, replacing its credentials means recreating the user with the same name:

1. Delete the existing user:

   lakectl auth users delete --id <user-id>
   

2. Shut down the lakeFS server, which invalidates the old credentials.

3. Create the user again with the same name and new credentials:

   lakefs superuser --user-name <user-id>
   

   The command generates a new set of credentials and prints them:

   credentials:
     access_key_id: *** (omitted)
     secret_access_key: *** (omitted)
   

4. Start the lakeFS server again.

Migrating an installation with multiple users¶

An installation that still holds several users or several sets of credentials in the lakeFS database, for example one that was set up before single-user mode or one that ran the ACL server against the same database, has to choose which user and credentials to keep. A single stored user is adopted automatically when the server starts. With more than one, the server refuses to start until you pick the user with the lakefs superuser command. For a user named <my-username> with the access key <my-access-key-id>, run:

lakefs superuser --user-name <my-username> --access-key-id <my-access-key-id>

Afterwards you can access the installation with that access key ID and its secret access key. If the ACL server used a database of its own, no user is carried over and the server refuses to start until you create the administrator with lakefs superuser --user-name <user-id>, after which you log in with the credentials the command prints.

An installation that kept its users in an external authorization service, with auth.ui_config.rbac set to external, was never set up in the lakeFS database, so an upgraded server would otherwise come up uninitialized and offer the setup wizard to whoever reaches it first. To prevent that, lakeFS refuses to start whenever it finds traces of earlier use while having no administrator of its own, whether those traces are existing repositories, users left by an earlier version, or an auth.api endpoint still present in the configuration. Create the administrator with lakefs superuser --user-name <name>, which also records the installation as set up, so the server starts normally afterwards and you log in with the credentials the command prints. To keep a key pair your clients are already configured with, pass both --access-key-id and --secret-access-key, because passing the access key ID on its own asks lakeFS to import credentials from its own database, which an installation of this kind never held.

An installation that holds neither repositories nor users of its own leaves the auth.api keys as its only trace, so create the administrator before you remove them.