k3s: Error: enable-admission-plugins plugin "PodSecurityPolicy" is unknown

Describe the bug Enabling the admission plugin PodSecurityPolicy fails with an error Error: enable-admission-plugins plugin "PodSecurityPolicy" is unknown.

To Reproduce I’m running k3d helper like this (same behavior with k3s:v0.5.0 and k3s:v0.6.0-rc2)

$ k3d create -p 6444 -i docker.io/rancher/k3s:v0.6.0-rc2 --server-arg=--kube-apiserver-arg=enable-admission-plugins=PodSecurityPolicy

The docker container running k3s fails to start, and the logs include:

time="2019-05-30T20:40:16.287817900Z" level=info msg="Running kube-apiserver --tls-cert-file=/var/lib/rancher/k3s/server/tls/localhost.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/token-node.key --advertise-address=127.0.0.1 --api-audiences=unknown --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --requestheader-allowed-names=kubernetes-proxy --requestheader-username-headers=X-Remote-User --service-account-issuer=k3s --basic-auth-file=/var/lib/rancher/k3s/server/cred/passwd --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-group-headers=X-Remote-Group --watch-cache=false --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --allow-privileged=true --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/localhost.key --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/token-node-1.crt --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-cluster-ip-range=10.43.0.0/16 --insecure-port=0 --secure-port=6444 --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --advertise-port=6445 --enable-admission-plugins=PodSecurityPolicy"
Error: enable-admission-plugins plugin "PodSecurityPolicy" is unknown
Usage:
  kube-apiserver [flags]
...
      --enable-admission-plugins strings       admission plugins that should be enabled in addition to default enabled ones (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, PersistentVolumeClaimResize, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: DefaultStorageClass, DefaultTolerationSeconds, LimitRanger, MutatingAdmissionWebhook, NamespaceLifecycle, NodeRestriction, PersistentVolumeClaimResize, Priority, ResourceQuota, ServiceAccount, TaintNodesByCondition, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.
...

Expected behavior I expect k3s to start with the requested admission plugin.

Additional context My goal is to test that some particular pods run in the presence of some PodSecurityPolicy.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 4
  • Comments: 17 (4 by maintainers)

Most upvoted comments

As can be seen in k3s server command help screen, it is stated that:

admission plugins that should be enabled in addition to default enabled ones (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, PersistentVolumeClaimResize, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: DefaultStorageClass, DefaultTolerationSeconds, LimitRanger, MutatingAdmissionWebhook, NamespaceLifecycle, NodeRestriction, PersistentVolumeClaimResize, Priority, ResourceQuota, ServiceAccount, TaintNodesByCondition, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter

Unfortunately the PodSecurityPolicy isn’t on that list. Either way, it would be nice to know when it will be implemented.

Edit: I found out that PodSecurityPolicy was removed in k3s, probably on purpose 😦. Couldn’t bring it back for myself, it seems that Kubernetes changes related to this functionality are quite deep - or it’s just me with my almost zero knowledge about go 😉. I’m interested in bringing this plugin to k3s - is it planned? Or maybe there’s some way to do build k3s with this plugin?

With k3s >= v0.9.0 you should be able to enable PodSecurityPolicy by passing the server arg --kube-apiserver-arg enable-admission-plugins=PodSecurityPolicy,NodeRestriction

Sounds like we need an issue to track enabling of PodSecurityPolicy admission plugin and bundling the RBAC?

Would it be possible to add the necessary PSPs, (Cluster)Roles and (Cluster)RoleBindings to k3s by default? I think this would make much sense. It wouldn’t hurt to have them there even when the admission plugin is off. I think everything needed to start k3s with the PSP admission plugin should be included, then it would be up to the user to define additional PSPs for their own workload.

For what it’s worth, this is what I used to get it working (note that it is probably more permissive than necessary):

# A permissive PSP that allows anything
# see https://kubernetes.io/docs/concepts/policy/pod-security-policy/#example-policies
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: permissive
  annotations:
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
spec:
  privileged: true
  allowPrivilegeEscalation: true
  allowedCapabilities:
  - '*'
  volumes:
  - '*'
  hostNetwork: true
  hostPorts:
  - min: 0
    max: 65535
  hostIPC: true
  hostPID: true
  runAsUser:
    rule: 'RunAsAny'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'RunAsAny'
  fsGroup:
    rule: 'RunAsAny'
---
# A ClusterRole that allows using the permissive PSP above
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: permissive-psp
rules:
- apiGroups:
  - policy
  resourceNames:
  - permissive
  resources:
  - podsecuritypolicies
  verbs:
  - use
---
# Allow all service accounts in kube-system to use the permissive PSP
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: permissive-psp
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: permissive-psp
subjects:
- kind: Group
  name: system:serviceaccounts