SAP-archive / karydia

Kubernetes Security Walnut
Other
77 stars 10 forks source link

manifests/rbac: allow karydia to list {cluster,}role{s,bindings} #82

Closed schu closed 5 years ago

schu commented 5 years ago

The KarydiaSecurityPolicy admission handler needs permission to list {cluster,}role{s,bindings} for KSPs to work. If not given, it cannot list the available bindings in order to determine the KSPs to check for the currrent user.

E0410 12:44:48.711578       1 reflector.go:134] k8s.io/client-go/informers/factory.go:131: Failed to list *v1.ClusterRoleBinding: clusterrolebindings.rbac.authorization.k8s.io is forbidden: User "system:serviceaccount:kube-system:karydia" cannot list resource "clusterrolebindings" in API group "rbac.authorization.k8s.io" at the cluster scope
E0410 12:44:48.742234       1 reflector.go:134] k8s.io/client-go/informers/factory.go:131: Failed to list *v1.ClusterRole: clusterroles.rbac.authorization.k8s.io is forbidden: User "system:serviceaccount:kube-system:karydia" cannot list resource "clusterroles" in API group "rbac.authorization.k8s.io" at the cluster scope
E0410 12:44:48.755163       1 reflector.go:134] k8s.io/client-go/informers/factory.go:131: Failed to list *v1.Role: roles.rbac.authorization.k8s.io is forbidden: User "system:serviceaccount:kube-system:karydia" cannot list resource "roles" in API group "rbac.authorization.k8s.io" at the cluster scope
E0410 12:44:49.711716       1 reflector.go:134] k8s.io/client-go/informers/factory.go:131: Failed to list *v1.RoleBinding: rolebindings.rbac.authorization.k8s.io is forbidden: User "system:serviceaccount:kube-system:karydia" cannot list resource "rolebindings" in API group "rbac.authorization.k8s.io" at the cluster scope

The default view role that we already give to karydia is not enough:

"Allows read-only access to see most objects in a namespace. It does not allow viewing roles or rolebindings." [1]

Thus we expliclity have to allow listing of those resources for KSP authz to work.

I guess we didn't notice before because when we did the change in b16bfba8c3a203ef1da9cb5ce888a38faac07362 KSPs were already disabled by default and nobody checked since - until now. And even before that we used cluster-admin and had all privileges.

[1] https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles