Contribuisci a migliorare questa pagina
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Per contribuire a questa guida per l'utente, scegli il GitHub link Modifica questa pagina nel riquadro destro di ogni pagina.
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Eseguire l’autenticazione a un altro account con IRSA
Ѐ possibile configurare le autorizzazioni IAM multi-account creando un gestore 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.
-
L'opzione 1 è più semplice ma richiede l'Account B per creare e gestire un provider di identità OIDC per il cluster dell'Account A.
-
L'opzione 2 mantiene la gestione OIDC nell'Account A ma richiede il concatenamento dei ruoli tramite due chiamate.
AssumeRole
Opzione 1: creare un provider di identità dal cluster di un altro account
In questo esempio, l'account A fornisce all'account B l'URL dell'emittente OpenID Connect (OIDC) dal relativo cluster. L’account B segue le istruzioni indicate alle pagine Create an IAM OIDC provider for your cluster e Assegnare ruoli IAM agli account di servizio Kubernetes utilizzando l’URL dell’emittente OIDC dal cluster dell’account A. Quindi, un amministratore del cluster annota l'account di servizio nel cluster dell'Account A per utilizzare il ruolo dell'Account B (444455556666).
apiVersion: v1 kind: ServiceAccount metadata: annotations: eks.amazonaws.com/role-arn: arn:aws: iam::444455556666:role/account-b-role
Opzione 2: utilizzare operazioni AssumeRole concatenate
In questo approccio, ogni account crea un ruolo IAM. Il ruolo dell'Account B si affida all'Account A e il ruolo dell'Account A utilizza la federazione OIDC per ottenere le credenziali dal cluster. Il Pod concatena quindi i due ruoli utilizzando i AWS profili CLI.
Fase 1: Creare il ruolo di destinazione nell'Account B
L'account B (444455556666) crea un ruolo IAM con le autorizzazioni necessarie ai pod del cluster dell'account A. L'account B associa la politica di autorizzazione desiderata a questo ruolo, quindi aggiunge la seguente politica di fiducia.
Politica di fiducia per il ruolo dell'Account B: questa politica consente al ruolo IRSA specifico dell'Account A di assumere questo ruolo.
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": "sts:AssumeRole", "Condition": {} } ] }
Importante
Per ottenere il minimo privilegio, sostituisci l'PrincipalARN con il ruolo specifico ARN dell'account A invece di usare l'account root (). arn:aws:iam::111122223333:root L'utilizzo dell'account root consente a qualsiasi principale IAM dell'account A di assumere questo ruolo.
Fase 2: Creare il ruolo IRSA nell'Account A
L'account A (111122223333) crea un ruolo con una politica di fiducia che ottiene le credenziali dal provider di identità creato con l'indirizzo dell'emittente OIDC del cluster.
Politica di fiducia per il ruolo dell'Account A (federazione OIDC): questa politica consente al provider OIDC del cluster EKS di emettere credenziali per questo ruolo.
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com" } } } ] }
Importante
Per ottenere il privilegio minimo, aggiungi una StringEquals condizione per la sub dichiarazione di limitare questo ruolo a uno specifico account di servizio Kubernetes. Senza una sub condizione, qualsiasi account di servizio nel cluster può assumere questo ruolo. Il sub valore utilizza il formatosystem:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME
. Ad esempio, per limitarsi a un account di servizio denominato my-service-account nel default namespace:
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account"
Passaggio 3: allegare l' AssumeRole autorizzazione al ruolo dell'Account A
L'Account A allega una politica di autorizzazione al ruolo creato nella Fase 2. Questa politica consente al ruolo di assumere il ruolo dell'Account B.
Politica di autorizzazione per il ruolo dell'Account A: questa politica concede sts:AssumeRole all'Account B il ruolo obiettivo.
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::444455556666:role/account-b-role" } ] }
Passaggio 4: configura il Pod per concatenare i ruoli
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 ~/.aws/config file è simile al seguente.
[profile account_b_role] source_profile = account_a_role role_arn=arn:aws: iam::444455556666: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::111122223333:role/account-a-role
Per specificare profili concatenati per altri AWS SDKs, consulta la documentazione dell'SDK che stai utilizzando. Per ulteriori informazioni, consulta Strumenti su cui costruire
