ProficientNowTechRFCs

12. Federation

RFC-WORKLOAD-IDENTITY-0001                                     Section 12
Category: Standards Track                                     Federation

12. Federation

← Previous: Service Mesh Integration | Index | Next: Rationale →


12.1 Federation Overview

12.1.1 What is Identity Federation

Identity federation enables workloads in different trust domains to establish mutual trust:

ScenarioFederation Type
Multiple Kubernetes clustersSPIFFE cross-cluster
Different cloud providersWorkload identity federation
Partner organizationsTrust bundle exchange
Hybrid cloudOn-prem to cloud federation

12.1.2 Federation Challenges

ChallengeSolution
Different trust rootsTrust bundle exchange
Network boundariesSecure federation endpoints
Policy consistencyCentralized policy, distributed enforcement
Key managementAutomated rotation, secure storage

12.2 SPIFFE Federation

12.2.1 Trust Domains

Each SPIFFE deployment has a trust domain:

EnvironmentTrust Domain
Production clusterprod.example.com
Staging clusterstaging.example.com
Partner orgpartner.otherorg.com

12.2.2 Federation Bundle

Trust bundles contain public keys for verifying identities:

{
  "trust_domain": "prod.example.com",
  "keys": [
    {
      "kty": "RSA",
      "use": "x509-svid",
      "n": "...",
      "e": "AQAB"
    }
  ],
  "sequence_number": 1
}

12.2.3 Federation Relationship

12.2.4 SPIRE Federation Configuration

# SPIRE Server configuration for federation
server:
  trust_domain: "prod.example.com"
  ca_subject:
    country: ["US"]
    organization: ["Example Corp"]
 
  federation:
    bundle_endpoint:
      address: "0.0.0.0"
      port: 8443
      acme:
        domain_name: "spiffe-federation.prod.example.com"
        email: "security@example.com"
 
    federates_with:
      "staging.example.com":
        bundle_endpoint_url: "https://spiffe-federation.staging.example.com:8443"
        bundle_endpoint_profile:
          https_spiffe:
            endpoint_spiffe_id: "spiffe://staging.example.com/spire/server"

12.2.5 Federation Workflow


12.3 Multi-Cloud Identity

12.3.1 Cloud Workload Identity Federation

Federating between cloud providers:

SourceTargetFederation Path
GKE → AWSGCP WI → AWS STSOIDC token → AssumeRoleWithWebIdentity
EKS → GCPAWS IAM → GCP WIFOIDC token → Workload Identity Pool
AKS → AWSAzure WI → AWS STSOIDC token → AssumeRoleWithWebIdentity

12.3.2 GCP to AWS Federation

Configuration:

# AWS: Trust GCP OIDC
resource "aws_iam_role" "gcp_workload" {
  name = "gcp-workload-access"
 
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = {
        Federated = "arn:aws:iam::${var.account_id}:oidc-provider/container.googleapis.com/v1/projects/${var.gcp_project}/locations/${var.gcp_location}/clusters/${var.gcp_cluster}"
      }
      Action = "sts:AssumeRoleWithWebIdentity"
      Condition = {
        StringEquals = {
          "container.googleapis.com:sub" = "system:serviceaccount:${var.namespace}:${var.service_account}"
        }
      }
    }]
  })
}

12.3.3 AWS to GCP Federation

# GCP: Workload Identity Pool for AWS
resource "google_iam_workload_identity_pool" "aws" {
  workload_identity_pool_id = "aws-pool"
  display_name              = "AWS Workload Pool"
}
 
resource "google_iam_workload_identity_pool_provider" "aws_eks" {
  workload_identity_pool_id          = google_iam_workload_identity_pool.aws.workload_identity_pool_id
  workload_identity_pool_provider_id = "aws-eks"
  display_name                       = "AWS EKS"
 
  aws {
    account_id = var.aws_account_id
  }
 
  attribute_mapping = {
    "google.subject"        = "assertion.arn"
    "attribute.aws_account" = "assertion.account"
  }
}
 
# Bind to GCP service account
resource "google_service_account_iam_binding" "aws_workload" {
  service_account_id = google_service_account.target.name
  role               = "roles/iam.workloadIdentityUser"
 
  members = [
    "principalSet://iam.googleapis.com/${google_iam_workload_identity_pool.aws.name}/attribute.aws_account/${var.aws_account_id}"
  ]
}

12.4 Trust Domain Management

12.4.1 Trust Domain Hierarchy

