Decentraliseerde IAM en Multi-Cloud Security: Zero Trust Bouwen op Schaal

Het tijdperk van het traditionele beveiligingsmodel (castle-and-moat) is definitief voorbij. Wanneer je infrastructuur zich uitstrekt over AWS, GCP, Azure en on-premise omgevingen, bestaat er geen fysieke omtrek (perimeter) meer. In deze realiteit is Decentraliseerde IAM en Multi-Cloud Security niet zomaar een architectonisch patroon-het is de enige levensvatbare verdediging tegen laterale bewegingen (lateral movement) en geavanceerde supply chain-aanvallen. De identiteit van de aanvrager, of het nu een mens of een machine is, vormt de nieuwe grens.

De meeste organisaties falen hierin. Ze proberen verouderde, gecentraliseerde identity providers (IdPs) in dynamische, multi-cloud Kubernetes-clusters te proppen. Dit resulteert in kwetsbare integraties, overmatige machtigingen en single points of failure. In dit artikel ontleden we het probleem, stellen we een heldere architectuur voor en laten we precies zien hoe je dit implementeert zonder de ontwikkelsnelheid te schaden.

Het Probleem: De Valkuil van Gecentraliseerde Identiteit (Hub-and-Spoke)

Wanneer bedrijven voor het eerst een multi-cloudstrategie hanteren, routeren ze meestal alle authenticatie en autorisatie via één gecentraliseerde directory (bijv. Active Directory of een enkele Okta-instantie). Dit creëert de valkuil van gecentraliseerde identiteit (Hub-and-Spoke).

Elke service in AWS die toegang wil tot een database in GCP, moet zich authenticeren bij de centrale hub. Dit ontwerp introduceert drie kritieke nadelen:

1. Latentie: Een microservices-architectuur die honderden interne API-aanroepen per seconde doet, kan zich de latentie van een extra netwerk-hop naar een centrale IdP niet veroorloven.
2. Beschikbaarheid: Als de centrale IdP uitvalt, ligt de hele multi-cloudinfrastructuur direct plat.
3. Blast Radius: Een gecompromitteerde centrale directory geeft een aanvaller direct de sleutels tot het hele koninkrijk, verspreid over alle clouds.

Je hebt identiteiten nodig die lokaal worden geverifieerd, maar globaal worden beheerd.

Waarom Decentraliseerde IAM en Multi-Cloud Security Moeilijk is

Het decentraliseren van identiteit betekent het distribueren van vertrouwen, en het distribueren van vertrouwen vereist cryptografische bewijzen die continu worden gevalideerd. Wanneer een workload in AWS EKS een object in een Google Cloud Storage-bucket moet lezen, hoe weet GCP dan dat het de AWS-pod kan vertrouwen?

De naïeve aanpak is het gebruik van statische inloggegevens met een lange levensduur (bijv. AWS Access Keys of JSON-bestanden voor GCP Service Accounts) die zijn opgeslagen in Vault of Kubernetes Secrets. Dit is een enorme anti-pattern. Statische inloggegevens lekken, ze worden zelden geroteerd en ze schenden het kernprincipe van Zero Trust: kortstondige (ephemeral), nauwkeurig afgebakende toegang.

De uitdaging ligt in het opzetten van workload identity federation tussen verschillende vertrouwensdomeinen. Je moet een identiteit in Domein A (AWS OIDC provider) koppelen aan een rol in Domein B (GCP IAM) zonder statische geheimen uit te wisselen.

De Voorgestelde Architectuur: Workload Identity Federation

Wij pleiten voor een architectuur waarin elke omgeving fungeert als zijn eigen Identity Provider (IdP) voor de workloads die er draaien. Deze lokale IdP's federeren vervolgens het vertrouwen met andere cloudomgevingen met behulp van OpenID Connect (OIDC).

Onze referentie-architectuur maakt gebruik van:

• Kubernetes (EKS v1.30): Hosting van de workloads.
• AWS IAM OIDC Provider: De lokale IdP voor EKS.
• GCP Workload Identity Federation: Vertrouwt de AWS OIDC provider.
• SPIFFE/SPIRE (v1.8.0): Voor interne service-to-service mTLS en de uitgifte van identiteiten.

In plaats van geheimen door te geven, vraagt de workload een token met een korte levensduur aan bij de lokale omgeving. Dat token is cryptografisch ondertekend door de lokale IdP. De doelomgeving (GCP) controleert de handtekening, koppelt de OIDC-claim aan een lokale GCP IAM-rol en verleent tijdelijk toegang.

Implementatie: AWS EKS naar GCP BigQuery

Laten we kijken naar een concrete implementatie. We hebben een data-ingestionservice draaien in een AWS EKS-cluster die gegevens moet schrijven naar een GCP BigQuery-dataset.

1. Configureer de AWS EKS OIDC Provider

Zorg er eerst voor dat je EKS-cluster een bijbehorende IAM OIDC provider heeft. Hierdoor kunnen Kubernetes service accounts IAM-rollen aannemen, maar nog belangrijker: het geeft ons een issuer-URL die GCP kan vertrouwen.

# Terraform v1.8.0
# AWS Provider v5.40.0

data "tls_certificate" "eks" {
  url = aws_eks_cluster.main.identity[0].oidc[0].issuer
}

resource "aws_iam_openid_connect_provider" "eks" {
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = [data.tls_certificate.eks.certificates[0].sha1_fingerprint]
  url             = aws_eks_cluster.main.identity[0].oidc[0].issuer
}

2. Maak de GCP Workload Identity Pool aan

In GCP maken we een Workload Identity Pool en een Provider aan. De Provider verwijst naar de AWS EKS OIDC issuer-URL. We koppelen de sub-claim (die de Kubernetes-namespace en de naam van het service account bevat) aan een Google IAM-subject.

