Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Also I have created 2 policy(restricted and privileged) as below:
When I checked the "default" service account on any namespace, the default service account was able to use the privileged pod security policy:
Because of this any new helm chart which doesn't link with any service account is able to get privileged permission in the cluster.
What you expected to happen:
Are you running
One observation is that by granting privileged access to all service accounts in the kube-system namespace, all pod-creating controller loops will have privileged access, and any user that creates a deployment/replicaset/etc will be able to make the pod-creating controller create a privileged pod on their behalf.
Thanks @liggitt for the reply. Yes I am using secured port.
As suggested by you I have modified the ClusterRoleBinding for kube-system namespace to grant permission to specific serviceAccount. Now my psp.yaml shows like below:
I am also using Helm for deploying charts in any namespace and using RBAC for the helm as:
I am deploying tiller in cluster scope(single tiller pod in kube-system namespace for the cluster). Now I suspect that linking cluster-admin to the tiller service account is causing the security hole.
But I am still not clear how tiller is able to break the security (and giving privileged policy to any service) even if I link restricted psp policy with all service account.
Your can-i command has a typo in the PSP name (priviledged in the command vs privileged in the role), which would seem to indicate the service account in question has permissions on all PSPs.
Yes, granting anything cluster-admin rights allows it to use any PSP (cluster-admin == superuser == allow any verb on any resource)