Kubernetes 1.35 pod certificates and constrained impersonation: what they actually fix

Summary. Kubernetes v1.35, "Timbernetes (The World Tree Release)", landed on 17 December 2025 with 60 enhancements: 17 stable, 19 beta, 22 alpha. Two SIG Auth changes got read as a zero-trust upgrade. Pod Certificates (KEP-4317) graduated to Beta after more than two years in progress, and constrained impersonation (KEP-5284) arrived as net-new Alpha behind the ConstrainedImpersonation gate, defaulting to false. The framing that followed was wrong in a specific way worth understanding. Pod Certificates do not give you service mesh mTLS. The KEP names pod-to-pod mTLS as a non-goal, Kubernetes ships no built-in signer for application workloads, and John Howard, an Istio maintainer, tested it on v1.35.0 on 22 December 2025 and concluded: "There will likely be no impact; I do not think Pod Certificates are a feature that will make a meaningful difference on service meshes." Sysdig's 2 December 2025 preview counted 17 security-related changes in the release and put the gate default at true; Howard's post-release test found it off. The certificate signing request API has been stable since Kubernetes 1.19 in 2020, and over 99% of Istio certificate flows already run through paths that predate this KEP. Constrained impersonation is not an mTLS feature at all; it is an authorisation check on the impersonation verb. Both are real and useful. Neither replaces Istio, SPIRE or cert-manager. This guide covers what each one actually does, the YAML that works, the gates you must turn on, and where the sources disagree.

What Kubernetes 1.35 actually shipped for SIG Auth

Kubernetes v1.35 was published on 17 December 2025 and carried 60 enhancements, of which 17 reached stable, 19 beta and 22 alpha, per the official release announcement. Sysdig counted 17 changes touching security features across the release.

The two that drew the zero-trust headlines both come from SIG Auth:

Feature	KEP	Stage in 1.35	Feature gate	Default
Pod Certificates	4317	Graduating to Beta	PodCertificateRequest	Sources disagree; see below
Constrained impersonation	5284	Net new to Alpha	ConstrainedImpersonation	false
Harden kubelet serving cert validation	4872	Net new to Alpha	KubeletCertCNValidation	false
Structured Authentication Config	3331	Graduating to Stable	StructuredAuthenticationConfiguration	true
SPDY to WebSockets transition	4006	Graduating to Stable	AuthorizePodWebsocketUpgradeCreatePermission	true

Those last two will affect more clusters than the first two, and we will come back to why.

Pod Certificates: what the feature is

Pod Certificates give Kubernetes a way to automatically issue X.509 certificates to Pods. The mental model is the one you already have for service account JWT tokens, moved to TLS certificates.

The certificate signing request API went stable back in Kubernetes 1.19, which gave you a way to request and obtain X.509 certificates. What it never gave you was a clean way to get those certificates into your workloads. That is the gap KEP-4317 closes. It adds two things: the PodCertificateRequest API, and a podCertificate projected volume source that tells the kubelet to provision a certificate for the Pod.

Here is a Pod that asks for one, in the shape Sysdig documents:

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: pod-certificates-example
spec:
  restartPolicy: OnFailure
  automountServiceAccountToken: false
  containers:
  - name: main
    volumeMounts:
    - name: spiffe-credentials
      mountPath: /run/workload-spiffe-credentials
  volumes:
  - name: spiffe-credentials
    projected:
      sources:
      - podCertificate:
          signerName: "row-major.net/spiffe"
          keyType: ED25519
          credentialBundlePath: credentialbundle.pem

The volume source can also split the chain and key into separate files rather than a bundle. From John Howard's hands-on walkthrough on v1.35.0:

      volumes:
      - name: pcr-x509
        projected:
          defaultMode: 420
          sources:
          - podCertificate:
              keyType: RSA4096
              signerName: coolcert.example.com/foo
              certificateChainPath: cert.pem
              keyPath: key.pem

Inside the Pod you then have an ordinary key pair on disk:

$ curl https://... --key /var/run/pcr-x509/key.pem --cert /var/run/pcr-x509/cert.pem

The part the headlines skipped: Kubernetes does not sign anything

This is the sentence that reframes the whole feature. From Howard's teardown: "Kubernetes itself does not issue any certificates; it is up to an external controller to watch for these requests and issue certificates. There is no built-in controller that can be used for application workloads."

So the flow is: kubelet generates a private key, kubelet creates a PodCertificateRequest, and then nothing happens until a signer controller you deployed notices it and fills in status.certificateChain. The signerName field in your volume source is the name of that external controller.

