IAM-rollen voor serviceaccounts (IRSA)

Wanneer een pod die in EKS draait een AWS API moet aanroepen — bijvoorbeeld om uit S3 te lezen of naar DynamoDB te schrijven — heeft de pod AWS-inloggegevens nodig. De voor de hand liggende aanpak is om een IAM-gebruiker te maken en de toegangssleutels daarvan als omgevingsvariabelen vast in de code op te nemen. Dit is onveilig en in strijd met het principe van minimale rechten, omdat alle pods op dezelfde node dezelfde inloggegevens delen. IAM Roles for Service Accounts (IRSA) lost dit op door fijnmazige IAM-rollen rechtstreeks aan Kubernetes-serviceaccounts te koppelen.

IRSA werkt via OpenID Connect (OIDC)-federatie. EKS maakt een OIDC-provider voor uw cluster. Wanneer een pod verwijst naar een serviceaccount waaraan een IAM-rol-ARN is toegevoegd, injecteert EKS een ondertekend geprojecteerd serviceaccounttoken in de pod. De AWS SDK in de pod wisselt dit token om voor tijdelijke AWS-inloggegevens met behulp van de AssumeRoleWithWebIdentity-API van AWS STS — langlopende sleutels zijn niet nodig.

Voordat u IRSA gebruikt, moet u de OIDC-uitgever van EKS als vertrouwde identiteitsprovider koppelen in uw AWS-account. Hierdoor wordt een IAM OIDC-providerresource gemaakt die door AWS STS wordt herkend. De opdracht eksctl regelt dit automatisch. Nadat de provider is gemaakt, kunt u deze in de IAM-console verifiëren onder Identity Providers.

De IAM-rol voor IRSA moet een vertrouwensbeleid hebben waarmee de OIDC-provider de rol mag aannemen, beperkt tot een specifieke Kubernetes-namespace en een specifiek serviceaccount. De voorwaarde gebruikt de claim sub in het OIDC-token, die is ingesteld op system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME. Hierdoor kunnen alleen pods die dat specifieke serviceaccount gebruiken de rol aannemen — niet elke pod in het cluster.

Maak een Kubernetes-ServiceAccount in de doelnamespace en voeg de IAM-rol-ARN als annotatie toe. Wanneer een pod naar dit serviceaccount verwijst, injecteert EKS automatisch het OIDC-token en twee omgevingsvariabelen (AWS_WEB_IDENTITY_TOKEN_FILE en AWS_ROLE_ARN). De AWS SDK detecteert deze automatisch en roept STS aan om tijdelijke inloggegevens te verkrijgen — u hoeft geen code in uw toepassing te wijzigen.

Stel in de specificatie van uw pod of implementatie serviceAccountName in op het geannoteerde serviceaccount. Wanneer EKS de pod plant, koppelt EKS het OIDC-token automatisch aan op /var/run/secrets/eks.amazonaws.com/serviceaccount/token en stelt het de vereiste omgevingsvariabelen in. Elke AWS SDK-aanroep in de pod gebruikt transparant de inloggegevens van de gekoppelde IAM-rol, zonder expliciete configuratie van inloggegevens.

Met een IAM-rol van een node erft elke pod op een node dezelfde machtigingen — een gecompromitteerde pod kan toegang krijgen tot alle AWS-services waartoe de node toegang heeft. Met IRSA neemt elke pod via zijn serviceaccount alleen de rol aan die nodig is. Dit volgt het principe van minimale rechten op podniveau en beperkt de impact van een beveiligingsincident. AWS raadt IRSA aan boven rollen op node-niveau voor alle nieuwe EKS-implementaties.

Met eksctl kunt u de OIDC-koppeling, IAM-rol, het vertrouwensbeleid en de annotatie van het Kubernetes-ServiceAccount met één opdracht maken via create iamserviceaccount. Dit is de eenvoudigste manier om IRSA in te stellen zonder handmatig JSON voor het vertrouwensbeleid te schrijven. U geeft de namespace, de naam van het serviceaccount en de ARN van het toe te voegen IAM-beleid op; eksctl regelt de rest.

Veel EKS-add-ons en controllers hebben IRSA nodig om te functioneren: Cluster Autoscaler heeft toestemming nodig om de EC2 Auto Scaling API aan te roepen, de AWS Load Balancer Controller heeft toestemming nodig om ELB-resources te maken en te beheren, external-dns heeft schrijftoegang tot Route 53 nodig en het EBS CSI-stuurprogramma heeft toestemming nodig om EBS-volumes te maken en te koppelen. Gebruik altijd IRSA voor deze systeemcomponenten — verleen deze machtigingen nooit op het niveau van de IAM-rol van de node.

IRSA-tokens hebben een korte levensduur en worden automatisch geroteerd door de Kubernetes-controller voor tokenprojectie voordat ze verlopen. De standaarddoelgroep van het token is sts.amazonaws.com en de vervaltijd is 24 uur, maar de controller vernieuwt de tokens wanneer 80% van hun levensduur is verstreken. AWS STS-inloggegevens die via IRSA zijn verkregen, zijn ook tijdelijk (meestal 1 uur). Deze automatische rotatie neemt de last weg van het roteren van inloggegevens die hoort bij langlopende IAM-toegangssleutels.

Elke keer dat een pod via IRSA een IAM-rol aanneemt, registreert AWS CloudTrail een gebeurtenis van het type AssumeRoleWithWebIdentity. De gebeurtenis bevat de ARN van de aangenomen rol, het onderwerp van het OIDC-token (system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT) en het bron-IP-adres. Hierdoor ontstaat een volledige audittrail van welke pods welke AWS-services hebben gebruikt en wanneer — cruciaal voor naleving en onderzoek van incidenten in gereguleerde omgevingen.

In deze les hebt u geleerd dat IRSA OIDC-federatie gebruikt om Kubernetes-serviceaccounttokens om te wisselen voor tijdelijke AWS-inloggegevens, dat vertrouwensbeleidsregels voor IAM-rollen de toegang beperken tot een specifieke namespace en een specifiek serviceaccount, en dat IRSA minimale rechten per pod biedt, wat veel beter is dan IAM-rollen op node-niveau. Hierna bekijken we CloudWatch-statistieken, namespaces en dimensies voor het observeren van uw AWS-resources.