Hello there I hope you're having a great day, night, or breakfast, depending on when you read this. I have a question about access control for self-hosted instances of lakeFS. Specifically, I'm trying to configure a user who can only download and view data. The read "Group" rule seems ideal, except for the fact that it allows users to delete their own access keys, which poses an issue for my use case (details below). Is there an option to modify or add "Group" rules to prevent users from editing their own settings? Here’s a more detailed explanation of my requirements: I frequently work with build artefacts that are primarily in zip format. I want to manage these artefacts similarly to how one would store items in Git, enabling my automation processes to pull and place them as needed. While this might typically call for an artefact repository manager, after considerable discussion within our project team, we decided that lakeFS better suits our needs. (PS: I'm from Ynput we do open-source VFX software, just in case you care https://github.com/ynput) Additionally, we have a few open-source plugins that need to load some of these zip archives from the lakeFS server. We aim to create a user who can only download and view these files, without any other permissions. This way, we can safely include the "open" keys in a secret file without worrying about them being misused. Thank you for your help! Best regards, Lyon

Hey Hey and welcome @Lyon Rosenblatt! Thanks for providing the context. The OSS version does not allow changing the policies or adding new ones. What you are trying to achieve is easily in the RBAC (only available in Enterprise / Cloud)

Thanks for the answer and your time. That's unfortunate to hear, tbh. Because enterprise and cloud are not options for the current project. (users are both open source/enterprise and people that play around the need to be able to run it on their side; we can't use a platform or Higer order agreement in this situation, On top of that, the whole thing also has to run under open source licenses like MIT or Apach2.0 and having a license agreement in place would force users to have the same license agreement. if they wish to have it on cloud good for them but we can't force them) I see minimal documentation for external auth providers, but the documentation around it looks outdated as it describes setup keys that don't exist. for example, [Remote Authenticator](https://docs.lakefs.io/reference/security/remote-authenticator.html) states this:

ui_config:
    logout_url: /logout

And the ui_config errors if you give it that key. That makes sense, as the key is never listed in the config docs. also, there is a key set called

auth.api

and

auth.authentication_api

but I don't find documentation on how you would implement/use them correctly. also, there is this in the documentation

If you have configured an external auth server you can set this to "external" to support the policy editor.

under

auth.ui_config.rbac

so I assume an external implementation is possible. I know there was an option for

oidc

but it's stated as deprecated, so if you want to use something like KeyCloack, you must write an application that connects them. (this is btw something I would like to do and make available for the community, but for that, it would be great to have some more documentation on the pluggable authentication) So yeah, that's kind of my situation. I hope someone can expand on those systems a bit because contributing to and implementing granular pluggable authentication for the community would be great. Also, it would be great if someone could explain why a user can delete their key if they just have Read access, as it seems like a strange decision. Cheers Lyon.

@Lyon Rosenblatt we have two extendable and separated concepts. 1. Authentication - that’s the remote_authentication concept you mentioned - that only provides identity, regardless of permissions. 2. Authorization - That’s the service that you are interested in if you would want to implement authorization service. essentially replacing in lakeFS the built in authorization with a service. To implement such service you need an API that implements the following API spec and configure it under

auth.api

to make it pluggable.