Konrad:
I’m trying to debug the permissions of a service account with the following command: kubectl auth can-i patch secrets --as=system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)
. I got the username pattern for the --as
flag from https://kubernetes.io/docs/reference/access-authn-authz/authentication/|this doc. It returns yes
for any existing or non-existing combination of namespace/service account Does that mean that there are default permissions attached to service accounts and if so, where are they configured?
Konrad:
Yeah, in Katacoda environments there is a ClusterRoleBinding permissive-binding
which attaches “cluster-admin” to the group system:serviceaccounts
. Doesn’t make any sense to me:confused:
kcd clusterrolebinding permissive-binding
Name: permissive-binding
Labels: <none>
Annotations: <none>
Role:
Kind: ClusterRole
Name: cluster-admin
Subjects:
Kind Name Namespace
---- ---- ---------
User admin
User kubelet
Group system:serviceaccounts
It was pure luck to find this when I strolled through the list of role bindings. How am I supposed to do this in a production cluster with hundreds, maybe thousands of such role bindings? IMO Kubectl is lacking some important functionality here.