Skip to content
TrustPlane

Trust Anchor source availability

Every Trust Anchor Source kind that appears in the Control console’s create wizard is selectable, but not every kind is currently supported for enrollment. This matrix states, per source profile, its configuration surface, whether it is supported today, and what a production deployment requires. The CLI flags in the configuration column are the trustplane enroll provider flags from CLI v0.2.2.

The matrix

Section titled “The matrix”
Source profile Configuration Availability Requirements
Manual Client Vault public key Public key registered directly in Client Vault; no automated source, no enrollment policy, no capacity slot Supported No automated proof validation; rotation and revocation are manual operator actions. Key custody and rotation procedure; revocation runbook; verify the key’s provenance out of band
OIDC JWKS Console: issuer, JWKS URI, audience. CLI: --provider oidc_jwks with --proof-file or --proof-stdin (for example a projected ServiceAccount token) Supported Proof must be supplied explicitly (file or stdin); enrollment validates evidence once — it does not bind later requests to the original pod. Follow the OIDC JWKS enrollment runbook; issuer and JWKS reachable from Control; narrow audience and required verified-subject binding; renewal via re-enroll before expiry
Kubernetes service-account OIDC Console: OIDC issuer, optional public JWKS URI override, audience. CLI: --provider kubernetes_service_account_oidc with --kubernetes-token-file (defaults to the projected ServiceAccount token path) Not currently supported Do not plan on this kind; use the generic OIDC JWKS profile pointed at the cluster OIDC issuer — that is the supported path
CI OIDC Console: issuer, JWKS URI, audience for CI-issued OIDC identities. CLI: --provider ci_oidc with --ci-token-file or --ci-token-env Not currently supported For future support: narrow organization/repository policy selectors; short proof lifetimes typical of CI tokens accounted for in renewal planning
SPIFFE JWT-SVID Console: JWT-SVID issuer, trusted JWKS URI, SPIFFE trust domain, audience. CLI: --provider spiffe with --spiffe-jwt-file or --spiffe-workload-api Not currently supported JWT-SVID only in TA-G1; SPIFFE X.509 SVID is also not currently supported. For future support: trust domain and SPIFFE ID constraints in the enrollment policy; a reachable Workload API if not using a proof file
AWS EC2 instance identity Console: AWS partition or provider identity, AWS account, region, public AWS signing certificate (PEM). CLI: --provider aws_ec2_iid with --aws-iid-document-file and --aws-iid-signature-file (IID acquired from IMDSv2 by the CLI) Not currently supported Always operator-approved in TA-G1 (no automatic approval); account + region alone are too broad as an authorization boundary. For future support, see the EC2 subsection below: exact instance-identity verification model, certificate provenance, freshness/replay controls, narrow identity constraints
GCP instance identity Console: provider identity, GCP project, audience. CLI: --provider gcp_instance_identity; proof transport per the console’s enrollment command generator Not currently supported For future support: project-scoped and identity-scoped policy selectors verified against real instance evidence
Azure instance identity Console: immutable per-revision proof mode — managed_identity_jwt (issuer, JWKS URI, expected audience, tenant ID, optional subscription ID) or imds_attested_document (public Azure IMDS trust-root certificate PEM, optional tenant/subscription IDs). CLI: --provider azure_instance_identity with --azure-pkcs7-file and --azure-compute-metadata-file, or --azure-imds-attested-document Not currently supported Proof mode is fixed per source revision; enrollment commands cannot switch modes. For future support: tenant/subscription constraints in policy for the chosen proof mode; IMDS trust-root provenance verified before pasting the PEM

OIDC JWKS and Manual Client Vault public key are the supported enrollment paths today. Every other row in this table describes what the console and CLI offer as configuration, not a currently supported enrollment path.

AWS EC2 instance identity: requirements for future support

Section titled “AWS EC2 instance identity: requirements for future support”

The current EC2 console fields (account, region, signing certificate) describe where an instance lives, not which instance it is. Account plus region alone are too broad as an authorization boundary: any instance in that account and region that can read its own instance identity document would satisfy them. Support for a production EC2 profile requires:

  • An exact instance-identity verification model — precisely which fields of the IID document are verified, and against what expected values.
  • Certificate provenance — the public AWS signing certificate (PEM) pasted into the source must be obtained and verified from AWS documentation channels, not from the instance being enrolled.
  • Freshness and replay controls — an IID document and signature are static artifacts; the profile must bound how old a document may be and prevent the same captured document from being replayed for a second enrollment.
  • Narrow identity constraints — policy selectors that pin the expected instance identity (not just its account and region) so a compromised neighbor instance cannot enroll.

Source or observed IP address is defense in depth, not durable primary identity — instance IPs are reassigned and NAT-translated, so an IP match must never be the deciding control.

Where to go next

Section titled “Where to go next”