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.