> ZERO-TRUST // zt-arch-04
Secretless Multi-Cloud Workload Identity Federation
Elimination of static cloud API secrets by establishing short-lived OpenID Connect (OIDC) trust relationships between GitHub Actions, Kubernetes, AWS IAM, GCP, and Azure.
Adversary Threat Model
Adversary extracts long-lived secrets from CI/CD pipeline variables, using them for persistent cloud resource hijacking.
Architecture Specs
NIST SP 800-207 Tenets Enforced
- ✓Access to individual enterprise resources is granted on a per-session basis.
- ✓The enterprise collects as much information as possible about the current state of network infrastructure and communications.
MITRE ATT&CK Techniques Blocked
3 Maturity Tier Configurations
Evolutionary engineering configurations from baseline Initial up to CISA Optimal zero-compromise fortress.
GitHub Actions configured with AWS OIDC provider for production deployments.
Short-lived IAM role assumption (TTL 1 hour) scoped to repository branch.
Standard AWS IAM STS endpoint over public HTTPS.
CloudTrail AssumeRoleWithWebIdentity logging.
Cross-cloud federated identity across AWS, GCP Workload Identity, and on-prem Kubernetes.
Claims-based attribute checks enforcing Git commit SHA, environment, and signed tag.
AWS STS VPC Endpoints used exclusively for internal workload token exchange.
Automated drift detection alerting on unauthorized identity federation providers.
Dynamic multi-cloud mesh with zero long-lived credentials anywhere across edge, cloud, and DBs.
Sub-15-minute ephemeral tokens dynamically bound to SPIFFE IDs and SLSA L3 provenance.
Air-gapped private STS routing with egress identity filtering.
Continuous cryptographic ledger auditing of all federated token assumptions.
Infrastructure as Code: Terraform & Kubernetes
Production-ready declarative manifests for immediate automated deployment.
resource "aws_iam_openid_connect_provider" "github" {
url = "https://token.actions.githubusercontent.com"
client_id_list = ["sts.amazonaws.com"]
thumbprint_list = ["6938fd4d98bab03faadb97b34396831e3780aea1"]
}
resource "aws_iam_role" "ci_deploy" {
name = "TinyCTO-GitHub-Deploy"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Action = "sts:AssumeRoleWithWebIdentity"
Effect = "Allow"
Principal = { Federated = aws_iam_openid_connect_provider.github.arn }
Condition = {
StringEquals = {
"token.actions.githubusercontent.com:aud" = "sts.amazonaws.com"
}
StringLike = {
"token.actions.githubusercontent.com:sub" = "repo:tiny-cto/tinycto-tv:ref:refs/heads/main"
}
}
}]
})
}apiVersion: v1
kind: ServiceAccount
metadata:
name: finops-collector-sa
namespace: analytics
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/TinyCTO-Finops-CollectorElimination of static cloud API secrets by establishing short-lived OpenID Connect (OIDC) trust relationships between GitHub Actions, Kubernetes, AWS IAM, GCP, and Azure.
Architecture Blueprint FAQs
How does the Secretless Multi-Cloud Workload Identity Federation blueprint mitigate adversary threats and MITRE ATT&CK techniques?
Secretless Multi-Cloud Workload Identity Federation addresses the following adversary profile: Adversary extracts long-lived secrets from CI/CD pipeline variables, using them for persistent cloud resource hijacking. It actively eliminates lateral movement and privilege escalation by mitigating: T1552.001, T1078.004, T1537, T1580 via hardware-rooted identity, kernel-level enforcement, or continuous attestation.
Which NIST SP 800-207 Zero-Trust tenets does this architecture enforce?
This blueprint strictly operationalizes the following NIST SP 800-207 tenets: Access to individual enterprise resources is granted on a per-session basis.; The enterprise collects as much information as possible about the current state of network infrastructure and communications.. Implicit trust based on network location is replaced with per-session dynamic cryptographic verification.
What are the technical differences between the Initial and Optimal maturity tiers?
The Initial tier focuses on baseline policy and identity enforcement (GitHub Actions configured with AWS OIDC provider for production deployments.), while the Optimal tier delivers CISA ZTMM 2.0 zero-compromise fortress defense (Dynamic multi-cloud mesh with zero long-lived credentials anywhere across edge, cloud, and DBs.) using: hashicorp-vault-oidc, aws-irsa, azure-workload-identity, spiffe-oidc.
What is the primary failure mode risk and how is high availability guaranteed?
The primary failure risk is identified as: STS rate limiting throttles under burst microservice scaling events.. Resilience is maintained through active-active control planes, local cached attestations, and graceful degradation playbooks.
How can engineering teams automate this architecture using Terraform and Kubernetes?
The provided declarative Terraform HCL (main.tf) and Kubernetes policy manifests (policy.yaml) can be immediately integrated into automated GitOps CI/CD pipelines (e.g., ArgoCD, Flux) for reproducible, drift-detected infrastructure provisioning.