tenant owner can't impersonate a namespace admin #424
Comments
brightzheng100
added
blocked-needs-validation
|
@brightzheng100 Thanks for reporting this issue. Currently, Capsule operator creates a RoleBinding between the tenant owner identity, e.g. The User-facing ClusterRole So impersonate users is not allowed to tenant owners. In the current design, the tenant owners act as admin of the namespaces belonging to the tenant and they cannot impersonate outside the namespaces they own. On the other side, giving impersonate users and groups permission can lead to a security issue since the tenant owner can use this capability to access resources not allowed to. For example, if we provide as cluster admin kubectl apply -f - << EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: impersonator
rules:
- apiGroups: [""]
resources: ["users"]
verbs: ["impersonate"]
EOF
kubectl apply -f - << EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: impersonator
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: impersonator
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: capsule.clastix.io
EOF
the tenant owner At same time, she can impersonate any other user Any idea how to solve this in a safe way would be really appreciated. |
bsctl
added
enhancement
|
I don't know the rationale behind the As we're assuming the Tenant Owner works like the Cluster Admin in the assigned namespaces, so this security issue shouldn't be a big concern just like we shouldn't challenge why Cluster Admin can impersonate anyone within the assigned cluster. So this may raise a potential requirement, where a custom cluster role, instead of the in-built In this case, the design might be slightly changed to something like: type OwnerSpec struct {
Name string `json:"name"`
Kind Kind `json:"kind"`
// +kubebuilder:default=admin
Role string `json:"role,omitempty"`
}Not sure whether this makes any sense, thanks! |
|
@brightzheng100 thanks for your suggestion, definitively something we can consider for next releases. |
|
Before considering this feature request for the next release, I'd like to chime in on this topic. The goal of Capsule is to provide the ability to provision in a fashioned self-service way Namespace without the help of external parties, such as opening tickets, sending emails, and so on. The users will be granted The imperonsate feature is absolutely a nice feature that I used several times to understand what was not going on with my applications, and it's convenient. At the same time, it's really important to understand that _with great power comes great responsibility: impersonating another user in a multi-tenant scenario, in most of the scenarios, is a privilege escalation since it allows to bypass any permission set by RBAC boundaries. Additionally, we have always to remember that Kubernetes API hasn't been designed with a User first approach, a fact that implies most of the limitations that users are complaining about, like getting the list of owner Namespaces: the rationale is that these resources are cluster scoped and the ACL is based on the resource objects rather than the user, as most of the web applications are doing. The same applies to the With that said, I just wanted to explain why we (and Kubernetes with its Working on Capsule code baseThe operator could start watching for any RoleBinding with a kind subject equals to apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: impersonator-${tenant_name}
rules:
- apiGroups:
- ""
resources:
- groups
verbs:
- impersonate
- apiGroups:
- ""
resourceNames:
- joe
resources:
- users
verbs:
- impersonatewith a following All the resources must be attached to the Tenant using the I tested this and it seems working since we're targeting the subjects using the Pros
Cons
Working with capsule-proxyOur proxy is providing a smart approach to overcome Kubernetes limitations and could be playing a role also here, as we're doing with the listing of Namespaces, Ingress and PodPriority and Storage Class resources. We would just pipe the request in a middleware matching the control of the impersonate headers and check if the targeted user got a RoleBinding matching the criteria: if that's the case, proxy to the upstream API Server updating the request with the right fields, otherwise do nothing and let Kubernetes deal with the failure since the user is not entitled to impersonate a user. Pros
Cons
Said so, we have to pick a choice, and would be great to have as much feedback as possible from the community in order to start a discussion and find the optimal solution. @MaxFedotov please, join the discussion, your opinion is highly appreciated. |
|
I personally think that having the flexibility of setting up a The |
|
@prometherion
If |
Hadn't tested yet, it seems doable, tho, and this confirms my concerns regarding the privilege esclation. I think we have to investigate addressing this on |
In order to impersonate, we have to give wider permission and using the NB |
|
With that said, we have to track this down on |
Would be better to move the discussion to the proper repository, although I can briefly answer your questions here. We wanted to keep the same look and feel, and developer experience too, of native kubernetes, without adding any additional extra thing like a new path or verb. Allowing tenants to install CRDs, rather, is another issue we cannot overcome with the soft multi-tenancy model implemented by Capsule since it's a hard limitation put in place by Kubernetes and at the current state just a separated etcd store would be able to provide this. |
I guess that's what |
|
@brightzheng100 it's quite accepted into the community two types of multi-tenancy for Kubernetes:
The first one is addressed very well by Capsule. For the second one, may you can be interested into a new project we're working on. It's called Kamaji. The project is still in its infancy and comments and contributions are really welcomed. Would you like to help us? |
|
Yeah and this is a good blog there: Three Tenancy Models For Kubernetes Not sure how Karmaji differentiates itself from:
|
|
I don't know each of one the projects you mentioned, so my tl;dr; could be highly wrong.
Said so, Kamaji takes a different approach, using a shared and multi-tenant If you got more concerns and inquiries I'd say to move the discussion to the Kamaji repository to keep sticking the discussion regarding the feature request. |
|
We encountered this requirement while working on #528 and we're addressing it in Capsule Proxy with projectcapsule/capsule-proxy#216. Going to close this, let's move an eventual discussion there. |
Bug description
The tenant owner Alice can't impersonate the namespace admin Joe assigned by her.
Only Cluster Admin can do this as of now.
How to reproduce
By following the docs, the tenant owner Alice assign Joe as the namespace admin:
But she can't impersonate Joe:
And only Cluster admin can.
unset KUBECONFIG kubectl --as joe --as-group capsule.clastix.io auth can-i create pod -n oil-development yes kubectl --as joe --as-group capsule.clastix.io auth can-i create pod -n oil-production noExpected behavior
The tenant owner should be able to act like a Cluster Admin within the assigned tenant.
Additional context
The text was updated successfully, but these errors were encountered: