https://lakefs.io/ logo
#help
Title
# help
j

Jonas

03/02/2023, 9:48 AM
I'm currently trying to configure lakefs to restrict users access to a single repo. If I take the sample from here (https://docs.lakefs.io/reference/authorization.html#additional-policies) and remove everything else I end up with the following error message
insufficient permissions: uM: insufficient permissions at ot (<http://localhost:8090/assets/index-7bf1aa94.js:71:93127>) at async T$.list (<http://localhost:8090/assets/index-7bf1aa94.js:71:100206>) at async <http://localhost:8090/assets/index-7bf1aa94.js:71:111901>
when accessing http://localhost:8090/repositories. What am I missing? EDIT: I can restrict write access, my issue though is that I don't even want the user to see repos he has no access to
i

Itai Admi

03/02/2023, 10:10 AM
Hey Jonas, I’m looking into it. Would you mind sharing your lakeFS version? Also, is it your first time you ran lakeFS? The reason I’m asking is that we need to take into account possible migrations too. Any other information on your use-case would help a lot too 🙂
I would also like to share the RBAC support for the OSS version is deprecated and replaced with ACLs. For the reasoning and ways to configure lakeFS authorization, please read our announcement.
j

Jonas

03/02/2023, 10:22 AM
Hi! Sure here are the versions we are using: lakeFS 0.90.1 Web UI 0.90.1
👍 1
We just started using to so yes it is pretty much the first time we are using it
I fear you need to explain this in more basic terms, I'm a mathematician, I have very limited knowledge about authorization methods 😄 That's why I like the interface you provide even though I struggle with it :D
i

Itai Admi

03/02/2023, 10:59 AM
Sure thing, I’ll do my best 😅
The lakeFS RBAC model is defined here. In short, it has 5 basic components: Users, Actions, Resources, Policies, Groups which you may combine to have a fine-grained access-control. For example, User that belongs to the Group
Developers
is allowed to perform all read and write (
fs:*
) Actions on the Resource
repository-dev
. The linked guide has several great examples and that’s a good place to start. Remember,
0.90.1
is the last version where lakeFS RBAC capabilities are supported for the OSS.
On the other hand, ACLs are a much more simplified solution. The Groups are predefined and cannot be altered. The attached Actions & Policies cannot be modified too. It all boils down to 4 basic Groups with predefined Policies and you can assign Users to any of these groups.
Adding @Isan Rivkin & @Ariel Shaqed (Scolnicov) who are working on this as we speak, to keep me honest 🙂
j

Jonas

03/02/2023, 11:19 AM
So the more recent version allows for less fine grained control if I got that correctly?
And thank you so much for explaining it like this!
i

Itai Admi

03/02/2023, 11:24 AM
With pleasure!
Yes, we needed to decouple the security aspects like RBAC from lakeFS OSS. It allows us to focus on building lakeFS to be the best data version control tool. We added RBAC to our paid offerings as we can fully back all security considerations there, hence the SOC2 compliance we’re offering just for the paid solutions.
a

Ariel Shaqed (Scolnicov)

03/02/2023, 12:15 PM
You might have missed our founders' security update about this. It will be going in soon. Here's the design for what is actually happening with ACLs. In addition to what @Itai Admi said, you will also be able to create groups with one of the bottom 3 permission levels (read / write / super) that are limited to a single repo. Groups at the highest permission level (admin) can always do everything.
g

Geert-Jan Van den Bogaerde

08/21/2023, 8:17 AM
@Ariel Shaqed (Scolnicov), on you will also be able to create groups with one of the bottom 3 permission levels (read / write / super) that are limited to a single repo. : i was looking for this feature in the current open source version, and wasn't able to find it. did i miss it / is it on the roadmap / or was the design changed?
a

Ariel Shaqed (Scolnicov)

08/21/2023, 8:31 AM
We ended up deciding to remove this: everyone with whom our product people talked thought that it was not useful and too complicated to understand.
See #5689.
g

Geert-Jan Van den Bogaerde

08/21/2023, 9:26 AM
@Ariel Shaqed (Scolnicov), got it, thanks for the quick response!
8 Views