What do you mean by “prefixes”?

Sorry. A "prefix" is S3-speak for "directory": really just a common prefix for all keys used. For instance, I might put all repos for my us-east-1 test installations in s3://treeverse-test-ariels-us/installation/NAME/repo/NAME.

ahh. So does lakeFS need its own namespace or do I let users pick that for each repositories? So for example me as the admin do I make a s3://company/services/lakeFS/ And lakeFS manages it? Or do people just make. s3://company/random/bucket/that/user/makes/project and lakeFS just works with that?

Your choice, really. That guide tries to keep it simple to get you up and running as quickly as possible. But you could apply a similar role-based policy to your role that allowed it to access more buckets. Or you could deploy such a policy for each bucket intended for use on lakeFS. We try to avoid deciding things like that as part of lakeFS itself: different users and different use cases will have different requirements here. That said, if I were trying to get started, I'd go with the policy on the quickstart, and transition to a principled automated approach when scale became significant and worth the effort.

Yeah, I'm just trying to get it working atm. I don't have access to create IAM_ROLES so i'm waiting on admin to do that. I'm just trying to get a reasonable organizational pattern because it sometimes tends to make things difficult to change for projects after the fact. So I assume that if i put a bucket policy that allows the lakeFS server to access and then for one bucket add permissions for “team1only” and “team2only” and then a person in team2 would only see team2 buckets and not team1? Or should permission and access for groups/users be handled at the lakeFS level?

There's a way to use personal access credentials too, of course - if your policy allows that. That's a good way to "get it working". (Also sorry, I'd not realized the connection between your questions!)

yeah they were kind of conflated