Wechseln zu einer IAM-Rolle (AWS CLI)

Eine Rolle legt eine Gruppe von Berechtigungen fest, die Sie für den Zugriff auf AWS-Ressourcen, die Sie benötigen, verwenden können. In dieser Hinsicht ist sie mit einem IAM-BenutzerAWS Identity and Access Management vergleichbar. Wenn Sie sich als Benutzer anmelden, erhalten Sie einen bestimmten Satz von Berechtigungen. Sie melden sich jedoch nicht bei einer Rolle an. Wenn Sie sich aber als Benutzer angemeldet haben, können Sie zu einer Rolle wechseln. Dadurch werden Ihre ursprünglichen Benutzerberechtigungen vorübergehend zurückgestellt und Sie erhalten stattdessen die der Rolle zugewiesenen Berechtigungen. Die Rolle kann sich in Ihrem eigenen Konto oder jedem anderen AWS-Konto befinden. Weitere Informationen zu Rollen, ihren Vorteilen sowie zu ihrer Erstellung und Konfiguration finden Sie unter IAM-Rollenund Erstellen von IAM-Rollen. Weitere Informationen zu den unterschiedlichen Methoden, die Sie zum Übernehmen einer Rolle verwenden können, finden Sie unter Verwenden von IAM-Rollen.

Wichtig

Die Berechtigungen Ihres IAM-Benutzers und alle Rollen, die Sie annehmen, können nicht kumuliert werden. Es ist nur jeweils ein Satz von Berechtigungen aktiv. Wenn Sie eine Rolle annehmen, geben Sie Ihre vorherigen Benutzer- oder Rollenberechtigungen temporär auf und arbeiten mit den Berechtigungen, die der Rolle zugeordnet sind. Wenn Sie die Rolle verlassen, werden Ihre Benutzerberechtigungen automatisch wiederhergestellt.

Sie können eine Rolle verwenden, um einen AWS CLI-Befehl auszuführen, wenn Sie als IAM-Benutzer angemeldet sind. Sie können eine Rolle auch verwenden, um einen AWS CLI-Befehl auszuführen, wenn Sie als extern authentifizierter Benutzer (SAML oder OIDC) angemeldet sind, der bereits eine Rolle verwendet. Darüber hinaus können Sie eine Rolle für die Ausführung eines AWS CLI-Befehls aus einer Amazon EC2-Instance verwenden, die einer Rolle über ihr Instance-Profil zugeordnet ist. Sie können keine Rolle anwenden, wenn Sie sich als Root-Benutzer des AWS-Kontos anmelden.

Verketten von Rollen – Sie können auch das Verketten von Rollen verwenden, was bedeutet, Berechtigungen einer Rolle für den Zugriff auf eine zweite Rolle zu verwenden.

Standardmäßig ist Ihre Rollensitzung eine Stunde gültig. Wenn Sie diese Rolle mithilfe der assume-role*-CLI-Operationen annehmen, können Sie einen Wert für den duration-seconds-Parameter angeben. Dieser Wert kann zwischen 900 Sekunden (15 Minuten) und der maximalen Sitzungsdauer für die Rolle liegen. Wenn Sie in der Konsole die Rollen wechseln, ist Ihre Sitzungsdauer auf maximal eine Stunde begrenzt. Weitere Informationen dazu, wie Sie den maximalen Wert für Ihre Rolle anzeigen, finden Sie unter Anzeigen der maximalen Sitzungsdauer für eine Rolle.

Wenn Sie die Verkettung von Rollen verwenden, ist Ihre Sitzungsdauer auf die maximale Dauer von einer Stunde begrenzt. Wenn Sie den duration-seconds-Parameter verwenden, um einen Wert größer als eine Stunde anzugeben, schlägt die Operation fehl.

Beispielszenario: Wechseln zu einer Produktionsrolle

Stellen Sie sich vor, Sie sind ein IAM-Benutzer und arbeiten in der der Entwicklungsumgebung. In diesem Szenario müssen Sie gelegentlich mit der Produktionsumgebung an der Befehlszeile mit der AWS CLI arbeiten. Sie haben bereits einen Zugriffsschlüsselsatz, die Ihnen zur Verfügung steht. Dies kann das Zugriffsschlüsselpaar sein, das dem IAM-Standardbenutzer zugewiesen ist. Wenn Sie dagegen als Verbundbenutzer angemeldet sind, kann es sich um das Zugriffsschlüsselpaar für die Rolle handeln, die Ihnen ursprünglich zugewiesen wurde. Wenn Sie durch die aktuellen Berechtigungen die Möglichkeit haben, eine bestimmte IAM-Rolle anzunehmen, können Sie diese Rolle in einem "Profil" in den AWS CLI-Konfigurationsdateien identifizieren. Dieser Befehl wird dann mit den Berechtigungen der angegebenen IAM-Rolle, nicht mit der ursprünglichen Identität ausgeführt. Beachten Sie, dass Sie die neue Rolle verwenden, wenn Sie jenes Profil in einem AWS CLI-Befehl angeben. In dieser Situation können Sie nicht gleichzeitig die ursprünglichen Berechtigungen im Entwicklungskonto nutzen. Der Grund besteht darin, dass zu einem bestimmten Zeitpunkt nur jeweils ein Satz Berechtigungen wirksam sein kann.

