skip to content

Your store trusts two issuers and both trust domains mint the subject name data-loader — how can a non-production workload arrive as the production identity?

level: seniorimportance: should knowfreq 46%

answer

  1. unique where, exactly?
  2. a subject is half an identity
  3. an omitted issuer means any issuer
  4. adding an issuer widens old rules
  5. match the pair, per trust domain

basics

~20 s

Subject names are unique only inside the issuer that mints them. A mapping matching the subject alone is satisfied by either trusted issuer, so a workload created with that name in the non-production domain becomes the production identity.

solid answer

~40 s

A subject name is scoped to its issuer and nothing more, so `data-loader` from one trust domain and `data-loader` from another are different principals wearing the same string. If the mapping matches on the subject and does not also pin the issuer, a document from either trusted issuer satisfies it. Someone who can create a workload in the non-production domain — usually the domain where creation is open and administrators are many — chooses that name and is mapped onto the production local identity. The signature check does not save you, because both issuers are trusted and the signature is genuine. The fix is to key every mapping on the issuer and subject together, with a separate local identity per trust domain.

code

yaml · 8 lines
yaml
trustedIssuers:
  - issuerId: domain-prod
  - issuerId: domain-nonprod      # added later, open workload creation

identityMappings:
  - matchSubject: data-loader     # no issuer named, so either one matches
    localIdentity: prod-data-loader
    grantedFor: nightly-extract

go deeper

for a junior

Recall that a subject name only means something together with the issuer that minted it, never on its own.

for a middle

Explain why an unspecified issuer in a mapping behaves as a wildcard, and what the pair-keyed version changes.

for a senior

Spot that adding an issuer rewrote the meaning of untouched rules, and run the audit that finds every mapping it widened.

for a principal

Require pair-keyed mappings and per-domain local identities as a condition of trusting any additional issuer, so the audit never has to be retrospective.

## Subject names are issuer-scoped, and only that An issuer guarantees uniqueness inside its own domain. It says nothing at all about what names another issuer hands out, because it has no relationship with that issuer and no view of its name space. So a subject is only meaningful as a pair: **which issuer said it, and what it said**. A bare subject string is half an identity. This is easy to lose sight of, because for as long as a store trusts exactly one issuer, the subject really is unambiguous. Mappings written in that period are correct. They stop being correct the moment a second issuer is trusted, and nobody edits them to make that happen. ## What adding an issuer did to rules nobody touched This is the mechanism worth naming in an answer: **trusting an additional issuer widens every pre-existing mapping that did not name one**. An unspecified issuer in a mapping is not 'none', it is 'any' — the absence of a constraint, not a narrower constraint. So the change that created the exposure is not in the mapping's own history at all. It is in a different part of the configuration, made by someone solving a different problem, possibly months later. | what the mapping keys on | who satisfies it | when it becomes wrong | |---|---|---| | subject only | any caller either trusted issuer names that way | the day a second issuer is trusted | | issuer and a subject pattern | anything matching the pattern in that one domain | when that domain's naming changes | | issuer and a stable subject identifier | one caller | only if that identifier is reissued, which it must not be | ## The direction the attack runs It runs from the weaker domain into the stronger one, which is the opposite of how people picture it when they describe the second issuer as 'only non-production'. - The non-production domain is usually where anyone can create a workload without review. - It usually has more administrators, looser joining rules, and casual naming. - Creating a workload named `data-loader` there is not an exploit; it is ordinary use of that domain. - The document that workload presents is genuinely signed by an issuer you genuinely trust. - Every check the store runs therefore passes, and it maps the caller onto the production local identity. Nothing is forged and nothing fails, which is why this is caught by review rather than by alerting. ## The fix, and what it costs 1. **Key every mapping on the issuer and the subject together.** This is the whole correction; everything else supports it. 2. **Give each trust domain its own local identities.** Two domains sharing one local identity destroys attribution even when the mapping is correct, because the access trail can no longer say which side acted. 3. **Prefer a stable subject identifier over a name** in the subject half of the pair, so the pin cannot be moved by a rename on their side. 4. **Treat an omitted issuer as a defect**, not as a default. If the configuration format allows it to be left out, that is a wildcard with friendly syntax. The cost is real but small: more rows, less reuse, and an onboarding step that must record which domain a caller belongs to. Compare that with the alternative, which is a production identity reachable from a domain you deliberately hold to a lower standard. ## What to audit whenever an issuer is added Adding an issuer changes the meaning of rules you did not edit, so it belongs in review alongside those rules. The audit is short: - every mapping that does not name an issuer; - every local identity now reachable from more than one trust domain; - every mapping whose subject half is a pattern rather than an exact value, since patterns collide far more easily than exact names; - the naming conventions of the new domain against the ones your existing pins assume. ## The generalisation worth stating Uniqueness always has a scope, and the scope is usually one system. Any time an identifier crosses a boundary — between issuers, between tenants, between environments — carrying its scope with it stops being pedantry and becomes the thing that keeps two different principals apart. A store that trusts more than one issuer is a store where every bare name is ambiguous until proven otherwise.

  • Why is the non-production trust domain the dangerous one here?
    Because it is where workload creation is open, administrators are many, and naming is casual — which is exactly what makes minting a chosen subject name easy. Nothing has to be broken into: someone creates a workload with the right name in a domain you also trust, and every check passes.
  • The configuration lets the issuer be omitted from a mapping. How should you read that?
    As a wildcard over every trusted issuer, present and future. An omitted constraint is the absence of a rule, not a narrower one. The mappings to audit first are the ones written before a second issuer existed — unambiguous then, open now.
  • Would stronger verification have prevented this?
    No. The document is genuine and signed by an issuer you trust, so signature checking, freshness and every other per-document check pass exactly as designed. The defect is in the admission rule, which asked a question that two different principals can both answer correctly.

Two towns each issue staff badges numbered from one. Accept both towns' badges but check only the number, and badge seventeen from the smaller town opens the larger town's doors.

saying these in an interview costs you the question

  • Assumes subject names are globally unique across issuers.
  • Thinks adding a second issuer only affects mappings written afterwards.
  • Reads an unspecified issuer in a mapping as none rather than any.
  • Believes a non-production domain is harmless because it holds no data.
  • Says the signature check would catch the wrong trust domain.