Istiod secret cache keys omitted namespace identity
CVE-2021-34824 allows an authorized client to retrieve TLS credentials cached for another namespace. The fix changes the cache key to include the secret type, name, and resolved namespace.
An authorization check can validate the requested namespace while a cache returns data from another namespace. CVE-2021-34824 is that kind of failure in Istiod's TLS credential distribution. The secret generator checked access to a resolved Secret, but its cache key did not retain all the information identifying that Secret.
The 24 June advisory describes an authorized client retrieving TLS certificates and private keys cached in Istiod. The intended boundary permits a gateway or workload to receive credentials only from Kubernetes Secrets in its own namespace.
I regard workload identity as one of Istio's strongest design choices. That makes correct credential distribution a basic requirement. An authenticated connection proves which workload is asking, but it cannot make an incorrectly identified cached response safe.
CredentialName moves secret delivery through Istiod
The advisory identifies the credentialName field in Gateway and DestinationRule configuration. Those resources can load private keys and certificates from Kubernetes Secrets. Since Istio 1.8, Istiod conveys the material to gateways or workloads through the xDS API.
This architecture places Istiod between the secret store and the consuming proxy. The control plane retrieves the material, constructs the response, and can reuse a cached result. Each stage must preserve the namespace associated with the authorized Secret.
The vulnerability does not require an unauthenticated caller to query Kubernetes Secrets directly. Its advisory describes an authorized client and a failure in the control plane's response behavior. Those credentials are already available to Istiod for legitimate distribution.
That distinction affects the trust boundary. Kubernetes permissions on the Secret remain relevant, but the control plane also needs to enforce the narrower access of each client using its own distribution interface. The authority of the control plane is broader than the authority it should exercise for any one request.
The old key used the unresolved request name
The secret generator in Istio 1.10.1 defined its cache key by prefixing the requested resource name. The 1.10.2 implementation instead includes the secret's type, name, and namespace.
The relevant change is small enough to describe directly. Previously, the return expression used "sds://" + sr.ResourceName. After the correction, it uses "sds://" + sr.Type + "/" + sr.Name + "/" + sr.Namespace.
Resource-name parsing explains why that matters. A name without an explicit namespace is resolved using the proxy's configuration namespace. The same relative resource name can therefore identify different Kubernetes Secrets for different proxies.
If a cache uses only that relative name, distinct resolved Secrets can become indistinguishable to the lookup. Including the resolved namespace makes those entries distinct. The correction brings cache identity into agreement with the identity used to retrieve the actual Kubernetes Secret.
This is an explanation of the implementation difference and the advisory's cross-namespace impact. It does not require guessing an undisclosed exploit sequence or claiming that the cache exposes unrelated data it never contained.
Authorization precedes the cache lookup
The versioned generator shows several checks before producing a result. It requires a verified proxy identity, obtains the secret controller for the proxy's cluster, and authorizes the service account through that controller.
For each requested resource, it parses the secret reference and checks that the proxy's configuration namespace matches the resolved secret namespace. Only then does it consult the cache.
The position of that check is important. A simple review asking whether namespace authorization exists would find it. The failure arises because the subsequent lookup can identify a response less precisely than the authorization check identifies the requested Secret.
On a cache hit, the generator appends the cached response and continues without regenerating it from the secret store. That is the expected purpose of caching. It is also why an incorrect key can cross a boundary despite a correct check on the request being processed.
The security property must connect the check to the returned bytes. Verifying permission for one resolved object is insufficient if the response is selected using an identifier that can also represent another object.
The cached response includes private key material
The generator constructs Envoy secret responses containing certificate chains and private keys as inline bytes. That makes the advisory's confidentiality concern direct. A response can contain the material needed for TLS use, not merely a public certificate name.
A public certificate and its private key have different confidentiality requirements. The advisory explicitly includes both, so describing the issue only as certificate metadata leakage would omit the consequential part of the finding.
The source also distinguishes CA-only secret responses using the -cacert suffix. Its dependency mapping accounts for related names with and without that suffix so updates can keep associated data synchronized.
Those details show why secret caching has several identity requirements. A cache entry needs the correct namespace and resource type, and invalidation needs to track the related Kubernetes configuration. Fixing one requirement does not make the others irrelevant.
The published change specifically repairs the cache key's identity. The advisory does not establish that every other cache or secret-distribution mechanism has the same flaw. Its scope remains the described Istiod path.
Relative names need context before reuse
A relative secret reference can be convenient because configuration does not have to repeat its namespace. That convenience leaves the resolution context as part of the reference's meaning. Two proxies in different namespaces can submit the same text while referring to different objects.
The corrected key stores the resolved identity instead of relying on that text alone. This lets the cache retain the distinction already made by resource parsing and authorization. The difference is visible even without changing the client-facing resource-name format.
Exposure depends on all the published conditions
The advisory lists three conditions that must hold together. The cluster uses an affected Istio version, Gateway or DestinationRule configuration specifies credentialName, and Istiod caching has not been disabled through PILOT_ENABLE_XDS_CACHE=false.
The affected versions are every 1.8 patch release, 1.9.0 through 1.9.5, and 1.10.0 through 1.10.1. The fixed patch versions are 1.9.6 and 1.10.2 for their respective branches.
The 1.10.2 release announcement confirms the security correction. The 1.9.6 announcement supplies the corresponding supported-branch update.
For 1.8 users, the disclosure directs operators to their Istio provider for updates. A post should preserve that instruction instead of inventing a universally published fixed 1.8 patch.
These conditions also prevent overstatement. An affected version alone does not satisfy the advisory's complete exposure test. The credential configuration and cache setting are part of the assessment.
Disabling the cache trades performance for mitigation
If an upgrade is not feasible, the advisory recommends disabling Istiod caching with PILOT_ENABLE_XDS_CACHE=false. It warns that this can affect system and Istiod performance because it disables xDS caching.
That mitigation matches the disclosed mechanism. Without the vulnerable cache behavior, responses do not follow the same incorrectly keyed reuse path. The cost is losing the performance benefit of cached generation.
This is an explicit operational tradeoff from the source. It should not be presented as a free configuration improvement that every cluster should retain indefinitely. The corrected implementation preserves caching while distinguishing the resolved secret identity.
The source does not provide a universal estimate of that performance cost. Workload-specific numbers would need measurements that are not part of this disclosure. The useful claim is the documented tradeoff and the setting that implements it.
Cache identity must match authorization identity
My judgement is that this is a particularly instructive control-plane vulnerability because the authorization code is visible before the cache access. The defect is not explained by the complete absence of authentication or a namespace check.
Instead, a relative request name and a resolved secret identity were treated as interchangeable at the cache boundary. The corrected key records the type, name, and namespace that distinguish the data the generator is permitted to return.
That requirement applies to the response as well as the incoming request. Istiod must authorize a client for the selected Secret and ensure that any reused response belongs to that same resolved identity. The 1.9.6 and 1.10.2 corrections restore that relationship for the credential distribution described in the advisory.