A PodCertificateRequest carries proof of who is asking. The spec includes nodeName, nodeUID, podName, podUID, serviceAccountName, serviceAccountUID, pkixPublicKey, proofOfPossession, maxExpirationSeconds and signerName. The status carries certificateChain, notBefore, notAfter, beginRefreshAt and conditions such as CertificateIssued. That is a genuinely good API: the signer gets verifiable assertions about the Node, Service Account and Namespace behind the request, signed by the kubelet, rather than having to trust a self-asserted identity.

Two operational details follow from the design. Unlike CSRs, PodCertificateRequests have no approval phase; the signer's controller decides to issue or deny directly. And a kube-controller-manager controller deletes terminal PodCertificateRequests older than 15 minutes, so every issuance flow is expected to finish inside that window.

The feature gate question, where sources disagree

Be careful here, because the published guidance conflicts.

Sysdig's 1.35 preview, published 2 December 2025 before the release, lists Pod Certificates as graduating to Beta with feature gate PodCertificateRequest defaulting to true.

Howard, testing the released v1.35.0 on 22 December 2025, writes that "even in Beta, the feature is off-by-default", and his working kind config turns on both the API group and the gate:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
runtimeConfig:
  "certificates.k8s.io/v1beta1/podcertificaterequests": "true"
featureGates:
  "PodCertificateRequest": true

The reconciliation is probably the API group rather than the gate. Kubernetes does not enable new beta APIs by default, so certificates.k8s.io/v1beta1 needs an explicit --runtime-config entry regardless of what the gate defaults to. The practical answer is the same either way: set both, verify on a throwaway cluster, and do not assume your managed control plane exposes either knob. On EKS, GKE or AKS you may not be able to set --runtime-config at all, which quietly ends the conversation for a lot of teams.

The API object itself is certificates.k8s.io/v1beta1, kind: PodCertificateRequest.

Why this is not service mesh mTLS

The KEP is explicit, and Howard is blunt about it: "The KEP specifies pod-to-pod mTLS (i.e. service mesh) as a non-goal, though the feature has evolved to somewhat help service meshes."

His argument against mesh impact is worth reading in full, but the load-bearing parts are these.

The ecosystem solved this a decade ago. In the Istio space, certificates already arrive by the built-in Istio CA, which needs zero external dependencies and has the proxy generate an in-memory key and request signing over an internal gRPC API; by cert-manager's istio-csr, which implements the same API and plugs in cert-manager's large set of backing CAs; or by SPIRE over the SPIFFE Workload API. Cert-manager also ships a CSI driver that behaves almost identically to Pod Certificates. Howard puts the first group at over 99% of use cases.

For an existing mesh, adopting Pod Certificates is at best neutral and mostly worse. Private keys have to live on the filesystem rather than in memory, which is generally considered less secure. The end-to-end flow gains components: kubelet, the PodCertificateRequest resource, an external signer controller, and a direct dependency on the API server. And there is no end-user benefit to show for it.

Then there is a hard blocker. The KEP only covers one certificate for one Pod. Istio's ambient mode does not work that way: one Pod, ztunnel, holds a certificate for each other Pod on the same Node. Howard notes there is no support for that in the KEP and, as far as he knows, no plans to add it, which makes the KEP unusable with ambient mode.

The honest engineering read: this is plumbing for a problem most mesh users already stopped having. The real cost was never certificate distribution, it was CA lifecycle, and Pod Certificates does not take that off your plate.

So what is it good for

Three cases survive scrutiny.

Pod-to-pod mTLS without a service mesh gets slightly easier. Certificate distribution is one of the annoying parts of do-it-yourself mTLS, and this removes that part. It does not turn DIY mTLS into a solved problem, and Howard is direct that it does not enable a generic "mTLS everywhere without service mesh" setup.

Authenticating to the API server with mTLS instead of service account tokens is, reading between the lines of the KEP, closer to the original intent. The security argument is that certificates are not vulnerable to replay the way bearer JWTs are. If this lands in the standard client libraries, it becomes a low-cost improvement for workloads that talk to the API server.

A brand-new service mesh built from scratch could reasonably build on it rather than writing its own distribution layer. Howard doubts many new meshes will be built, and suspects any that are would pick SPIFFE or cert-manager.

There is also a future worth watching. If the API server eventually ships built-in signers that can fully implement a CA, that would free Istio from acting as a CA. The same components still run, but there are fewer CAs to manage. That is a real benefit, and it does not exist yet.

