Kubernetes 1.30 (April 17, 2024) and 1.31 (August 13, 2024) each shipped around 45 enhancements, but only a dozen of them matter for cluster security posture. The headline item is the graduation of ValidatingAdmissionPolicy to GA in 1.30, which for the first time puts a CEL-based admission mechanism in the in-tree API, directly competing with the Open Policy Agent and Kyverno ecosystems. Also notable: 1.31 introduced OCI artifact-backed VolumeSource as alpha, tightened anonymous API access, and finally deprecated the in-tree cloud providers that have been a recurring source of secret-leakage advisories. This post walks the changes an AppSec or platform engineer should actually wire into their next release train, including the ones that will break your existing policies.
Why does ValidatingAdmissionPolicy going GA matter?
Because it removes the single biggest excuse for clusters not running policy as code. Before 1.30, enforcing "no privileged pods" or "all images must be signed" meant deploying either Gatekeeper (and learning Rego) or Kyverno (and running a third-party admission controller). ValidatingAdmissionPolicy uses CEL, the same expression language already used by kubectl explain and CRD validation, and it runs inside the API server with no additional pod to manage. In clusters where OPA or Kyverno was ruled out on operational cost grounds, there is now no reason to leave policy unenforced.
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
name: no-privileged-containers
spec:
failurePolicy: Fail
matchConstraints:
resourceRules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE", "UPDATE"]
resources: ["pods"]
validations:
- expression: "!object.spec.containers.exists(c, c.securityContext.privileged)"
message: "Privileged containers are not allowed"
What does OCI VolumeSource change?
1.31 introduced image as a VolumeSource type (KEP-4639), letting a pod mount an OCI artifact directly as a read-only volume. This is a quiet but significant change for supply chain security: it creates a supported path to distribute config, policy bundles, and WASM modules through the same registry infrastructure that signs and verifies container images. Instead of packaging an Open Policy Agent bundle as an init container that curls a tarball, you can ship the bundle as an OCI artifact, sign it with Cosign, and mount it by digest. The admission-time verification story becomes homogeneous.
Is anonymous API access finally dead?
Almost. 1.31 did not remove anonymous access but it did ship AnonymousAuthConfigurableEndpoints in alpha, which lets cluster operators allow anonymous only on specific endpoints like /livez and deny it on everything else. That is not the same as "off by default," but it does give operators a supported way to close the gap that has historically made every misconfigured kubelet and every accidentally-exposed API server a one-request data breach. The hardening maturity model now looks like: 1.29 and earlier, you hack it with --anonymous-auth=false and hope nothing breaks; 1.31, you enumerate the endpoints explicitly.
What broke in RBAC or auth?
Two things worth flagging. First, ServiceAccount tokens no longer include the legacy extra claim, which some third-party webhooks depend on; expect a small number of tool-chain breakages. Second, the --service-account-issuer-discovery flag is now required on any cluster that federates with an external OIDC consumer, which a lot of CI systems do for workload-identity. These are not security regressions, but they will surface as auth failures in staging if you upgrade without regression tests.
How does the container image supply chain story evolve?
Sigstore and image-signing requirements are now closer to first-class than ever. The combination of OCI VolumeSource, ValidatingAdmissionPolicy, and the ImageVolume feature gate lets you write a CEL policy that literally says "this pod may only mount images whose digest has been signed by our prod key." Previously that required either an OPA/Kyverno rule with cosign verify wired through an external webhook, or a custom admission controller. The in-tree path is not yet turnkey, but the primitives are all present.
What should platform teams do this quarter?
Three concrete actions. First, stand up at least one ValidatingAdmissionPolicy in warn mode, pick one that your OPA or Kyverno deployment already enforces, to start building organizational competence in CEL. Second, move any init-container config-fetchers to OCI artifact volumes on a pilot cluster. Third, audit your kubelet exposure against the AnonymousAuthConfigurableEndpoints alpha definition, even if you cannot turn it on yet, because it documents what a hardened baseline looks like.
How Safeguard Helps
Safeguard treats Kubernetes cluster configuration as part of the software supply chain, not as a separate operational concern. Our policy gates evaluate your ValidatingAdmissionPolicy corpus against industry benchmarks like NSA/CISA Kubernetes Hardening Guide v1.2 and flag gaps that new features in 1.30 and 1.31 actually let you close. SBOM analysis covers container images, OCI artifacts used as volumes, and cluster components themselves, so a CVE in kube-apiserver lands against the specific cluster versions you run. Griffin AI translates NSA guidance and CIS benchmarks into concrete CEL policies for ValidatingAdmissionPolicy, and reachability analysis tells you which workloads would actually be blocked if you flipped a policy from warn to fail, so the rollout is data-driven rather than a pager incident.