Panoramica tecnica - Amazon EKS

Panoramica tecnica

Nel 2014, AWS Identity and Access Management ha aggiunto il supporto per le identità federate mediante OpenID Connect (OIDC). Questa caratteristica consente di autenticare le chiamate API AWS con provider di identità supportati e ricevere un token Web JSON OIDC (JWT) valido. É possibile passare questo token all'operazione API AWS STS AssumeRoleWithWebIdentity e ricevere credenziali temporanee per il ruolo IAM. È possibile utilizzare queste credenziali per interagire con qualsiasi servizio AWS, ad esempio Amazon S3 e DynamoDB.

Kubernetes utilizza da tempo gli account di servizio come sistema di identità interno. I pod possono eseguire l'autenticazione con il server API Kubernetes utilizzando un token con montaggio automatico (che è un token JWT non OIDC) che solo il server API Kubernetes può convalidare. Questi token legacy dell'account di servizio non hanno scadenza e la rotazione della chiave di firma è un processo difficile. In Kubernetes versione 1.12, è stato aggiunto il supporto di una nuova funzionalità ProjectedServiceAccountToken, ovvero un token Web JSON OIDC che contiene anche l'identità dell'account di servizio e supporta un gruppo di destinatari configurabile.

Amazon EKS ora ospita un endpoint di rilevamento OIDC pubblico per cluster, contenente le chiavi di firma per i token Web JSON ProjectedServiceAccountToken, in modo che i sistemi esterni, ad esempio IAM, possano convalidare e accettare i token OIDC emessi da Kubernetes.

Configurazione del ruolo IAM

In IAM, è necessario creare un ruolo IAM con una relazione di trust valida per il provider OIDC del cluster, lo spazio dei nomi dell'account di servizio e (facoltativamente) il nome dell'account di servizio. Quindi allegare la policy IAM che si desidera associare all'account di servizio. È possibile aggiungere più voci nelle condizioni StringEquals e StringLike riportate di seguito per utilizzare più account di servizio o spazi dei nomi con il ruolo.

  • Per definire l'ambito di un ruolo per un account di servizio specifico:

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/OIDC_PROVIDER" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "OIDC_PROVIDER:sub": "system:serviceaccount:SERVICE_ACCOUNT_NAMESPACE:SERVICE_ACCOUNT_NAME" } } } ] }
  • Per definire l'ambito di un ruolo per un intero spazio dei nomi (per utilizzare lo spazio dei nomi come limite):

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/OIDC_PROVIDER" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringLike": { "OIDC_PROVIDER:sub": "system:serviceaccount:SERVICE_ACCOUNT_NAMESPACE:*" } } } ] }

Configurazione dell'account di servizio

In Kubernetes, è necessario definire il ruolo IAM da associare a un account di servizio nel cluster aggiungendo l'annotazione eks.amazonaws.com/role-arn all'account.

apiVersion: v1 kind: ServiceAccount metadata: annotations: eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT_ID:role/IAM_ROLE_NAME

Configurazione dei pod

Il webhook delle identità pod per Amazon EKS nel cluster monitora i pod associati agli account di servizio con l'annotazione specificata e applica a tali pod le seguenti variabili di ambiente.

AWS_ROLE_ARN=arn:aws:iam::ACCOUNT_ID:role/IAM_ROLE_NAME AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token
Nota

Il cluster non deve utilizzare il webhook di modifica per configurare le variabili di ambiente e i montaggi del file di token; è possibile scegliere di configurare i pod per aggiungere manualmente queste variabili di ambiente.

Le versioni supportate dell'SDK AWS cercano queste variabili di ambiente prima nel provider della catena di credenziali. Le credenziali del ruolo vengono utilizzate per i pod che soddisfano questi criteri.

Nota

Quando un pod utilizza le credenziali AWS da un ruolo IAM associato a un account di servizio, il AWS CLI o altri SDK nei container per tale pod utilizzano le credenziali fornite da tale ruolo in modo esclusivo. Allo stesso tempo, il pod ha ancora accesso alle credenziali fornite al Ruolo IAM del nodo Amazon EKS, a meno che non si limiti l'accesso a tali credenziali. Per ulteriori informazioni, consulta Limita l'accesso al profilo di istanza assegnato al nodo (worker).

