-
Notifications
You must be signed in to change notification settings - Fork 163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dedicated PodSecurityPolicy per Tenant #52
Comments
@bsctl do we still need discussion or any priority to assign here? |
Definitely a requirement for a strong multi tenancy environment. Also needed by #65. Anyway not a current request from our early adopters, so we can postpone to the next release. |
@bsctl , @prometherion i would like to provide to our customers a specific PSP for own Tenant in a K8s Cluster with Capsule and i think that this feature would be perfect for our purpose. |
Thanks for your feedback @gdurifw, really appreciated: having feedbacks and offering help for feature requests is always good! This specific one looks fuzzy to me, right now: we all know that PSPs aren't yet a graduated Rather than this, I think we should start seriously thinking about this enhancement proposal: Make Capsule admission controller programmable. This could provide more flexibility rather than PSP and a higher layer of additional business logic that could be designed by the Cluster Administrator, and could be an amazing feature and enhancement, even that would add an additional resource as a direct dependency (Gatekeeper/OPA). Feedback from the early adopters and the community here would be great: @MaxFedotov, please, any thoughts about this? |
@prometherion as #51 is a long term evolution, we should consider #52 as short term solution to address this requirement. Although PSP is going to be deprecated in favor of OPA, it is still widely used. And deprecation seems only in Azure AKS. |
This will be useful for me as well. If tying this closely to PodSecurityPolicy resources is a concern due to its potential deprecation, would it make more sense to look at this as a generic RoleBinding feature? For example, instead of apiVersion: capsule.clastix.io/v1alpha1
kind: Tenant
metadata:
name: oil
spec:
podSecurityPolicies:
- psp:restricted
... it could be apiVersion: capsule.clastix.io/v1alpha1
kind: Tenant
metadata:
name: oil
spec:
roleBindings:
- roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: psp:restricted
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:serviceaccounts
... This would also be consistent with with the pattern established by the |
thanks for your point @d-m: I'm thinking of a similar approach, like the following: additionalRoleBindings:
role-name: psp:restricted
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:serviceaccounts The idea is to use the key as the value of the Cluster Role we'd like to apply all over the Tenant's Namespaces, giving the change to personalize the subjects. I think we can avoid the @bsctl @MaxFedotov @d-m WDYT? |
Describe the feature
It would be nice to let the cluster admin to set a dedicated Pod Security Policy (PSP) per tenant. This is likely to be a requirement in a multi-tenancy environment.
A PSP is defined at cluster scope. To assign the PSP to users/serviceaccounts in a tenant we can use RoleBindings for each namespace created in the tenant. The Capsule should enforce the creation of RoleBinding assigning the PSP.
What would the new user story look like?
Expected behavior
For each namespace created into the tenant, the Capsule controller creates a RoleBinding assigning the PSP to all the services accounts in such namespace:
The text was updated successfully, but these errors were encountered: