You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be useful to let Capsule set all the needed RBAC and identities for a machine Tenant Owner, that would be responsible of reconciling Tenant resources.
What would the new user story look like?
As a platform/admin user, I want to provide tenant users the ability to declare their resources and let a GitOps Kubernetes operator reconcile them from Git, with an unprivileged identity.
Expected behavior
RBAC
By using a knob (e.g. spec.gitopsReady=true) the admin user could request that the Tenant would be prepared to have:
Tenant Owner as ServiceAccount, to be used by GitOps operators and placed into a dedicated Namespace ("Tenant Owner Home")
necessary (Cluster)Roles bound, in order to patch, work with custom resources inside the Tenant (admin ClusterRole is not enough, cluster-admin is needed)
(optional) ClusterRole bound in order to impersonate himself (e.g. needed on Flux use case
(optional) Secret with generated kubeconfig to let the Tenant Owner SA communicate over Capsule Proxy
I'm going to refine this propsal with more detail and the rationale behind it.
Client config for Proxy
For each robot Tenant Owner (i.e. ServiceAccount type) a Secret containing kubeconfig to configure a client to communicate as Tenant Owner through the Capsule Proxy.
Instead, in order to keep Capsule a framework for soft multi-tenancy, we'd provide an additional and dedicated addon to manage RBAC as an adapter for GitOps environments.
This is still more appropriate when RBAC is related to impersonation, which is now, leveraged by a GitOps operator(s) in particular.
cluster-admin
One another detail is to avoid the usage/binding of the cluster-adminClusterRole even though it would be attached to Tenant's Namespaces only. Insted, it would be better to provide a tailored ClusterRole, like a "powered" adminClusterRole.
GitOps RBAC manager as a Capsule Addon
The addon could manage all RBAC-related stuff to adapt the Capsule-managed RBAC for Tenant owners for GitOps environments - typically the owners might be machine users.
This might include the configuration needed to make the Tenant owners as GitOps reconciler indentities communicate over the Capsule Proxy.
Describe the feature
It would be useful to let Capsule set all the needed RBAC and identities for a machine Tenant Owner, that would be responsible of reconciling Tenant resources.
What would the new user story look like?
As a platform/admin user, I want to provide tenant users the ability to declare their resources and let a GitOps Kubernetes operator reconcile them from Git, with an unprivileged identity.
Expected behavior
RBAC
By using a knob (e.g.
spec.gitopsReady=true
) the admin user could request that the Tenant would be prepared to have:ServiceAccount
, to be used by GitOps operators and placed into a dedicated Namespace ("Tenant Owner Home")Cluster
)Role
s bound, in order to patch, work with custom resources inside the Tenant (admin ClusterRole is not enough, cluster-admin is needed)ClusterRole
bound in order to impersonate himself (e.g. needed on Flux use caseSecret
with generated kubeconfig to let the Tenant Owner SA communicate over Capsule ProxyI'm going to refine this propsal with more detail and the rationale behind it.
Client config for Proxy
For each robot Tenant Owner (i.e.
ServiceAccount
type) aSecret
containingkubeconfig
to configure a client to communicate as Tenant Owner through the Capsule Proxy.Related issues
The text was updated successfully, but these errors were encountered: