Securing the Usage of volumeMounts with Kubewarden | SUSE Communities

Securing the Usage of volumeMounts with Kubewarden


Securing a Kubernetes cluster is far from a simple task. How do you know if you have correctly configured volumeMounts in your in-cluster containers? And what about all those workload resources, such as Deployments, Jobs, Pods, etc? Luckily, you can use Kubewarden, an efficient Kubernetes policy engine that runs policies compiled to Wasm. This means you can run powerful specifically-written policies, our reuse existing Rego policies for example.

If you prefer not to reuse policies, we present the new volumeMounts Kubewarden Policy.  This Kubewarden policy inspects containers, init containers, and ephemeral containers and restricts their usage of volumes by checking the volume name used in the container’s volumeMounts[*].name.

You can find the policy in published in Artifact Hub. As usual, its artifact is signed with Sigstore in keyless mode, and if you are curious, you can peek into the policy’s implementation in Rust here.

This new policy joins the already existing volumes-psp policy, which provides an allowlist of volume types, and hostpaths-psp policy, with an allowlist of hostPath volumes.

What is useful about the new volumeMounts policy?

The existing PSP policies restricted the usage of volumes as a cluster admin. The new volumeMounts policy has settings with 4 operators that enable you to check for compliance and migration use cases, even if you don’t have access to controlling the creation of Volumes in the cluster. Let’s see them:

  • reject: anyIn: Works as a denylist of your usage of volumes. Since we are checking volume names, we can also filter Out-Of-Tree volumes:
    reject: anyIn
    - my-secure-hostpath-volume
    - my-cache-volume
    - my-out-of-tree-volume
  • reject: anyNotIn: Works as an allowlist.
    reject: anyNotIn
    - my-secrets-volume
    - my-volume2
  • reject: allAreUsed: The container cannot use all listed volumes at once. Helpful for enforcing migration between volumes, for example:
    reject: allAreUsed
    - old-deprecated-volume
    - new-supported-volume
  • reject: notAllAreUsed: The container can use all listed volumes at once, but only one of them. Helpful for enforcing backup operations, for example:
    reject: notAllAreUsed
    - work-volume
    - backup-volume

In action

Just instantiate an AdmissionPolicy or cluster-wide ClusterAdmissionPolicy with the policy module and settings. Here’s a definition of a policy that rejects any workload resource (Pods, Deployments, Cronjobs..) that doesn’t adhere to the provided volumeMounts allowlist:

kubectl apply -f - <<EOF
kind: ClusterAdmissionPolicy
  name: volumemounts-policy
  mutating: false
  - apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods", "deployments", "replicasets", "daemonsets", "replicationcontrollers", "jobs", "cronjobs"]
    - CREATE
    - UPDATE
    reject: anyNotIn # as an allowlist
    - my-volume
    - my-volume2

Let’s instantiate a Pod that uses a Volume with a name that is not in the allowlist:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
  name: test-pd
  - image:
    name: test-container
    - mountPath: /cache
      name: cache-volume
  - name: cache-volume
    emptyDir: {}

As expected, the Pod is rejected:

Error from server: error when creating "STDIN":
admission webhook "clusterwide-volumemounts-policy.kubewarden.admission" denied the request:
container test-container is invalid: volumeMount names not allowed: ["cache-volume"]

Try the policy for yourself!

As usual, we look forward to your feedback! Have ideas for new policies? Would you like more features on existing ones? Drop us a line at #kubewarden on Slack! 🙂

(Visited 5 times, 1 visits today)