Aiutaci a migliorare questa pagina
Vuoi contribuire a questa guida per l'utente? Scorri fino alla fine di questa pagina e seleziona Modifica questa pagina su GitHub. I tuoi contributi contribuiranno a rendere la nostra guida utente migliore per tutti.
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à.
Effettua l'autenticazione su un altro account con IRSA
Puoi configurare le IAM autorizzazioni per più account creando un provider di identità dal cluster di un altro account o utilizzando operazioni concatenate. AssumeRole
Negli esempi seguenti, l'Account A possiede un EKS cluster Amazon che supporta i IAM ruoli per gli account di servizio. Podsche sono in esecuzione su quel cluster devono assumere IAM le autorizzazioni dell'Account B.
Esempio Crea un provider di identità dal cluster di un altro account
In questo esempio, l'Account A fornisce all'Account B l'emittente OpenID Connect (OIDC) URL dal proprio cluster. L'account B segue le istruzioni Crea un IAM OIDC provider per il tuo cluster e Assegna IAM ruoli agli account di Kubernetes servizio utilizza l'OIDCemittente del cluster URL 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
Esempio Utilizzo di operazioni AssumeRole
concatenate
In questo esempio, l'Account B crea una IAM policy con le autorizzazioni da concedere a Pods nel cluster dell'Account A. Account B (444455556666
) attribuisce tale politica a un IAM ruolo con una relazione di fiducia che consente AssumeRole
le autorizzazioni all'Account A (111122223333
).
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::
111122223333
:root" }, "Action": "sts:AssumeRole", "Condition": {} } ] }
L'account A crea un ruolo con una politica di fiducia che ottiene le credenziali dal provider di identità creato con l'indirizzo dell'emittente del OIDC cluster.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::
111122223333
:oidc-provider/oidc.eks.region-code
.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE
" }, "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::
444455556666
:role/account-b-role
" } ] }
Il codice dell'applicazione per i Pods 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 il 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 profili AWS SDKs, consulta la documentazione relativa a SDK quello che stai utilizzando. Per ulteriori informazioni, consulta Strumenti su AWS cui costruire