Open izgeri opened 4 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.
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:
465 - Conjur is updated to stop auto-creation of account management account
463 - Conjur CLI is updated to allow manual creation of account management account
364 -
/accounts
has been added to API docs466 - Conjur documentation is updated with an “Account Management” reference page
460 - Conjur.org has an account management tutorial
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:
(it looks like we headed in the latter direction)
at current: