workload-identity

Design SPIFFE/SPIRE or cloud IAM workload identity workflows for Kubernetes and multi-cloud systems.

15|2|Updated Dec 13, 2025
One-click install
npx skills add https://github.com/d-padmanabhan/agent-engineering-handbook --skill workload-identity
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: workload-identity
Source: https://github.com/d-padmanabhan/agent-engineering-handbook/tree/main/skills/workload-identity
Command: npx skills add https://github.com/d-padmanabhan/agent-engineering-handbook --skill workload-identity

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

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.

Frequently Asked Questions about workload-identity

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I migrate Kubernetes workloads off long-lived secrets and static cloud credentials?

To migrate Kubernetes workloads off static secrets, you design secure workload identity using SPIFFE SVIDs for mTLS and bridge to cloud IAM via OIDC federation. This grants scoped, temporary cloud permissions without long-lived keys.

When should I use SPIFFE/SPIRE instead of cloud IAM for workload identity?

Use SPIFFE/SPIRE instead of cloud IAM when you need secure east-west service-to-service authentication across multi-cloud environments. An explicit scoring workflow evaluates your trust boundaries to determine the correct identity substrate for your workload class.

How do I bridge JWT-SVIDs to AWS IAM using OIDC federation?

Bridge JWT-SVIDs to AWS IAM by federating trust domains and exchanging the JWT-SVID for scoped cloud credentials via OIDC federation. This process enforces strict claim pinning for sub and aud to guarantee hard security boundaries.

Does SPIRE deployment on EKS support image-digest-based workload selectors?

Yes, production-grade SPIRE deployment on EKS supports image-digest-based selectors. This enforces trust-domain separation and ensures only verified container images receive workload identity SVIDs.

What are the limitations of using SPIFFE for workload identity in Kubernetes?

SPIFFE workload identity requires strict operational constraints including bounded TTLs, mTLS identity separation from authorization, and production-ready audit monitoring. Failing to enforce these trust-domain boundaries makes service authentication fragile.

Can I federate multiple SPIRE trust domains across different cloud providers?

Yes, you can federate multiple SPIRE trust domains across different cloud providers. This involves bridging JWT-SVIDs to AWS, GCP, Azure, or Vault via OIDC federation while pinning claims to maintain strict security guarantees.