Enforcing StorageClass Usage at the Workload Level

[pohanhuangtw]

Description

This policy restricts the usage of specific StorageClasses by Kubernetes resources.

Currently, the policy enforces checks at the PersistentVolumeClaim (PVC) level — PVCs using forbidden StorageClasses are rejected.

Unlike persistentvolumeclaim-storageclass-policy just prevent the pvc dreatehion, this policy should enforce at the workload level (e.g., rejecting a Deployment if any of its PVCs reference a forbidden StorageClass), similar to what NeuVector supports.

Restricting which StorageClasses can be used is useful in scenarios such as limiting workloads to a trusted storage provider or preventing the use of unsupported classes.

Configuration

You must configure either deniedStorageClasses or allowedStorageClasses (but not both).

# A list of storage classes that are forbidden.
# This setting is mutually exclusive with allowedStorageClasses.
deniedStorageClasses:
  - fast
  - nvme

# A list of storage classes that are permitted.
# This setting is mutually exclusive with deniedStorageClasses.
allowedStorageClasses:
  - standard
  - slow

Examples

❌ Denied Example

Configuration

deniedStorageClasses:
  - fast
  - nvme

PersistentVolumeClaim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-fast
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: fast   # forbidden StorageClass

Deployment using this PVC

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-using-fast
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
        - name: busybox
          image: busybox
          command: ["sleep", "3600"]
          volumeMounts:
            - name: data
              mountPath: /data
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: pvc-fast

👉 Result: This Deployment will be denied, because it references pvc-fast, which is bound to a forbidden StorageClass (fast).

---

✅ Allowed Example

Configuration

allowedStorageClasses:
  - standard
  - slow

PersistentVolumeClaim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-standard
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: standard   # explicitly allowed

Deployment using this PVC

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-using-standard
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
        - name: busybox
          image: busybox
          command: ["sleep", "3600"]
          volumeMounts:
            - name: data
              mountPath: /data
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: pvc-standard

👉 Result: This Deployment will be accepted, because it references pvc-standard, which is bound to an allowed StorageClass (standard).

[jvanz]

That's looks a nice policy to have indeed! Let me share some steps help who else decide to code the policy in go lang:

1. Repository preparation. Follow the steps from our quick start guide to learn how to set up the basic policy structure. Once the policy stub is ready, you can start write the policy you want to.
   1. Update the policy OCI name
   2. Update the metadata.yml file with the policy correct data (e.g. title, author, url, context aware configuration, etc)
2. Write a README file explaining the policy. The policy documentation should have a high level description of the policy and its goals. As well as the settings available and some policy usage examples.
3. Change the settings.go file adding the expected policy settings and its validation. In this policy, you will add the deniedStorageClasses and allowedStorageClasses fields in the Settings struct. And change the Valid() function to perform the settings validation. Ensuring that both list cannot be used together. This changes also include unit tests in the settings_test.go file.
4. Update the validate.go file to actual perform the policy logic. As well as the validate_test.go to test the policy. I can see multiples steps in the policy logic implementation:
   1. Parse the incoming request payload. See example here
   2. Extract pod spec from the AdmissionRequest. For this, you can use a function available in the Go lang SDK that know to get this data from the Kubernetes resources. See example here
   3. Once you have the PodSpec, get the PVC name in use and call the Kuberwarden host capability to fetch data from the Kubernetes cluster.
   4. When you have the PVC data returned by the Kubewarden host capability, check if the storageClassName is complaint with the policy settings.
   5. If the storageClassName in use is valid, call AcceptRequest. See an example here
   6. If the storageClassName in use in invalid, call RejectRequest. See examples here
5. Add e2e tests to run the policy using kwctl and validate the policy as it will run in the policy server. In this cases, you can simulate the host capabilities call using the --replay-host-capabilities-interactions flag as described here
6. Ensure the CI is able to build the policy. The template repository should have all the required CI workflow to build, test and release the policy.

It's important to know that context aware policies, like this one, requesting Kubernetes resources must define which kind of resources they are expected to fetch from the cluster. Therefore, it's necessary to update the policy metadata.yml file adding the PVC resource in the list. See an example here.See more Kubewarden documentation about this. It's important to properly populate the metadata.yml to allow kwctl scaffold the manifest to deploy the policy later with all the required data to make it work.

This also means that the policy server running this policy requires additional RBAC permissions to access the PVC resources. To change the default ServiceAccount used by the policy server, define the ServiceAccount name with the aditional permission in the spec.serviceAccountName field in the PolicyServer definition.

I hope not forgetting something important

[jvanz]

@kubewarden/kubewarden-developers can you review my proposal on how to implement this policy? 😁

[viccuad]

@jvanz thanks for the detailed list! Looks great to me!

There's several ways to work on a new policy, in the past we have created a personal repo from the go template clicking on the "use this template" button on the top right.
We have then opened a first PR adjusting the things on the template and adding the README.md, with explanations and examples of how the policy settings look like so follow-up PRs implementations can reference the README.md.
Once the policy is done, the repo is donated to the kubewarden GH org.