Anmerkung

Aus Sicherheitsgründen können Administratoren AWS CloudTrail-Protokolle überprüfen, um festzustellen, wer eine Aktion in AWS ausgeführt hat. Ihr Administrator erfordert möglicherweise, dass Sie einen bestimmten Wert für den Sitzungsnamen angeben, wenn Sie die Rolle übernehmen. Weitere Informationen finden Sie unter sts:SourceIdentity und sts:RoleSessionName.

So wechseln Sie zu einer Produktionsrolle (AWS CLI)

1. Wenn Sie die AWS CLI noch nie verwendet haben, müssen Sie zunächst Ihr Standard-CLI-Profil konfigurieren. Öffnen Sie eine Eingabeaufforderung und richten Sie Ihre AWS CLI-Installation ein, um den Zugriffsschlüssel von Ihrem IAM-Benutzer oder von Ihrer verbundenen Rolle zu nutzen. Weitere Informationen finden Sie unter Konfigurieren der AWS Command Line Interface im AWS Command Line Interface-Leitfaden.

   Konfigurieren Sie die mit dem Befehl wie folgt:

   aws configure

   Wenn Sie dazu aufgefordert werden, geben Sie die folgenden Informationen an:

   AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
   AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
   Default region name [None]: us-east-2
   Default output format [None]: json

2. Erstellen Sie ein neues Profil für die Rolle in der Datei .aws/config in Unix oder Linux oder in der Datei C:\Users\USERNAME\.aws\config in Windows. Im folgenden Beispiel wird ein Profil mit dem Namen prodaccess erstellt, das zur Rolle ProductionAccessRole im 123456789012-Konto wechselt. Der ARN der Rolle wird Ihnen vom Kontoadministrator, der die Rolle erstellt hat, mitgeteilt. Wenn dieses Profil aufgerufen wird, verwendet die AWS CLI die Anmeldeinformationen von source_profile zum Anfordern der Anmeldeinformationen für die Rolle. Daher muss die Identität, die als source_profile referenziert ist, über sts:AssumeRole-Berechtigungen für die Rolle verfügen, die in role_arn angegeben ist.

   [profile prodaccess]
       role_arn = arn:aws:iam::123456789012:role/ProductionAccessRole
       source_profile = default

3. Nach dem Erstellen des neuen Profils wird jeder AWS CLI-Befehl, der den Parameter --profile prodaccess angibt, unter den Berechtigungen ausgeführt, die der IAM-Rolle ProductionAccessRole und nicht dem Standardbenutzer angefügt sind.

   aws iam list-users --profile prodaccess

   Dieser Befehl funktioniert, wenn die Berechtigungen, die ProductionAccessRole zugeordnet sind, das Auflisten der Benutzer im aktuellen AWS-Konto ermöglichen.

4. Um zu den Berechtigungen zurückzukehren, die von Ihren ursprünglichen Anmeldeinformationen erteilt wurden, führen Sie Befehle ohne den --profile-Parameter. Die AWS CLI wird auf die Verwendung der Anmeldeinformationen Ihrem Standardprofil zurückgesetzt, die Sie in Schritt 1 konfiguriert haben.

Weitere Informationen hierzu finden Sie unter Assuming a Role im AWS Command Line InterfaceLeitfaden.

Beispielszenario: Einer Instance-Profilrolle erlauben, zu einer Rolle in einem anderen Konto zu wechseln

Angenommen, Sie verwenden zwei AWS-Konten und möchten einer Anwendung, die auf einer Amazon-EC2-Instance läuft, erlauben, AWS CLI-Befehle in beiden Konten auszuführen. Gehen Sie davon aus, dass die EC2-Instance im Konto 111111111111 vorhanden ist. Diese Instance enthält die abcd-Instance-Profilrolle, die der Anwendung erlaubt, schreibgeschützte Amazon S3-Aufgaben für den my-bucket-1-Bucket innerhalb desselben 111111111111 Kontos auszuführen. Die Anwendung muss aber auch berechtigt sein, die kontoübergreifende efgh-Rolle zu übernehmen, um Aufgaben im Konto 222222222222 auszuführen. Dazu muss der EC2-Instance-Profilrolle abcd die folgende Berechtigungsrichtlinie zugeordnet sein.

