cyberark / conjur

CyberArk Conjur automatically secures secrets used by privileged users and machine identities
https://conjur.org
Other
760 stars 123 forks source link

Conjur supports multitenancy #1328

Open izgeri opened 4 years ago

izgeri commented 4 years ago

As a Conjur operator, I want to be able to create separate Conjur accounts so I can manage my identities and secrets in separate namespaces.

Developer Notes

There is already some functionality in place to support multitenancy, but it is missing a few key pieces to make it truly possible. There are several issues related to completing that work to enable multitenancy; however, many of these issues were filed over 2 years ago and it's worth a new review to understand what else may be required.

The old issues relating to enabling true multitenancy in Conjur OSS are:

What is lost to time is the context behind why #465 was created, and why it is important in enabling multitenancy. I think it had something to do with enabling the user configuring Conjur for the first time to create their own account management account that they could then use to manage the accounts - absent this change, the account management account would be inaccessible to users added to Conjur, and thus nothing could be granted permissions to access the /accounts webservice.

Some relevant quotes:

So we can either provide a way to login as !:!:root or we can provide a way to create !:user:admin, or we can get rid of !:!:root and replace it with !:user:admin and then provide a way to get the API key of that user, probably using conjurctl

(it looks like we headed in the latter direction)

then if someone wants to download conjur and manage the accounts, they would call conjurctl accounts create-admin (or similar) and then use the resulting api key / public key to load a policy in the account management account ! that would give them access to the !:webservice:accounts resource then they could use that resource to manage the conjur accounts

at current:

! is a special account that is automatically created by the server and used for account management. The account ! has a role !:!:root which is the owner of !:webservice:accounts. If you login as cucumber:user:admin and try and load a policy into the account !, well you may be able to guess what happens, or you can just try it. Just remember that ! is an account name. It doesn’t have any special / magic meaning to the server.

UberKitten commented 3 years ago

This would be very helpful to have fully supported. Currently the lack of support for things like k8s auth and the lack of docs make it a non-starter. Plus being unsupported is not a risk that's easy to stomach for a critical app. If you're measuring desire for multitenancy by looking at customer usage of accounts that's the wrong idea - no one would use it in the current state.

At Cisco multitenancy is a requirement. We need to be able to separate individual teams into separate accounts. That way one team can't cross into another team's resources and each team can manage their own policy. We'd want to have hundreds of accounts orchestrated by self-service automation.

Currently to get around this we have to cram hundreds of teams into the same tenant (account) and try to split their privileges via careful hierarchy of host keys, policies, and permissions. It requires a lot of oversight and planning to do right. Accounts were made for this problem - but they're not usable.