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?
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.