Konto 111111111111 abcd Rollen-Berechtigungsrichtlinie

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAccountLevelS3Actions",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowListAndReadS3ActionOnMyBucket",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": [
                "arn:aws:s3:::my-bucket-1/*",
                "arn:aws:s3:::my-bucket-1"
            ]
        },
        {
            "Sid": "AllowIPToAssumeCrossAccountRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::222222222222:role/efgh"
        }
    ]
}

Gehen Sie davon aus, dass die kontoübergreifende efgh-Rolle die Ausführung schreibgeschützter Amazon S3-Aufgaben für den my-bucket-2-Bucket im selben 222222222222-Konto zulässt. Dazu muss der kontoübergreifenden efgh-Rolle die folgende Berechtigungsrichtlinie zugeordnet sein:

Konto 222222222222 efgh Rollen-Berechtigungsrichtlinie

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAccountLevelS3Actions",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowListAndReadS3ActionOnMyBucket",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": [
                "arn:aws:s3:::my-bucket-2/*",
                "arn:aws:s3:::my-bucket-2"
            ]
        }
    ]
}

Die efgh-Rolle muss der abcd-Instance-Profilrolle die Übernahme erlauben. Dazu benötigt die efgh-Rolle die folgende Vertrauensrichtlinie:

Konto 222222222222 efgh Rollen-Berechtigungsrichtlinie

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "efghTrustPolicy",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {"AWS": "arn:aws:iam::111111111111:role/abcd"}
        }
    ]
}

Damit Sie dann AWS CLI-Befehle im Konto 222222222222 ausführen können, müssen Sie die CLI-Konfigurationsdatei aktualisieren. Identifizieren Sie die efgh-Rolle als "Profil" und die abcd-EC2-Instance-Profilrolle als "Quelle der Anmeldeinformationen“ in der AWS CLI-Konfigurationsdatei. Dann werden Ihre CLI-Befehle mit den Berechtigungen der efgh-Rolle und nicht mit denen der ursprünglichen abcd-Rolle ausgeführt.

Anmerkung

Sie können AWS CloudTrail zu Zwecken der Sicherheit nutzen, um die Verwendung von Rollen im Konto zu prüfen. Um zwischen Rollensitzungen zu unterscheiden, wenn eine Rolle von verschiedenen Auftraggebers in CloudTrail-Protokollen verwendet wird, können Sie den Rollensitzungsnamen verwenden. Wenn die AWS CLI eine Rolle im Namen eines Benutzers annimmt, wie in diesem Thema beschrieben, wird ein Rollensitzungsname automatisch als AWS-CLI-session-nnnnnnnn erstellt. Hier ist nnnnnnnn eine Ganzzahl, die die Zeit in Unix-Epoche (die Anzahl der Sekunden seit Mitternacht UTC am 1. Januar 1970) angibt. Weitere Informationen finden Sie in der CloudTrail Event Reference im Leitfaden AWS CloudTrailLeitfaden.

So lassen Sie zu, dass eine EC2-Instance-Profilrolle zu einer kontoübergreifenden Rolle wechselt (AWS CLI)

1. Sie müssen kein Standard-CLI-Profil konfigurieren. Stattdessen können Sie Anmeldeinformationen aus den Metadaten des EC2-Instance-Profils laden. Erstellen Sie ein neues Profil für die Rolle in der .aws/config-Datei. Das folgende Beispiel erstellt ein instancecrossaccount-Profil, das zur efgh-Rolle im 222222222222-Konto wechselt. Wenn dieses Profil aufgerufen wird, verwendet die AWS CLI die Anmeldeinformationen aus den Metadaten des EC2-Instance-Profils, um Anmeldeinformationen für die Rolle anzufordern. Deshalb muss das EC2-Instance-Profil über die sts:AssumeRole-Berechtigungen für die Rolle verfügen, die in role_arn angegeben ist.

   [profile instancecrossaccount]
   role_arn = arn:aws:iam::222222222222:role/efgh
   credential_source = Ec2InstanceMetadata

2. Nach dem Erstellen des neuen Profils wird jeder AWS CLI-Befehl, der den Parameter --profile instancecrossaccount angibt, unter den Berechtigungen ausgeführt, die zur efgh-Rolle im 222222222222-Konto zugewiesen sind.

   aws s3 ls my-bucket-2 --profile instancecrossaccount

   Dieser Befehl funktioniert, wenn die Berechtigungen, die zur efgh-Rolle zugewiesen sind, die Auflistung der Benutzer im aktuellen AWS-Konto zulässt.

3. Zum Zurückkehren zu den ursprünglichen EC2-Instance-Profilberechtigungen im Konto 111111111111 führen Sie die CLI-Befehle ohne den Parameter --profile.

Weitere Informationen hierzu finden Sie unter Assuming a Role im AWS Command Line InterfaceLeitfaden.