Constrained impersonation is a different feature entirely

Bundling constrained impersonation into an mTLS story is a category error. It has nothing to do with certificates or transport security. It is an authorisation control on the impersonation mechanism.

Kubernetes impersonation lets one identity act as another. It is genuinely useful, most obviously for an admin debugging an authorisation policy: impersonate the user, submit the request, see whether it is denied. The problem is that the mechanism has historically had no granularity. Grant someone impersonate on a user, and they get everything that user can do. That breaks least privilege.

KEP-5284 adds the missing check. Sysdig's description: "With ConstrainedImpersonation enabled, users won't be able to perform any action while impersonating someone that they couldn't perform on their own."

The KEP introduces verb prefixes, impersonate:<mode>: to impersonate a type of subject such as a user or service account, and impersonate-on:<mode>:<verb>: to perform a specific action on a resource. In effect it requires two separate permissions: permission to impersonate a specific identity, and permission to perform specific actions at a particular scope while impersonating, for example only list and watch on pods in the default namespace.

It is Alpha, gated behind ConstrainedImpersonation, default false. Treat it as a signal about direction, not a control you deploy this quarter.

The 1.35 changes that will actually page you

If you are upgrading to 1.35, the zero-trust features are not your risk. These are.

Change	KEP	What breaks
cgroup v1 support disabled by default	5573	Nodes on cgroups v1 fail; failCgroupV1 defaults to true
Ensure secret pulled images	2535	Pod creation failures on credential gaps; more image pulls
SPDY to WebSockets	4006	kubectl exec and port-forward need the create verb
Structured Authentication Config	3331	--authentication-config is incompatible with --oidc-* flags; API server exits
Kubelet cert CN validation	4872	Non-conforming kubelet certs rejected once enabled

Check your nodes before you upgrade:

$ stat -fc %T /sys/fs/cgroup/
cgroup2fs

The WebSockets one deserves a second look because it is a real RBAC change hiding inside a transport change. WebSocket connections all start as GET and can be upgraded, which would let read-only users escalate to running kubectl exec. To close that, the API server now requires the create verb whenever a connection upgrade is requested. Review your RBAC before upgrading; you can temporarily set AuthorizePodWebsocketUpgradeCreatePermission to false while you fix it.

The structured authentication one is a hard stop rather than a degradation: --authentication-config and the old --oidc-* arguments are incompatible, and the API server reports the misconfiguration and exits immediately.

And KEP-4872 is the certificate change that actually improves your security posture this release. It closes a real attack: an attacker with access to an old node holding a still-valid certificate configures that node's IP to match a new node's IP through ARP poisoning or routing attacks, then impersonates the new node to the API server and reroutes traffic to itself. The mitigation requires the CN of the kubelet's serving certificate to equal system:node:<nodename>. If your kubelets got their certificates through a CSR, you are already compliant; anything issued manually needs reissuing.

What we would do

If a platform team asked us to act on 1.35 this quarter, the order would be: audit cgroups v2 across the fleet, fix RBAC for the WebSocket create verb, migrate OIDC flags to --authentication-config on a non-production cluster first, then look at KEP-4872. Pod Certificates would be a spike on a kind cluster, not a roadmap item, unless you are doing mTLS without a mesh and are currently hand-rolling certificate distribution. Constrained impersonation goes on the watch list until Beta.

If you are already running Istio, Linkerd or SPIRE, the correct action on Pod Certificates in 1.35 is to read the KEP and do nothing. That is not cynicism; it is the maintainer's own read, and it saves a quarter.

There is plenty else in 1.35 worth your attention: our write-ups on in-place pod resize and rightsizing and on gang scheduling and the Workload API for GPU jobs cover changes with a clearer payback than pod certificates. If your platform runs agent workloads, prompt injection guardrails is a closer fit for the zero-trust budget.

India-specific considerations

For Indian teams running regulated workloads, the relevant 1.35 items are the boring ones. Under India's Digital Personal Data Protection Act 2023, your obligations attach to how personal data is processed and who can reach it, and the impersonation gap KEP-5284 closes is squarely an access-control concern: an operator granted impersonate today inherits everything the impersonated identity can do, including reading personal data they have no business reading. Until ConstrainedImpersonation is Beta, that gap is closed with RBAC discipline and audit, not with a feature gate.

The same logic applies to Pod Certificates. Reaching for mesh-grade mTLS to satisfy a data-protection requirement is usually the wrong instrument. We design applications aligned with DPDP requirements by controlling who can reach the data and proving it in audit logs, and transport encryption is one layer of that rather than the whole answer.