12.4.2 Trust Domain Policies

PolicyDescription
Full trustAll workloads can communicate
Selective trustOnly specific SPIFFE IDs allowed
One-way trustDomain A trusts B, B doesn't trust A
Transitive trustA trusts B, B trusts C, therefore A trusts C

12.4.3 Trust Bundle Lifecycle


12.5 Cross-Cluster Vault Access

12.5.1 Vault Multi-Cluster Authentication

Workloads in cluster B accessing Vault in cluster A:

12.5.2 Multi-Cluster Auth Configuration

# Enable auth for remote cluster
vault auth enable -path=kubernetes-cluster-b kubernetes
 
# Configure with cluster B's OIDC issuer
vault write auth/kubernetes-cluster-b/config \
    kubernetes_host="https://cluster-b.example.com:6443" \
    kubernetes_ca_cert=@cluster-b-ca.crt \
    issuer="https://oidc.cluster-b.example.com"
 
# Create role for cross-cluster access
vault write auth/kubernetes-cluster-b/role/cross-cluster-app \
    bound_service_account_names=app \
    bound_service_account_namespaces=default \
    policies=cross-cluster-read \
    ttl=1h

12.6 Partner Federation

12.6.1 B2B Federation Requirements

RequirementImplementation
Trust establishmentOut-of-band bundle exchange
Scope limitationSpecific SPIFFE ID patterns
AuditLog all cross-org access
RevocationImmediate bundle removal

12.6.2 Partner Trust Bundle

# Partner federation configuration
federation:
  federates_with:
    "partner.otherorg.com":
      bundle_endpoint_url: "https://spiffe.partner.otherorg.com:8443"
      bundle_endpoint_profile:
        https_web: {}
      # Only trust specific workloads
      trust_bundle_url: "https://spiffe.partner.otherorg.com/.well-known/spiffe-bundle.json"

12.6.3 Scoped Trust

# Only allow specific partner workloads
apiVersion: policy.linkerd.io/v1beta1
kind: ServerAuthorization
metadata:
  name: allow-partner-api
  namespace: b2b-gateway
spec:
  server:
    name: partner-gateway
  client:
    meshTLS:
      identities:
        # Only trust partner's integration service
        - "spiffe://partner.otherorg.com/ns/integration/sa/api-client"

12.7 Security Considerations

12.7.1 Federation Risks

RiskMitigation
Malicious bundle injectionVerify bundle signatures, HTTPS
Over-permissive trustExplicit SPIFFE ID allowlists
Lateral movement via federationSegment federated access
Trust anchor compromiseHSM-backed keys, rotation

12.7.2 Federation Security Controls

ControlImplementation
Bundle verificationHTTPS + SPIFFE endpoint verification
AuditLog all federation events
RevocationImmediate bundle removal capability
Scope limitationSPIFFE ID pattern matching

12.7.3 Zero Trust Federation

Even with federation, apply zero trust:

# Federated workloads still need explicit authorization
apiVersion: policy.linkerd.io/v1beta1
kind: ServerAuthorization
metadata:
  name: federated-access
spec:
  server:
    name: api
  client:
    meshTLS:
      identities:
        # Explicit allow, not wildcard
        - "spiffe://partner.example.com/ns/allowed/sa/client"
      # Deny by default - only listed identities allowed

12.8 Operational Procedures

12.8.1 Establishing Federation

  1. Exchange trust bundles out-of-band (secure channel)
  2. Configure federation endpoints
  3. Test connectivity with restricted workloads
  4. Expand access incrementally
  5. Monitor and audit cross-domain traffic

12.8.2 Rotating Federation Keys

12.8.3 Revoking Federation

# Remove federation relationship
spire-server federation delete -trustDomain partner.example.com
 
# Update mesh policies
kubectl delete serverauthorization -l federation=partner.example.com
 
# Verify revocation
spire-server bundle list

12.9 Compliance Mapping

12.9.1 Invariant Enforcement

InvariantFederation Implementation
INV-1Cross-domain SVIDs still cryptographically verified
INV-6mTLS required for cross-domain communication
INV-7Policies scope cross-domain access
INV-10All federation events logged

12.9.2 Audit Requirements

EventRequired Context
Bundle exchangeSource domain, timestamp, keys
Cross-domain authSource SPIFFE ID, target, outcome
Policy evaluationClient identity, requested resource, decision
Federation removalRemoved domain, reason, operator

Document Navigation


End of Section 12