Cloud & IT Cert Prep · leksjon

IAM-roller for tjenestekontoer (IRSA)

Knytt finkornede IAM-roller til Kubernetes-tjenestekontoer med IRSA, slik at pods kan få tilgang til AWS-tjenester uten tillatelser på nodenivå

Leksjon 4 av 413 trinn

IAM-roller for tjenestekontoer (IRSA) er en gratis leksjon i Cloud & IT Cert Prep på CoddyKit. Dette er leksjon 4 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Cloud & IT Cert Prep, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Cloud & IT Cert Prep inneholder totalt 4 leksjoner.

IAM-problemet med pod-er

Når en pod som kjører i EKS, må kalle et AWS API – for eksempel lese fra S3 eller skrive til DynamoDB – trenger den AWS-legitimasjon. Den naive tilnærmingen er å opprette en IAM-bruker og hardkode tilgangsnøklene som miljøvariabler. Dette er usikkert og bryter med prinsippet om minste privilegium, fordi alle pod-er på samme node deler legitimasjon. IAM Roles for Service Accounts (IRSA) løser dette ved å knytte finkornede IAM-roller direkte til Kubernetes-tjenestekontoer.

Slik fungerer IRSA: OIDC-federering

IRSA fungerer gjennom OpenID Connect (OIDC)-federering. EKS oppretter en OIDC-leverandør for klyngen. Når en pod refererer til en tjenestekonto som er annotert med en IAM-rolle-ARN, setter EKS inn et signert projisert tjenestekontotoken i pod-en. AWS SDK-et i pod-en utveksler dette tokenet mot midlertidig AWS-legitimasjon ved hjelp av AWS STS-API-et AssumeRoleWithWebIdentity – ingen langvarige nøkler kreves.

# View the OIDC issuer URL for your cluster
aws eks describe-cluster \
  --name my-cluster \
  --query 'cluster.identity.oidc.issuer' \
  --output text

# Example output:
# https://oidc.eks.us-east-1.amazonaws.com/id/EXAMPLEIDSTRING

Trinn 1: Knytt til OIDC-leverandøren

Før De bruker IRSA, må De knytte EKS OIDC-utstederen til AWS-kontoen som en klarert identitetsleverandør. Dette oppretter en IAM OIDC-leverandørressurs som AWS STS vil gjenkjenne. Kommandoen eksctl håndterer dette automatisk. Når leverandøren er opprettet, kan De bekrefte den i IAM-konsollen under identitetsleverandører.

# Associate the OIDC provider using eksctl (simplest method)
eksctl utils associate-iam-oidc-provider \
  --region us-east-1 \
  --cluster my-cluster \
  --approve

# Verify the provider was created
aws iam list-open-id-connect-providers \
  --query 'OpenIDConnectProviderList[].Arn'

Trinn 2: Opprett IAM-rollen

IAM-rollen for IRSA må ha en tillitspolicy som tillater OIDC-leverandøren å anta rollen, begrenset til et bestemt Kubernetes-navneområde og en bestemt tjenestekonto. Betingelsen bruker sub-påstanden i OIDC-tokenet, som er satt til system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME. Dette sikrer at bare pod-er som bruker den bestemte tjenestekontoen, kan anta rollen – ikke enhver pod i klyngen.

# Trust policy for the IRSA role (JSON)
# {
#   "Version": "2012-10-17",
#   "Statement": [{
#     "Effect": "Allow",
#     "Principal": {
#       "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLEID"
#     },
#     "Action": "sts:AssumeRoleWithWebIdentity",
#     "Condition": {
#       "StringEquals": {
#         "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLEID:sub":
#           "system:serviceaccount:production:s3-reader"
#       }
#     }
#   }]
# }

Trinn 3: Annoter tjenestekontoen

Opprett en Kubernetes-ServiceAccount i mål-navneområdet, og annoter den med IAM-rolle-ARN-en. Når en pod refererer til denne tjenestekontoen, setter EKS automatisk inn OIDC-tokenet og to miljøvariabler (AWS_WEB_IDENTITY_TOKEN_FILE og AWS_ROLE_ARN). AWS SDK-et oppdager disse automatisk og kaller STS for å hente midlertidig legitimasjon – programmet trenger ingen kodeendringer.

# Create and annotate the Kubernetes service account
kubectl create serviceaccount s3-reader -n production

kubectl annotate serviceaccount s3-reader \
  -n production \
  eks.amazonaws.com/role-arn=arn:aws:iam::111122223333:role/S3ReaderRole

# Verify the annotation
kubectl describe serviceaccount s3-reader -n production

Trinn 4: Referer til tjenestekontoen i pod-er

I spesifikasjonen for pod-en eller utrullingen setter De serviceAccountName til den annoterte tjenestekontoen. Når EKS planlegger pod-en, monterer den automatisk OIDC-tokenet på /var/run/secrets/eks.amazonaws.com/serviceaccount/token og setter de nødvendige miljøvariablene. Alle AWS SDK-kall inne i pod-en bruker sømløst legitimasjonen til den tilordnede IAM-rollen uten eksplisitt konfigurasjon av legitimasjon.

# Pod spec using IRSA service account
apiVersion: v1
kind: Pod
metadata:
  name: s3-app
  namespace: production
spec:
  serviceAccountName: s3-reader
  containers:
  - name: app
    image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/my-app:latest
    # AWS SDK auto-detects IRSA — no credential config needed
    # AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN are injected

IRSA kontra IAM-rolle for noder: Viktige forskjeller