FAQ

Did Pod Certificates reach Beta in Kubernetes 1.35?

Yes. KEP-4317 graduated to Beta in Kubernetes v1.35, released on 17 December 2025, after more than two years in progress. The API object is certificates.k8s.io/v1beta1, kind PodCertificateRequest. Beta here does not mean on by default, and you should verify the gate and API group on a test cluster.

Do Pod Certificates replace Istio or SPIRE?

No. The KEP names pod-to-pod mTLS as a non-goal. Istio maintainer John Howard tested it on v1.35.0 and concluded there will likely be no impact on service meshes, because existing meshes already solve certificate distribution through the Istio CA, cert-manager istio-csr or SPIRE. He puts those at over 99% of use cases.

Does Kubernetes issue the certificates itself?

No, and this is the detail most summaries miss. The kubelet generates a key and creates a PodCertificateRequest, but Kubernetes ships no built-in signer for application workloads. An external controller you deploy must watch for requests and populate status.certificateChain. The signerName field in your volume source names that controller.

Why will Pod Certificates not work with Istio ambient mode?

The KEP only supports one certificate for one Pod. Ambient mode inverts that: a single ztunnel Pod holds a certificate for every other Pod on the same Node. Howard reports there is no support for this in the KEP and no plans he knows of to add it, which makes the two incompatible today.

What does constrained impersonation actually do?

It stops an impersonator from exceeding their own permissions. With the ConstrainedImpersonation gate enabled, users cannot perform any action while impersonating someone that they could not perform on their own. It requires two permissions: to impersonate an identity, and to take specific actions at a defined scope.

Is constrained impersonation safe to enable in production?

Not yet. KEP-5284 is net-new Alpha in 1.35 behind the ConstrainedImpersonation feature gate, which defaults to false. Alpha features can change shape or be withdrawn between releases. Treat it as direction of travel and keep closing impersonation gaps with careful RBAC grants and audit logging instead.

What will actually break when we upgrade to 1.35?

cgroup v1 support is disabled by default, so check nodes report cgroup2fs first. The SPDY to WebSockets move requires the create verb for kubectl exec and port-forward upgrades. And --authentication-config is incompatible with the old --oidc-* flags; the API server exits immediately on that misconfiguration.

Which 1.35 certificate change is worth enabling?

KEP-4872, hardening kubelet serving certificate validation, closes a real attack where an old node with a valid certificate takes over a new node's IP and impersonates it. It requires the certificate Common Name to equal system:node:nodename. It is Alpha behind KubeletCertCNValidation, default false, so pilot it.

How eCorpIT can help

eCorpIT is a CMMI Level 5 certified engineering organisation in Gurugram, and our senior engineering teams do Kubernetes upgrade planning and platform security work of exactly this kind: auditing what a release actually changes for your clusters rather than what the release notes suggest. As an AWS, Microsoft and Google partner we work across managed control planes where feature gates are often not yours to set. If you are scoping a 1.35 upgrade or deciding whether pod certificates belong on your roadmap, talk to us and we will review it against your actual cluster topology.

References

1. Kubernetes v1.35: Timbernetes (The World Tree Release), Kubernetes Blog, 17 December 2025.
2. Kubernetes v1.35 Pod Certificates won't help your service mesh, John Howard, 22 December 2025.
3. Kubernetes 1.35 - New security features, Victor Jimenez Cerrada and Leonardo Grasso, Sysdig, 2 December 2025.
4. KEP-4317: Pod Certificates, Kubernetes Enhancements.
5. KEP-5284: Constrained Impersonation, Kubernetes Enhancements.
6. KEP-4872: Harden Kubelet serving certificate validation, Kubernetes Enhancements.
7. KEP-4006: Transition from SPDY to WebSockets, Kubernetes Enhancements.
8. Certificates and Certificate Signing Requests, Kubernetes Documentation.
9. User Impersonation, Kubernetes Documentation.
10. CHANGELOG-1.35.md, kubernetes/kubernetes.
11. cert-manager istio-csr, cert-manager Documentation.
12. SPIRE, SPIFFE.
13. cert-manager CSI driver, cert-manager Documentation.
14. Kubernetes 1.35 - Deep dive into new alpha features, Palark.
15. Kubernetes user namespaces, Kubernetes Documentation.
16. Kubernetes cgroups architecture, Kubernetes Documentation.

Last updated: 16 July 2026.