StorageClass
Does ZopNight manage StorageClass?
StorageClasses decide 3 cost-relevant things before any pod runs: which disk tier the provisioner creates, whether reclaimPolicy Delete or Retain destroys the disk when its claim goes, and when binding happens. ZopNight records provisioner, reclaimPolicy, volumeBindingMode, allowVolumeExpansion, and the isDefault flag, because the default class silently prices every claim that names none.
Rules that fire on StorageClass
No active rule family targets StorageClass today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
A StorageClass is the template every dynamically provisioned volume is cut from. It costs nothing itself, but it decides which disk tier gets created, what happens to the disk when its claim is deleted, and when provisioning happens at all. Those three decisions price storage before any pod runs.
One default class prices every unlabelled claim
Discovery records an isDefault flag per class because the default is where the leverage is: any PVC that names no class gets the default, so a cluster whose default class provisions a premium tier silently upgrades every casual claim to expensive storage. The provisioner is stored as the resource’s instance type (ebs.csi.aws.com, pd.csi.storage.gke.io, disk.csi.azure.com), which is also how you tell at a glance what kind of disk each class creates.
Delete or Retain: what the class does to dead disks
The class-level reclaimPolicy is stamped onto every PV it provisions. Delete means removing a claim removes the cloud disk and ends its bill; Retain means removing a claim leaves a Released volume billing until manual cleanup. Classes with Retain deserve to be the exception with a reason attached, because every PVC churned through them adds one more disk to the orphan pile the released-volume rule exists to catch.
Binding mode, expansion, and what else is captured
volumeBindingMode is recorded too: Immediate provisions the disk the moment the claim is created, while WaitForFirstConsumer delays until a pod actually schedules, which both places the disk in the right zone and avoids paying for storage no pod ever used. allowVolumeExpansion rounds out the record; when true, undersized claims can grow in place instead of being recreated, which removes one excuse for over-provisioning up front.
kubectl get storageclass -o custom-columns=NAME:.metadata.name,PROVISIONER:.provisioner,RECLAIM:.reclaimPolicy,BINDING:.volumeBindingMode,EXPANSION:.allowVolumeExpansionReviewing a cluster’s classes
Two questions cover most of the audit: is the default class the cheapest tier that satisfies typical workloads, and does anything still use Retain without a data-retention justification? Both answers are readable straight from the 5 fields discovery keeps per class.