# GCP Provider v5.20.0

resource "google_iam_workload_identity_pool" "aws_pool" {
  workload_identity_pool_id = "aws-eks-pool"
  display_name              = "AWS EKS Trust Pool"
  description               = "Identity pool for EKS workloads"
}

resource "google_iam_workload_identity_pool_provider" "aws_provider" {
  workload_identity_pool_id          = google_iam_workload_identity_pool.aws_pool.workload_identity_pool_id
  workload_identity_pool_provider_id = "aws-eks-provider"
  display_name                       = "AWS EKS OIDC Provider"
  
  attribute_mapping = {
    "google.subject" = "assertion.sub"
    "attribute.namespace" = "assertion['kubernetes.io']['namespace']"
  }
  
  oidc {
    issuer_uri = aws_eks_cluster.main.identity[0].oidc[0].issuer
  }
}

3. Bind het GCP Service Account

Nu maken we een GCP Service Account aan dat schrijfrechten heeft voor BigQuery, en we staan toe dat het specifieke Kubernetes Service Account (via de Identity Pool) dit account impersoneert.

resource "google_service_account" "bq_writer" {
  account_id   = "bq-writer-sa"
  display_name = "BigQuery Writer Service Account"
}

resource "google_project_iam_member" "bq_data_editor" {
  project = var.project_id
  role    = "roles/bigquery.dataEditor"
  member  = "serviceAccount:${google_service_account.bq_writer.email}"
}

resource "google_service_account_iam_member" "workload_identity_user" {
  service_account_id = google_service_account.bq_writer.name
  role               = "roles/iam.workloadIdentityUser"
  
  # The member string matches the Google subject mapping from the provider
  # format: principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT
  member = "principal://iam.googleapis.com/${google_iam_workload_identity_pool.aws_pool.name}/subject/system:serviceaccount:data-ingest:bq-writer"
}

4. De Applicatiecode

De applicatie die in EKS draait, gebruikt de Google Cloud SDK. De SDK detecteert automatisch het geprojecteerde service account token dat door EKS is geleverd, gebruikt dit om te authenticeren bij de GCP Workload Identity Pool en haalt een access token met een korte levensduur op voor het bq-writer-sa account. Er zijn geen statische sleutels nodig.

# Kubernetes Service Account and Pod definition
apiVersion: v1
kind: ServiceAccount
metadata:
  name: bq-writer
  namespace: data-ingest
  annotations:
    # Optioneel: Als je ook AWS-machtigingen nodig hebt
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/bq-writer-role

---
apiVersion: v1
kind: Pod
metadata:
  name: bq-writer-app
  namespace: data-ingest
spec:
  serviceAccountName: bq-writer
  containers:
  - name: app
    image: my-registry/bq-writer:v1.2.0
    env:
    # Tell Google SDK where to find the credential configuration
    - name: GOOGLE_APPLICATION_CREDENTIALS
      value: /var/run/secrets/google/credentials.json
    volumeMounts:
    - name: google-cloud-key
      mountPath: /var/run/secrets/google
    - name: k8s-token
      mountPath: /var/run/secrets/tokens
  volumes:
  - name: google-cloud-key
    configMap:
      name: workload-identity-config
  - name: k8s-token
    projected:
      sources:
      - serviceAccountToken:
          path: oidc-token
          expirationSeconds: 3600
          audience: sts.amazonaws.com # Of je GCP audience

Valkuilen om te Vermijden

De implementatie van deze architectuur is niet zonder risico's. Hier zijn de meest voorkomende fouten die we zien optreden wanneer teams decentraliseerde IAM adopteren:

1. Te Brede Claim-mapping

Bij het configureren van de attribute mapping voor de Workload Identity Provider moet je geen te brede claims mappen. Als je "google.subject" = "assertion.aud" mapt, sta je toe dat elke workload in het EKS-cluster het GCP service account kan impersoneren. Map altijd specifiek naar de sub (subject), die de namespace en de naam van het service account bevat (system:serviceaccount:namespace:sa-name).

2. Token-verloop Negeren

Geprojecteerde service account tokens in Kubernetes verlopen. Je applicatie moet in staat zijn om inloggegevens dynamisch opnieuw te laden. De meeste moderne SDK's regelen dit automatisch, maar aangepaste authenticatielogica cacht tokens vaak voor onbepaalde tijd. Dit leidt tot moeilijk te debuggen fouten wanneer het token na een uur verloopt.

3. Audit Logs Verwaarlozen

Decentralisatie kan het zicht belemmeren. Je moet audit logs van AWS CloudTrail, GCP Cloud Logging en je Kubernetes API-server aggregeren in een centrale SIEM. Als een workload identity gecompromitteerd is, moet je in staat zijn om de acties over cloudgrenzen heen te traceren. Zorg ervoor dat je de sub-claim uit het OIDC-token kunt correleren met de resulterende API-aanroepen in de doelomgeving.

Het Resultaat: Beveiliging als Versneller

De overstap naar een gefedereerde, gedecentraliseerde IAM-architectuur verandert de beveiligingshouding van een engineeringorganisatie fundamenteel.

Door statische inloggegevens te elimineren, roei je de belangrijkste vector voor supply chain-aanvallen uit. Wanneer een ontwikkelaar een nieuwe service toegang wil verlenen tot een cloud-overschrijdende resource, hoeft hij geen sleutel aan te vragen bij het securityteam. Ze schrijven simpelweg een Terraform-module om de vertrouwensrelatie op te zetten en het beleid te definiëren.

Beveiliging wordt code. Vertrouwen wordt tijdelijk. De infrastructuur wordt veerkrachtig. Dit is het enige juiste pad voor professionele engineeringteams die op schaal opereren.