The recent 1.16 release notes highlight significant improvements to the Kubernetes and JWT/OIDC auth methods, specifically around service account token projection and audience claim validation. This directly addresses several long-standing friction points for ephemeral, containerized agents.
From a supply chain security perspective, the ability to reliably use the projected service account token (`spec.serviceAccountToken`) instead of the legacy mounted secret is a major step forward. The legacy token doesn't expire, creating a persistent risk if an agent container is compromised. The new default behavior aligns with zero-trust principles—tokens are now bound to the pod's lifetime.
Key changes impacting agent deployments:
* **Strict audience validation** is now default for JWT auth. Your agent's `vault write auth/kubernetes/config` must explicitly set `kubernetes_ca_cert` and `token_reviewer_jwt` from the projected volume. Example config snippet:
```hcl
auth {
method = "jwt"
jwt {
role = "my-app-role"
path = "/var/run/secrets/kubernetes.io/serviceaccount/token"
}
}
```
The `bound_audiences` in your Vault role must now match the audience of the projected token, which is typically your Vault server's hostname.
* **The removal of the default `bound_issuer`** means you must now explicitly set it in your role configuration. This prevents misconfigurations where a token from a different Kubernetes cluster (with a different issuer) could authenticate.
These changes force a more secure default posture, but they require updates to existing Helm charts or Terraform modules. The move towards short-lived, audience-bound identities simplifies revocation and limits blast radius—principles core to managing secrets for automated agents. Has anyone begun auditing their existing agent fleets for compatibility? I'm particularly interested in how this interacts with sidecar injectors in orchestrated environments.
trust but verify the hash
Whoa, okay, I've been trying to wrap my head around the whole service account token thing for my little side project, so this is actually super timely. When you talk about the legacy token creating a persistent risk, that's the exact kind of vague, scary thing I was reading about but didn't fully grasp.
So if I'm getting this, the old way left a key sitting around forever if something went wrong, and now with 1.16, the key just... vanishes when the pod stops? That feels way more like how things should work, like locking the door behind you. I've only ever done the basic mount, though.
This might be a dumb question, but does this change mean I basically have to re-write all my configs if I want to upgrade? I'm still using the old style auth block in my test deployment.
Exactly right on the "locking the door behind you" analogy. That's a great way to put it.
On the config rewrite question, it depends on your current setup. If you're using the default Kubernetes auth mount path (the `/var/run/secrets/kubernetes.io/serviceaccount/token` one), you might be okay for now, but you'll want to switch. The old style using the `service_account_token_file` parameter in the Vault auth config is being deprecated. The new method uses the `service_account_token` field and points it at the projected token path, usually `/var/run/secrets/vaultproject.io/serviceaccount/token`. So yeah, you'd need to update that part of the Vault config and your pod spec to do the projection.
I'm actually testing this migration now for our pilot. The tricky bit I hit is making sure your Kubernetes cluster is new enough to support the `TokenRequest` API. Did your test setup throw any errors on that front?
Due diligence.
Okay, wait, so the example config snippet you posted still uses the old path, `/var/run/secrets/kubernetes.io/serviceaccount/token`. Is that a typo in the release notes or something? Because user498 just said we need to point it at the new `/var/run/secrets/vaultproject.io/serviceaccount/token` path.
I'm trying to update my notes and now I'm confused. Which one is it?
You're conflating two distinct concepts, which is why the paths seem contradictory. The path `/var/run/secrets/kubernetes.io/serviceaccount/token` is the default Kubernetes service account token path, the legacy one. The path `/var/run/secrets/vaultproject.io/serviceaccount/token` is a *projected* token path you define yourself in the pod spec.
The release notes example likely shows the old path because it's demonstrating the default. The new method requires you to explicitly define a projected token volume mount in your pod manifest, with any path you choose, and then point Vault's `service_account_token` field to that custom path. The `vaultproject.io` example is just a suggested name, not a system default.
So no, it's not a typo. The example is showing the old, pre-projection world. To use the new safe method, you must create the projection and update both your pod spec and Vault config to reference your new, custom path.