Identity bootstrap
Workload attestation is the process that uses platform evidence to decide which workload identity a running process can receive. Node attestation first establishes trust in the agent or machine that reports workload facts. Workload attestation then selects a process by facts such as orchestrator namespace, ServiceAccount, Pod identity, image, process credentials, or platform metadata.
Attestation bootstraps identity. It does not authorize every request that identity later makes.
Evidence and issuance
Define an attestation policy that maps a set of independently obtained selectors to one identity. Get selectors from the trusted platform or local operating system, not from self-asserted application input. Bind issuance to the attested node and current workload instance. Deliver short-lived credentials through a protected local API and rotate them automatically.
Keep the identity namespace separate from mutable deployment details. A stable service identity can map from a controlled namespace, ServiceAccount, and deployment label set. The issuer must reject ambiguous matches and log which selectors produced the result.
Failure and residual risk
A compromised node agent can claim false workload facts. Mutable labels can redirect identity. An admission weakness can let a workload select another ServiceAccount. Broad selector rules can assign one identity to unrelated processes. Stale registrations can keep issuing after a workload moves or is retired.
Attestation proves only the evidence and verifier chain in its model. It does not prove application integrity unless measured software evidence is part of that model, and even measured code can be exploited after launch.
Pomerium boundary
Pomerium can enforce routes for service identities and can run in cloud-native environments. A separate workload-identity system can attest and issue credentials to callers or upstreams. Operators must configure how Pomerium validates that identity and must not claim that Pomerium performs SPIFFE or platform attestation unless the deployed integration does so.
Evaluation checklist
- Which authority attests the node and which authority observes workload selectors?
- Are selectors obtained from a protected platform path instead of workload input?
- Can one workload match more than one identity or one rule match unrelated workloads?
- Do credentials expire and rotate when the workload, node, or registration changes?
- Can evidence connect an issued identity to the exact attestation policy and selectors?
