workload-identity

What problem does it solve?

Workload identity designs often devolve into long-lived secrets, weak trust boundaries, or unclear migration paths, making service-to-service authentication fragile and risky across Kubernetes and multi-cloud environments.

Core Features & Use Cases

• SPIFFE vs Cloud IAM decision workflows: choose the correct identity substrate per workload class using explicit scoring dimensions and produce an ADR boundary.
• Production-grade SPIRE on EKS workflows: deploy SPIRE with HA, Vault PKI upstream authority, image-digest selectors, and workload integration guidance.
• Trust-domain federation and cloud bridging: federate trust domains and bridge JWT-SVIDs to AWS/GCP/Azure/Vault via OIDC while pinning claims for hard security guarantees.

Use case: migrating an EKS-based payments platform from shared service account tokens and static cloud credentials to SPIFFE SVIDs for mTLS east-west auth, then using OIDC federation to grant scoped AWS/GCP/Azure permissions without long-lived keys.

Quick Start

Use the workload-identity skill to design and document a SPIFFE-based workload identity approach for your EKS services, including how to bridge to AWS/GCP/Azure cloud IAM using OIDC federation.