ADR-004: Roles and Service Accounts


We need to define roles and service accounts to allow all our use cases. Our first concerns are to allow the following:

  • Users should be able to deploy (manually in test cluster, via the deploy API in production clusters), but we do not want them by default to read secrets
  • Admins should get full access to all resources, mostly for emergency access
  • Applications should not get by default write access to the Kubernetes API
  • It should be possible for some applications to write to the Kubernetes API.


We define the following Roles:

  • ReadOnly: allowed to read every resource, but not secrets. “exec” and “proxy” and similar operations are not allowed. Allowed to do “port-forward” to special proxy, which will enable DB access.
  • PowerUser: “restricted” Pod Security Policy with write access to all namespaces but kube-system, ReadOnly access to kube-system namespace, “exec” and “proxy” are allowed, RW for secrets, no write of daemonsets. DB access through “port-forward” and special proxy.
  • Operator: “privileged” Pod Security Policy with write access to the own namespace and read and write access to third party resources in all namespaces.
  • Controller: Kubernetes component controller-manager is not allowed to “use” other Pod Security Policies then “restricted”, such that serviceAccount authorization is used to check the permission. To all other resources it has full access.
  • Admin: full access to all resources

And the following pairs <namespace, service account> that will get the listed role, assigned by the WebHook:

  • “kube-system:default” - Admin
  • “default:default” - ReadOnly
  • “*:operator” - Operator
  • kube-controller-manager - Controller
  • kubelet - Admin

Application that will want write access to the Kubernetes API will have to use the “operator” service account.




This decision is a breaking change of what was previously defined for applications. Users that need applications with write access to the Kubernetes API will need to select the right service account. The controller-manager has now an identity and uses the secured kube-apiserver endpoint, such that it can be authorized by the webhook.