Per impostazione predefinita, solo i container in esecuzione come root dispongono delle autorizzazioni adeguate del file system per leggere il file token di identità Web. È possibile fornire queste autorizzazioni facendo eseguire i container come root o fornendo il seguente contesto di sicurezza per i container nel manifesto. L'ID fsGroup è arbitrario ed è possibile scegliere qualsiasi ID gruppo valido. Per ulteriori informazioni sulle implicazioni dell'impostazione di un contesto di sicurezza per i pod, consultare la sezione Configurazione di un contesto di sicurezza per un pod o un container nella documentazione di Kubernetes.

Nota

Fornire questo contesto di protezione non è necessario per i cluster 1.19 o versioni successive.

apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: template: metadata: labels: app: my-app spec: serviceAccountName: my-app containers: - name: my-app image: my-app:latest securityContext: fsGroup: 1337 ...

La kubelet richiede e memorizza il token per conto del pod. Per impostazione predefinita, la kubelet aggiorna il token se è più vecchio dell'80% del suo TTL totale o se il token è più vecchio di 24 ore. È possibile modificare la durata di scadenza per qualsiasi account, ad eccezione dell'account di servizio predefinito, con le impostazioni nelle specifiche del pod. Per ulteriori informazioni, consultare Proiezione Volume Token Acount di Servizio nella documentazione di Kubernetes.

Autorizzazioni multi-account IAM

É possibile configurare le autorizzazioni multi-account IAM creando un provider di identità dal cluster di un altro account o utilizzando operazioni AssumeRole concatenate. Negli esempi seguenti, l'account A possiede un cluster Amazon EKS che supporta i ruoli IAM per gli account di servizio. I pod in esecuzione sul cluster devono assumere le autorizzazioni IAM dall'account B.

Esempio : creazione di un provider di identità dal cluster di un altro account

In questo esempio, l'account A fornisce all'account B l'URL dell'emittente OIDC dal relativo cluster. L'account B segue le istruzioni in Per creare un provider di identità IAM OIDC per il cluster e Creazione di un ruolo e una policy IAM per l'account di servizio utilizzando l'URL dell'emittente OIDC dal cluster dell'account A. Un amministratore del cluster annota quindi l'account di servizio nel cluster dell'account A per utilizzare il ruolo dall'account B.

apiVersion: v1 kind: ServiceAccount metadata: annotations: eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT_B_ID:role/IAM_ROLE_NAME

Esempio : utilizzo di operazioni AssumeRole concatenate

In questo esempio, l'account B crea una policy IAM con le autorizzazioni da assegnare ai pod nel cluster dell'account A. L'account B allega tale policy a un ruolo IAM con una relazione di trust che concede ad AssumeRole le autorizzazioni per l'account A (111111111111), come illustrato di seguito.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111111111111:root" }, "Action": "sts:AssumeRole", "Condition": {} } ] }

L'account A crea un ruolo con una policy di trust in grado di ottenere le credenziali dal provider di identità creato con l'URL dell'emittente OIDC del cluster, come illustrato di seguito.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111111111111:oidc-provider/oidc.eks.region-code.amazonaws.com/id/EXAMPLEC061A78C479E31025A21AC4CDE191335D05820BE5CE" }, "Action": "sts:AssumeRoleWithWebIdentity" } ] }

L'account A allega una policy a tale ruolo con le seguenti autorizzazioni per assumere il ruolo creato dall'account B.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::222222222222:role/account-b-role" } ] }

Il codice dell'applicazione per i pod che assumono il ruolo dell'account B utilizza due profili: account_b_role e account_a_role. Il profilo account_b_role utilizza il profilo account_a_role come origine. Per la AWS CLI, il file ~/.aws/config sarà simile all'esempio seguente.

[profile account_b_role] source_profile = account_a_role role_arn=arn:aws:iam::222222222222:role/account-b-role [profile account_a_role] web_identity_token_file = /var/run/secrets/eks.amazonaws.com/serviceaccount/token role_arn=arn:aws:iam::111111111111:role/account-a-role

Per specificare profili concatenati per altri SDK AWS, consultare la relativa documentazione.