Who can use podsecuritypolicy

[schnatterer]

What would you like to be added

k who-can use psp

Current Behavior:

Error: resolving resource: the "podsecuritypolicies" resource does not support the "use" verb, only [create delete deletecollection get list patch update watch]

Desired Behavior:

Return a list of Subjects that are authorized to use PSP.

Why is this needed

For debugging PSPs and getting an overview of Pods authorized to use a certain PSP.

[danielpacak]

What would you like to be added

k who-can use psp

Current Behavior:

Error: resolving resource: the "podsecuritypolicies" resource does not support the "use" verb, only [create delete deletecollection get list patch update watch]

Desired Behavior:

Return a list of Subjects that are authorized to use PSP.

Why is this needed

For debugging PSPs and getting an overview of Pods authorized to use a certain PSP.

Thank you for reporting this @schnatterer The fix was released in v0.1.0. You can get it with kubectl krew upgrade who-can

[schnatterer]

@danielpacak Thank you so much for fixing this.

I can confirm that the error message is gone.

However, I don't seem to get subjects authorize via RoleBinding.

Steps to reproduce:

• Set up a fresh KIND 1.17 Cluster (without PSP Admission Controller, but we're only testing RBAC here, right?).
• Do the following:

cat <<EOF | kubectl apply -f -                                                      
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: database-psp
  namespace: default
spec:
  # The rest fills in some required fields.
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
    - '*'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: podsecuritypolicy:databases
  namespace: default
rules:
  - apiGroups: ['policy']
    resources: ['podsecuritypolicies']
    verbs:     ['use']
    resourceNames:
    - database-psp
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: databases
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: podsecuritypolicy:databases
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: podsecuritypolicy:databases
subjects:
  - kind: ServiceAccount
    name: databases
    namespace: default
EOF

kubectl auth can-i use psp/database-psp --as=system:serviceaccount:default:databases
# yes

kubectl who-can use psp/database-psp --all-namespaces                                     
# No subjects found with permissions to use psp/database-psp assigned through RoleBindings

[danielpacak]

I'll check it on my end @schnatterer and come back to you

[danielpacak]

@schnatterer According to the docs https://kubernetes.io/docs/concepts/policy/pod-security-policy/#authorizing-policies if a RoleBinding (not a ClusterRoleBinding) is used, it will only grant usage for pods being run in the same namespace as the binding (the default namespace in your case).

That said, in your example, you're checking whether the ServiceAccount named databases is authorized to use the databases-psp PSP in the default namespace, not any namespace:

$ kubectl auth can-i use psp/database-psp \
  --as=system:serviceaccount:default:databases
yes

On the other hand, the kubectl who-can in your example checks which subjects are authorized to use the specified PSP in any namespace and the returned list is empty as expected.

$ kubectl who-can use psp/database-psp --all-namespaces

If you specify the namespace with the -n <namespace> flag, or use the default namespace configured in your kubectl context, you'll get the following output:

$ kubectl who-can use psp/database-psp -n default
ROLEBINDING                  NAMESPACE  SUBJECT    TYPE            SA-NAMESPACE
podsecuritypolicy:databases  default    databases  ServiceAccount  default

CLUSTERROLEBINDING        SUBJECT         TYPE            SA-NAMESPACE
cluster-admin             system:masters  Group
helm-kube-system-traefik  helm-traefik    ServiceAccount  kube-system

[danielpacak]

If your intention was to authorize the databases Service Account created in the default namespace to use the PSP in any namespace you'd rather configure it with ClusterRole and ClusterRoleBinding

$ cat <<EOF | kubectl apply -f -                                                      
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: database-psp
spec:
  # The rest fills in some required fields.
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
    - '*'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: podsecuritypolicy:databases
rules:
  - apiGroups: ['policy']
    resources: ['podsecuritypolicies']
    verbs:     ['use']
    resourceNames:
    - database-psp
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: databases
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: podsecuritypolicy:databases
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: podsecuritypolicy:databases
subjects:
  - kind: ServiceAccount
    name: databases
    namespace: default
EOF

Then the output of who-can will reflect that:

$ kubectl who-can use psp/database-psp --all-namespaces
No subjects found with permissions to use psp/database-psp assigned through RoleBindings

CLUSTERROLEBINDING           SUBJECT         TYPE            SA-NAMESPACE
cluster-admin                system:masters  Group
helm-kube-system-traefik     helm-traefik    ServiceAccount  kube-system
podsecuritypolicy:databases  databases       ServiceAccount  default

[danielpacak]

I did check all that without enabling PodSecurityPolicy admission controller in my cluster. @schnatterer Would you mind validating it on the cluster with enabled admission controller and confirm it. Otherwise, I'll do it anyway before closing this issue.

[schnatterer]

@danielpacak
My intention was to authorize the databases Service Account created in the * default* namespace to use the PSP the only in the default namespace :-P

I was then wondering why I got No subjects found with permissions to use psp/database-psp assigned through RoleBindings. Because I actually did use a RoleBinding. Or did I get something completely wrong here?

Unfortunately, enabling the PSP Admission Controller on local clusters such as KIND seems to be not straightforward. That is, I also tested it without admission controller.

But does this matter for our use case? We're only testing RBAC features here.

[danielpacak]

@danielpacak
My intention was to authorize the databases Service Account created in the * default* namespace to use the PSP the only in the default namespace :-P

I was then wondering why I got No subjects found with permissions to use psp/database-psp assigned through RoleBindings. Because I actually did use a RoleBinding. Or did I get something completely wrong here?

Unfortunately, enabling the PSP Admission Controller on local clusters such as KIND seems to be not straightforward. That is, I also tested it without admission controller.

But does this matter for our use case? We're only testing RBAC features here.

Your config is fine. But when you query permissions you should not use the --all-namespaces flag in such case. As I mentioned you probably wanted to query it this way:

$ kubectl who-can use psp/database-psp -n default
ROLEBINDING                  NAMESPACE  SUBJECT    TYPE            SA-NAMESPACE
podsecuritypolicy:databases  default    databases  ServiceAccount  default

CLUSTERROLEBINDING        SUBJECT         TYPE            SA-NAMESPACE
cluster-admin             system:masters  Group
helm-kube-system-traefik  helm-traefik    ServiceAccount  kube-system

or

$ kubectl who-can use psp/database-psp
ROLEBINDING                  NAMESPACE  SUBJECT    TYPE            SA-NAMESPACE
podsecuritypolicy:databases  default    databases  ServiceAccount  default

CLUSTERROLEBINDING        SUBJECT         TYPE            SA-NAMESPACE
cluster-admin             system:masters  Group
helm-kube-system-traefik  helm-traefik    ServiceAccount  kube-system

but not with the --all-namespaces flag.

$ kubectl who-can use psp/database-psp --all-namespaces

You cannot authorize SA to PSP with RoleBindings and that's why you get empty result.

[schnatterer]

@danielpacak 🙈 I got the --all-namespaces completely wrong.
I thought of it to broaden the scope like in kubectl get pod --all-namespaces.

But yeah it makes perfect sense that the question answered by kubectl-who-can is "who can use psp in all namespaces" and not "who can use psp per namespace". So --all-namespaces will never show RoleBindings, only ClusteRoleBindings, right?

Thanks very much for taking your time to explain!
I'll definitely advertise kubectl-who-can in my trainings and articles. Thanks for your work!

Closing this.

Slightly offtopic as Post Scriptum:

You cannot authorize SA to PSP with RoleBindings

Don't know if I got you wrong, but I do authorize PSPs to certain SAs using RoleBindings in practice and it works. A PSP might be non-namespaced but SAs and RoleBindings are. So I can authorize a single SA to use a certain PSP. And it's only valid within a certain namespace.

[danielpacak]

@danielpacak 🙈 I got the --all-namespaces completely wrong.
I thought of it to broaden the scope like in kubectl get pod --all-namespaces.

I know that sometimes this flag can be confusing and we actually thought about renaming it to --any-namespace, but on the other hand we want to be consistent with auth can-i and other kubectl commands.

But yeah it makes perfect sense that the question answered by kubectl-who-can is "who can use psp in all namespaces" and not "who can use psp per namespace". So --all-namespaces will never show RoleBindings, only ClusteRoleBindings, right?

Yup, you're right!

Thanks very much for taking your time to explain!
I'll definitely advertise kubectl-who-can in my trainings and articles. Thanks for your work!

❤️ I'm glad that you found it useful and actually contributed to make sure that we handle PSP properly.

Closing this.

Slightly offtopic as Post Scriptum:

You cannot authorize SA to PSP with RoleBindings

Don't know if I got you wrong, but I do authorize PSPs to certain SAs using RoleBindings in practice and it works. A PSP might be non-namespaced but SAs and RoleBindings are. So I can authorize a single SA to use a certain PSP. And it's only valid within a certain namespace.

I agree with you. I meant that you cannot authorize SA to PSP in any namespece / all namespaces with RoleBindings. For a certain namespace, as you said, it works.