1

Is this not possible to do? According to the docs:

System administrators, use care when granting access to pod creation. A user granted permission to create pods (or controllers that create pods) in the namespace can: read all secrets in the namespace; read all config maps in the namespace; and impersonate any service account in the namespace and take any action the account could take. This applies regardless of authorization mode.

https://kubernetes.io/docs/reference/access-authn-authz/authorization/#privilege-escalation-via-pod-creation

I would like for a user to be able to create a pod, but if they specify a ServiceAccount in the pod spec that has more permissions than they do, forbid the action. Even better, they shouldn't be allowed to specify a ServiceAccount, even if they have pod creation permissions, without an extra special permission.

Is there any way to achieve what I am looking for?

Andrew Moffat
  • 111
  • 1

1 Answers1

1

You need to use admission plugins in order to control pod specs, volumes and which images are allowed.

PodSecurityPolicy admission plugin lets you control what volumes and privileges a pod spec can contain, and the ImagePolicyWebhook admission plugin lets you control what images your pod can run:

A Pod Security Policy is a cluster-level resource that controls security sensitive aspects of the pod specification. The PodSecurityPolicy objects define a set of conditions that a pod must run with in order to be accepted into the system, as well as defaults for the related fields.

The ImagePolicyWebhook admission controller allows a backend webhook to make admission decisions.

With the help of the methods above you can prevent privileged pods from starting and control privilege escalation by controlling security sensitive attributes of pod specification.

EDIT:

If mounting privileged service accounts on pods can’t be avoided, it is strongly advised to grant them minimum permissions possible. It is also recommended to do checks the permissions across the environment and remove unnecessary permissions.

In order to find any risky permissions in the environment you can use KubiScan:

A tool for scanning Kubernetes cluster for risky permissions in Kubernetes's Role-based access control (RBAC) authorization model.

Wytrzymały Wiktor
  • 731
  • 3
  • 10
  • The PodSecurityPolicy and ImagePolicyWebhook don't seem to be able to restrict the ServiceAccounts associated with the Pod spec. Do I need to write a custom admission plugin? – Andrew Moffat Sep 03 '20 at 15:26