Kubernetes 1.27, released April 11, 2023, shipped 60 enhancements across 18 KEPs, several of which carry real security weight. The headline item is the graduation of the SeccompDefault feature gate, which lets cluster operators apply RuntimeDefault seccomp profiles to every workload without touching workload manifests. Alongside it, the Pod Security Admission controller graduated a set of baseline and restricted profile refinements, the ValidatingAdmissionPolicy feature reached beta, and the API server added several field-level validations that close long-standing edge cases. This post is aimed at cluster operators deciding what to upgrade for, and at platform engineering teams whose security posture depends on which bits are actually enabled. We focus on the items that change defender posture, not the full release grab bag.
Why is SeccompDefault graduation a big deal?
SeccompDefault graduation is a big deal because it finally lets operators flip the kubelet's --seccomp-default flag and have every pod that does not specify its own profile fall back to the container runtime's RuntimeDefault. Without this, the default was Unconfined, meaning every container could make any syscall Linux exposed, including the set that enables kernel exploitation. RuntimeDefault blocks roughly 65 dangerous syscalls such as kexec_load, bpf, and ptrace unless explicitly required. Most workloads run unchanged on the default profile; only a small percentage (language runtimes that use unusual syscalls, profilers, debuggers) need a custom profile.
# kubelet config snippet
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
seccompDefault: true
What changed with Pod Security Admission?
Pod Security Admission (PSA) in 1.27 received refinements to the restricted profile, including stricter enforcement of allowPrivilegeEscalation: false and clarifications to the runAsNonRoot check that previously allowed ambiguous behavior when a container image set USER as a numeric UID in a non-canonical form. PSA has been GA since 1.25, so the change here is incremental correctness rather than new capability. The practical operator takeaway is to re-run PSA audits against production namespaces after upgrading, because small semantic shifts can surface workloads that previously passed the baseline profile and now require attention.
How mature is ValidatingAdmissionPolicy in 1.27?
ValidatingAdmissionPolicy reached beta in 1.27, which means cluster operators can run CEL-based admission logic in-cluster without deploying an external webhook like OPA Gatekeeper or Kyverno. The value is a much faster admission path (no network hop), easier cold-start behavior, and simpler ops surface. The tradeoff is that CEL's expressiveness is narrower than Rego and policy authors must restructure complex allowlists. A common starter pattern is to port "require non-root user" and "deny host network" policies to ValidatingAdmissionPolicy first, then leave complex cross-resource logic in Gatekeeper.
apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingAdmissionPolicy
metadata:
name: "deny-privileged"
spec:
failurePolicy: Fail
matchConstraints:
resourceRules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE","UPDATE"]
resources: ["pods"]
validations:
- expression: "!object.spec.containers.exists(c, c.securityContext.privileged == true)"
Did 1.27 improve kubelet and API server defaults?
Yes. Kubelet dropped support for command-line flags that had been deprecated since 1.23, forcing operators onto the KubeletConfiguration file and reducing the chance of misconfigured flags surviving an upgrade. The API server tightened StructuredAuthenticationConfig validation and made a handful of informer paths more deterministic during failover. None of these are headline features, but each closes an edge case that can produce silent misconfiguration. The 1.27 changelog also removed kubectl run support for the --port and --limits flags, which pushes users toward manifests (a net security positive because manifests are easier to review and audit).
What about in-place pod resize and its security implications?
In-place pod resize, alpha in 1.27, changes CPU and memory requests/limits without recreating the pod, which has operational benefits but new security considerations. An attacker with sufficient RBAC to modify pod specs can now escalate resource use without forcing a scheduler cycle. The KEP addresses this by respecting the existing LimitRange and ResourceQuota admission pathways, so namespace-level limits still apply. Clusters that rely on admission to enforce resource caps should re-test once this feature progresses, and teams should ensure the pods/resize subresource is gated in RBAC to minimize the new path to privilege.
What should you prioritize when upgrading?
Prioritize five changes when planning a 1.27 upgrade. First, flip seccompDefault: true in kubelet config after validating a small workload subset. Second, re-run PSA dry-run checks in audit mode on production namespaces. Third, port at least one Gatekeeper policy to ValidatingAdmissionPolicy to get operational experience with the new admission path. Fourth, audit which kubelet flags you rely on and migrate to KubeletConfiguration. Fifth, inventory any tooling that manipulates pods via kubectl run --port or --limits and convert it to manifests. Do the first two before the upgrade, the remaining three within 30 days after.
How Safeguard Helps
Safeguard ingests cluster SBOMs, admission logs, and runtime pod specs to continuously evaluate your 1.27 security posture against a policy library that maps to CIS Kubernetes Benchmark v1.27, NSA/CISA Hardening Guidance, and PSA profiles. Griffin AI explains failing admission events in natural language, produces targeted remediations, and drafts ValidatingAdmissionPolicy YAML when a Gatekeeper policy can be ported. Reachability analysis joins the container SBOM with runtime call graphs so you know whether a CVE in a base image is actually exposed via a workload's listening ports. TPRM tracks container-image suppliers and flags upstream base images that regress on security updates. Policy gates block deployments that drop seccomp: RuntimeDefault without an explicit, justified override.