Med en IAM-rolle for noder arver hver pod på en node de samme tillatelsene – en kompromittert pod kan få tilgang til alle AWS-tjenester som noden har tilgang til. Med IRSA antar hver pod, via tjenestekontoen sin, bare rollen den trenger. Dette følger prinsippet om minste privilegium på pod-nivå og begrenser skadeomfanget ved en sikkerhetshendelse. AWS anbefaler IRSA fremfor roller på node-nivå for alle nye EKS-utrullinger.

Opprette IRSA-roller med eksctl

eksctl kan opprette OIDC-tilknytningen, IAM-rollen, tillitspolicyen og annoteringen av Kubernetes-ServiceAccount med én enkelt kommando ved hjelp av create iamserviceaccount. Dette er den enkleste måten å konfigurere IRSA på uten å skrive JSON for tillitspolicyen manuelt. De angir navneområdet, navnet på tjenestekontoen og ARN-en til IAM-policyen som skal knyttes til, så håndterer eksctl resten.

# Create everything needed for IRSA in one command
eksctl create iamserviceaccount \
  --name s3-reader \
  --namespace production \
  --cluster my-cluster \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
  --approve \
  --override-existing-serviceaccounts

IRSA for AWS-tillegg

Mange EKS-tillegg og kontrollere krever IRSA for å fungere: Cluster Autoscaler trenger tillatelse til å kalle EC2 Auto Scaling API-et, AWS Load Balancer Controller trenger tillatelse til å opprette og administrere ELB-ressurser, external-dns trenger skrivetilgang til Route 53, og EBS CSI driver trenger tillatelse til å opprette og koble til EBS-volumer. Bruk alltid IRSA for disse systemkomponentene – gi aldri tillatelsene på IAM-rollenivå for noder.

# Create IRSA for the EBS CSI driver
eksctl create iamserviceaccount \
  --name ebs-csi-controller-sa \
  --namespace kube-system \
  --cluster my-cluster \
  --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
  --approve \
  --role-name AmazonEKS_EBS_CSI_DriverRole

Fornying av token og rotering av legitimasjon

IRSA-token har kort levetid og blir automatisk rotert av Kubernetes-kontrolleren for tokenprojisering før de utløper. Standardmålgruppen for tokenet er sts.amazonaws.com, og utløpstiden er 24 timer, men kontrolleren fornyer dem når 80 % av levetiden er gått. AWS STS-legitimasjon som hentes via IRSA, er også midlertidig og varer vanligvis i én time. Denne automatiske roteringen fjerner arbeidet med å rotere legitimasjon som følger med langvarige IAM-tilgangsnøkler.

# Inspect the projected service account token inside a pod
kubectl exec -n production s3-app -- \
  cat /var/run/secrets/eks.amazonaws.com/serviceaccount/token

# Decode the JWT header and payload to see expiry and audience
# jwt.io or: base64 -d <<< "PAYLOAD_SECTION"

Revisjon av IRSA-bruk med CloudTrail

Hver gang en pod antar en IAM-rolle via IRSA, registrerer AWS CloudTrail en AssumeRoleWithWebIdentity-hendelse. Hendelsen inneholder ARN-en til den antatte rollen, OIDC-tokenets subjekt (system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT) og kilde-IP-adressen. Dette gir et komplett revisjonsspor over hvilke pod-er som fikk tilgang til hvilke AWS-tjenester, og når – noe som er avgjørende for samsvarskrav og hendelsesundersøkelser i regulerte miljøer.

# Search CloudTrail for IRSA calls
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRoleWithWebIdentity \
  --start-time '2024-01-01T00:00:00Z' \
  --query 'Events[].{Time:EventTime,Role:CloudTrailEvent}' \
  --output table

Hurtigsjekk

Test forståelsen Deres av AWS Solutions Architect-konsepter (SAA-C03) fra denne leksjonen.

Besvar den i den interaktive leksjonen

Oppsummering av leksjonen

I denne leksjonen har De lært at IRSA bruker OIDC-federering til å utveksle Kubernetes-tjenestekontotoken mot midlertidig AWS-legitimasjon, at IAM-rollers tillitspolicyer begrenser tilgangen til et bestemt navneområde og en bestemt tjenestekonto, og at IRSA gir minste privilegium per pod, noe som er langt bedre enn IAM-roller på node-nivå. Deretter skal vi utforske CloudWatch Metrics, Namespaces og Dimensions for overvåking av AWS-ressursene Deres.

Gratis å komme i gang

Lær deg Cloud & IT Cert Prep med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs: 150
Leksjoner: 600

Start læringen gratis Se hele kurset

Ofte stilte spørsmål

Er leksjonen «IAM-roller for tjenestekontoer (IRSA)» gratis?

Ja – hele teksten i «IAM-roller for tjenestekontoer (IRSA)» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av Cloud & IT Cert Prep-kurset, kan du oppgradere til CoddyKit PRO. Kurset i Cloud & IT Cert Prep inneholder totalt 4 leksjoner.

Hva lærer jeg i «IAM-roller for tjenestekontoer (IRSA)»?

Knytt finkornede IAM-roller til Kubernetes-tjenestekontoer med IRSA, slik at pods kan få tilgang til AWS-tjenester uten tillatelser på nodenivå Du øver på Cloud & IT Cert Prep med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Cloud & IT Cert Prep?

Ingen tidligere erfaring er nødvendig. Cloud & IT Cert Prep på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 4 av 4.

Hvor lang tid tar leksjonen «IAM-roller for tjenestekontoer (IRSA)»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Cloud & IT Cert Prep-leksjonen?

Ja. Alle Cloud & IT Cert Prep-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

EKS-kontrollplan og arbeidsnoder
Fargate-profiler for serverløse pods
EKS-nettverk: VPC CNI og lastbalansering
IAM-roller for tjenestekontoer (IRSA)

← Tilbake til Cloud & IT Cert Prep