{"id":12638,"date":"2026-07-06T21:23:22","date_gmt":"2026-07-07T02:23:22","guid":{"rendered":"https:\/\/www.rushworth.us\/lisa\/?p=12638"},"modified":"2026-11-02T10:05:53","modified_gmt":"2026-11-02T15:05:53","slug":"who-is-allowed-to-become-agent-xyz-attestation-and-identity-issuance","status":"publish","type":"post","link":"https:\/\/www.rushworth.us\/lisa\/?p=12638","title":{"rendered":"SPIFFE: Who Is Allowed to Become Agent XYZ? Attestation and Identity Issuance"},"content":{"rendered":"

The first security question is not whether a certificate or token can be verified. It is whether the system should have issued that identity in the first place. An attacker who satisfies an overly broad issuance policy can receive authentic credentials; signature verification will then work exactly as designed.<\/p>\n

Node evidence and workload evidence are separate<\/h2>\n

SPIRE uses node attestation to establish an agent\u2019s eligibility and workload attestation to determine the identities available to local callers. Registration entries associate a SPIFFE ID with selectors and a parent identity. Agents obtain relevant entries and compare caller evidence with them.<\/p>\n

For architecture review, identify the evidence producer, the administrator able to influence it, and the verifier relying on it. A cloud instance identity, a Kubernetes service-account assignment, and a local process UID have different provenance and compromise assumptions. Do not treat three labels derived from one mutable source as three independent factors.<\/p>\n

An illustrative registration policy<\/h2>\n
identity: spiffe:\/\/agents.example.org\/agent\/xyz\r\nparent: <eligible attested node or node group>\r\nrequired workload evidence:\r\nnamespace: agents-prod\r\nservice_account: agent-xyz\r\ncredential lifetime: <reviewed deployment setting<\/pre>\n
Namespace and service-account evidence can be useful, but ask who can create a pod using that account. If a developer can choose the privileged account while creating an arbitrary pod, the selectors alone do not distinguish the intended workload from the developer\u2019s replacement. Add controls at the deployment boundary: reviewed manifests, admission policy, appropriately scoped RBAC, and protected automation identities. These are complementary infrastructure controls, not properties supplied by SPIRE.<\/p>\n\n\n\n\n\n\n\n\n
Evidence or control<\/strong><\/td>\nWho may influence it?<\/strong><\/td>\nReview question<\/strong><\/td>\n<\/tr>\n
Namespace\/service-account assignment<\/strong><\/td>\nPod creators and deployment automation<\/td>\nCan an unrelated workload use XYZ\u2019s account?<\/td>\n<\/tr>\n
Unix process UID<\/strong><\/td>\nHost administrators and privileged processes<\/td>\nCan the attacker execute as that UID?<\/td>\n<\/tr>\n
Registration entry<\/strong><\/td>\nSPIRE registration administrators\/controllers<\/td>\nCan a broad entry issue privileged identities?<\/td>\n<\/tr>\n
Node enrollment<\/strong><\/td>\nInfrastructure and attestation administrators<\/td>\nCan an unauthorized node become eligible?<\/td>\n<\/tr>\n
Workload API access<\/strong><\/td>\nHost\/container isolation administrators<\/td>\nCan another process obtain or steal the credential?<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
 <\/p>\n
Choose the identity boundary deliberately<\/h2>\n
A SPIFFE ID often represents a service or deployment with many replicas. It is not necessarily a unique process-instance identifier. A single orchestrator running multiple logical agents with shared credentials does not create independently attested identities merely by assigning different agent names. Use isolated workloads and distinct policies where separate security principals are required. Preserve execution IDs as audit metadata rather than presenting them as attestation evidence. The Workload API identifies local callers under its implementation\u2019s security boundary.<\/p>\n
Attestation establishes eligibility under configured evidence rules; it is not a behavioral verdict. Prompt injection, malicious dependencies, or compromised application logic may all exist inside an eligible workload. Credential theft and local isolation also remain in the threat model.<\/p>\n
Configuration-review checklist<\/h2>\n
    \n
  • Enumerate every registration entry that can issue XYZ\u2019s identity, including controller-generated entries.<\/li>\n
  • Map every selector to its evidence source and modification privileges.<\/li>\n
  • Test an unauthorized workload that intentionally resembles XYZ.<\/li>\n
  • Document whether replicas share an identity and how individual runs are correlated.<\/li>\n
  • Separate registration administration from ordinary application deployment wherever practical.<\/li>\n
  • Require review of broad selector changes and retain a recoverable history of issuance policy.<\/li>\n<\/ul>\n
    Takeaway: issuance policy is an authorization boundary. Reviewing the SPIFFE ID string without reviewing who can satisfy its evidence is an incomplete security review.<\/p>\n","protected":false},"excerpt":{"rendered":"
    The first security question is not whether a certificate or token can be verified. It is whether the system should have issued that identity in the first place. An attacker who satisfies an overly broad issuance policy can receive authentic credentials; signature verification will then work exactly as designed. Node evidence and workload evidence are …<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2243],"tags":[2246,2244,2216,2245],"class_list":["post-12638","post","type-post","status-publish","format-standard","hentry","category-spiffe","tag-agent-identity","tag-spiffe","tag-spire","tag-workload-identity"],"_links":{"self":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/12638","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=12638"}],"version-history":[{"count":2,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/12638\/revisions"}],"predecessor-version":[{"id":12668,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/12638\/revisions\/12668"}],"wp:attachment":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=12638"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=12638"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=12638"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}