API key
Universal fallback, including AWS ECS/Fargate.
What BlackShield verifies
BlackShield verifies the issuer, audience, asymmetric signature, key ID, token time bounds, active tenant, and every exact claim binding. External role/scope claims and ordinary account/project labels never grant access. Workload tokens are accepted only by machine endpoints, not dashboard or admin APIs.
Projected token
Kubernetes/EKS or custom rotating OIDC token file, reread for every request.
GCP metadata
Audience-bound full-format identity tokens on Cloud Run and GCE.
Azure managed identity
Entra access tokens bound to the managed identity's immutable oid.
Set up and operate
- Create and validate a trusted issuer in Identity settings.
- Create an enabled binding for exact signed
sub,azp, oroidvalues and choose only required machine scopes. - Select that binding in the scanner install wizard. Compatible bundles omit the BlackShield secret.
- Rotate issuer keys normally; unknown key IDs trigger one bounded JWKS refresh. Disable the binding for immediate scanner revocation.
Troubleshooting
Validate discovery/JWKS first, then compare issuer, audience, exact signed claims, binding scopes, and token time bounds. Projected Kubernetes tokens must use the BlackShield audience, not the AWS STS audience. A scoped API key remains available as a fallback.
Open the Kubernetes deployment guide →Provider prerequisites
- GCP metadata identity tokens must use the configured BlackShield audience and full token format.
- Azure managed identity tokens must expose the immutable signed
oidbound in BlackShield. - Kubernetes/EKS projected tokens need a dedicated BlackShield audience. ECS/Fargate continues to use API keys because task roles expose AWS credentials rather than a generic OIDC JWT.