Users management

[prometherion]

At the current state of Capsule (just the first commit), we don't have multi-user management for the Tenant resources: it means just the owner can operate over all the clusters through the credentials provided by the Cluster Admin as mentioned here.

We need the support of the community to drive this development, so please: let's use this issue to propose a way to implement this feature.

[gdurifw]

Hi prometherion, this is a very nice project! :)

Could I ask you a question?
With the sentence "the owner can operate over all the clusters through the credentials provided by the Cluster Admin" you mean that the owner can operate as admin of all namespace of the tenant, right?

However, for every multi-user tenant, would be nice to have different Roles (and RoleBinding) for example:

• admin - the role that already exits
• devops - with grant and permission to start a deploy but not create a namespace or somethings else
• tester - user that can access to stdout and status of the pod or somethings else

The Admin Roles, need to update with grant to :

• add / remove role ( maybe non needed if we provide a set of predefined roles )
• add / remove user to/from role
• ....

In this way we can have nominal users / login for audit compliance and share the responsibility and activity between the users of the tenant.

For example we can extend the use case/story of Onboarding of new Customer in the following way.

• Tenant: Bastard Bank Inc.
• Alice: role Admin
• The Mad Hatter: role DevOps
• The White Rabbit: role Tester

Sorry but at the moment i don't know if this actions are applicabile to Capsule or are out of scope (i mean the enforcing of that roles policy), so if i'am wrong no worry to tell me :)

[prometherion]

Hi @gdurifw and thanks for the kind words!

With the sentence "the owner can operate over all the clusters through the credentials provided by the Cluster Admin" you mean that the owner can operate as admin of all namespace of the tenant

That's right: if you need more context regarding the terms we use, please check out the use-case documentation.

---

What I like a lot about Capsule is that it's providing fascinating self-provisioning management: a Tenant owner just needs to get the kubeconfig to create their Namespace resources, no need to interact with CRDs that are always a pain, using kubectl as any other Kubernetes cluster.

What Kubernetes is missing (and I don't see any drawback, honestly) is that there's no Kubernetes resource to manager users or groups, and probably this is the right approach: Kubernetes is just (sic) a container orchestrator platform, all the user management needs to be delegated to an Identity Management platform as OIDC providers.

I'll try to answer your question: if you're planning to onboard a Tenant owner (aka _new customers using your terms) it's their duty to setup Role and RoleBinding resources to the users that the Cluster Admin (aka the operators using Capsule) is going to provide to them (as your examples: new kubeconfig will be generated per each requested user).

The reason is that Capsule is not fully declarative, it means you're not to declare a Namespace with related RoleBinding resources into the Tenant definition and that's ok, since it's duty of the Tenant owner, as a Cluster Admin on any managed Kubernetes would do.

What could be annoying is to replicate a same Role and related bindings across several Namespace resources, but it looks good to me since it would be the same task if I would have to setup a new cluster for the team I'm responsible of.

What are you thoughts about this?

[bsctl]

What I like a lot about Capsule is that it's providing fascinating self-provisioning management: a Tenant owner just needs to get the kubeconfig to create their Namespace resources, no need to interact with CRDs that are always a pain, using kubectl as any other Kubernetes cluster.

Hello @gdurifw, as pointed by @prometherion, one of the key design principle of the Capsule Operator is the self-provisioning management from the Tenant owner perspective. The Tenant owner does not need to interact with the Cluster Admin in order to complete his day-by-day duties. On the other side, the Cluster Admin has not to deal with multiple requests coming from multiple Tenant owners that probably will overwhelm him.

So we leave the Tenant owner the freedom to create RBAC roles at namespace level (or using the pre-defined roles already available in Kubernetes) and assign them to other users in the Tenant according to his needs and requirements. Being roles and rolebindings, limited to a namespace scope, the Tenant owner can assign the roles to the other users accessing the same Tenant only after a namespace is created in the Tenant. This gives the Tenant a real power to admin his tenant without ask the Cluster admin.

From the Cluster Admin perspective, the only required action is to provision the other user identities in the IdP Management system but this task can be done once, when on boarding a new Tenant in the system and the number of users accessing the tenant can be part of the tenant business profile.

Hope this clarifies your doubts. We leave open this issue for a while in order to collect feedbacks and suggestions from the community.

[bsctl]

@prometherion @gdurifw User Management in Capsule has been improved with the addition of Kind: Group as tenant owner, as per #71. Should we close this issue?

[gdurifw]

@prometherion @bsctl

Should we close this issue?

It's perfect! yes we can close the issue. Thank you so much for your support.