Wie man eine ECS-Aufgabenrolle in AWS übernimmt - der offizielle und der falsche Weg

Wenn Sie mit AWS ECS arbeiten und das Prinzip der geringsten Privilegien anwenden, erstellen Sie für jede Aufgabe eine IAM-Rolle. Während Sie die Software entwickeln, möchten Sie vielleicht auch die Rolle testen. Das ist jedoch nicht so einfach möglich. In diesem Blog zeigen wir Ihnen, wie dies auf offiziellem Weg und auf einem etwas alternativeren Weg mit dem Dienstprogramm iam-sudo für Entwicklungszwecke geschehen kann. In unseren Cloud-Native-Einrichtungsprinzipien erlauben wir niemandem, manuelle Änderungen an der AWS-Umgebung vorzunehmen. Dies
bedeutet, dass die Entwickler selbst auf die Entwicklungsumgebung nur Zugriffsrechte haben. Alle Änderungen müssen
über AWS CloudFormation vorgenommen werden.Manchmal ist es notwendig, dass ein Entwickler seine Software von seinem lokalen Laptop aus debuggen kann, während er
mit der Entwicklungsumgebung spricht. Dazu müssen sie in der Lage sein, die Rolle der ECS-Aufgabe zu übernehmen.

Was ist das Problem?

Wenn Sie eine AWS ECS-Task-Rolle erstellen, erteilen Sie dem ecs-tasks-Service normalerweise die Berechtigung, die Rolle
zu übernehmen. Das bedeutet, dass nur AWS ECS die Rolle übernehmen kann und niemand sonst. Lassen Sie mich dies
anhand der folgenden Schritte veranschaulichen: * Erstellen der Rolle * Hinzufügen einer Richtlinie * Übernehmen der Rolle

die Rolle erstellen

Um eine Rolle für eine AWS ECS-Aufgabe zu erstellen, erteilen Sie dem Service ecs-tasks.amazonaws.com
die Berechtigung dazu wie folgt:

aws iam create-role  
  --role-name iam-sudo-demo-my-task 
  --assume-role-policy-document '{
        "Statement":  {
            "Effect": "Allow",
            "Principal": { "Service": [ "ecs-tasks.amazonaws.com" ] },
            "Action": [ "sts:AssumeRole" ]
         }]}'

eine Police hinzufügen

Als nächstes können Sie der Rolle eine Inline-Richtlinie hinzufügen, zum Beispiel:

aws iam put-role-policy 
  --role-name iam-sudo-demo-my-task 
  --policy-name 'describe-parameters' 
  --policy-document '{
            "Statement": [{
                "Effect": "Allow",
                "Action": [ "ssm:DescribeParameters" ],
                "Resource": "*"
            }]}'

die Rolle übernehmen

Um die Berechtigungsnachweise für diese Rolle zu erhalten, geben Sie ein:

ROLE_ARN=$(aws iam get-role 
  --role-name iam-sudo-demo-my-task 
  --query Role.Arn 
  --output text)

aws sts assume-role 
  --role-arn $ROLE_ARN 
  --role-session-name no-can-do

Leider schlägt dies mit der folgenden Fehlermeldung fehl:

An error occurred (AccessDenied) when calling the AssumeRole operation:
  User: arn:aws:iam::**********15:user/mvanholsteijn is not authorized
  to perform: sts:AssumeRole on resource: arn:aws:iam::**********15:role/iam-sudo-demo-my-task

Wie kommt das? Ich bin root-Benutzer des AWS-Kontos! Die Ursache dafür ist das Fehlen von
und der Berechtigung sts:AssumeRole für das AWS-Konto selbst.

Mögliche Lösungen

Es gibt mindestens zwei mögliche Lösungen für dieses Problem:

1. erweitern Sie das Dokument assume role um das AWS-Konto
2. die Rolle mithilfe von Sitzungsrichtlinien fälschen

Erweiterung der Rolle übernehmen auf das Konto

Eine mögliche Lösung besteht darin, dem AWS-Konto die Berechtigung zu erteilen, auch die Rolle
zu übernehmen, und zwar wie folgt:

ACCOUNT_ID=$(aws sts get-caller-identity 
   --query Account --output text)

aws iam create-role  
  --role-name iam-sudo-demo-my-task-allow-root-assume-role 
  --assume-role-policy-document "$(
     jq -n . --arg account_id $ACCOUNT_ID '{
        "Statement": [{
            "Effect": "Allow",
            "Principal": { "Service": [ "ecs-tasks.amazonaws.com" ] },
            "Action": [ "sts:AssumeRole" ]
          },{
            "Effect": "Allow",
            "Principal": { "AWS": [ $account_id ] },
            "Action": [ "sts:AssumeRole" ]
          }]}'
     )"

Die Rolle "Übernehmen" wird nun funktionieren. Es ist jedoch erforderlich, dass die Entwickler die Berechtigung
erhalten, diese Rolle ebenfalls zu übernehmen. Da wir viele ECS-Aufgabenrollen mit CloudFormation
haben, die in separaten CloudFormation-Vorlagen generiert wurden, ist dies ziemlich schwierig. Der einfachste Weg, dies zu tun,
ist, die Rollen wie folgt zu markieren:

aws iam create-role --tags Key=env,Value=dev ...

Und gewähren Sie den Entwicklern eine bedingte Rollenübernahmeberechtigung für diese Rollen:

    "Statement": [{
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "*",
        "Condition": {"StringLike": {"iam:ResourceTag/env": "dev"}}
    }]

Dies ist eine Lösung, die vollständig mit dem IAM-Lösungsraum funktioniert. Das einzige, was
dagegen spricht, ist die Tatsache, dass es sich um eine ziemlich invasive Änderung handelt, die nur
in der Entwicklungsumgebung benötigt wird.

die Rolle mithilfe von Sitzungsrichtlinien fälschen

Die vorherige Lösung ist die offizielle Lösung. Aber sie fügt
Komplexität hinzu, die in unserem Fall und nur in der Entwicklungsumgebung erforderlich ist.Wenn Sie sich den Aufruf der assume-role api
ansehen, werden Sie sehen, dass Sie bei der Übernahme einer Rolle Folgendes angeben können:* die zu übernehmende Rolle* eine anzuwendende Inline-Sitzungsrichtlinie* eine oder mehrere anzuwendende verwaltete RichtlinienDas bedeutet, dass Sie beim Lesen einer IAM-Rolle die Inline-Rollenrichtlinien und
die angehängten verwalteten Richtlinien anwenden und auf eine Rolle anwenden können, die Sie
übernehmen dürfen.Lassen Sie mich Ihnen zeigen, wie das funktioniert. Erstellen Sie zunächst eine Rolle
, die über ausreichende Berechtigungen verfügt, um eine wirksame Richtlinie zu haben:

aws iam create-role  
  --role-name iam-sudo-demo-power-user 
  --assume-role-policy-document "$(
     jq -n 
       --arg account_id $ACCOUNT_ID 
       '{
        "Statement": [{
            "Effect": "Allow",
            "Principal": { "AWS": [ $account_id ] },
            "Action": [ "sts:AssumeRole" ]
          }]}' 
     )"

aws iam attach-role-policy 
  --role-name iam-sudo-demo-power-user
  --policy-arn arn:aws:iam::aws:policy/PowerUserAccess

Als nächstes müssen wir alle Inline-Sitzungsrichtlinien der Rolle abrufen:

for NAME in $(aws iam list-role-policies 
  --role-name iam-sudo-demo-my-task 
  --query PolicyNames --output text) ; 
do
   aws iam get-role-policy 
      --role-name iam-sudo-demo-my-task 
      --policy-name $NAME
done | 
  jq  '.PolicyDocument.Statement' | 
  jq -s add > inline-policies.json

Um alle verwalteten Richtlinien abzurufen, die der Rolle zugeordnet sind, geben Sie ein:

 aws iam list-attached-role-policies 
   --role-name iam-sudo-demo-my-task 
   --query 'join(,, AttachedPolicies[*].join(=, [arn, PolicyArn]))' 
   --output text 
   | sed -e 's/^./--policy-arns &/' 
     > attached-policies.txt

Schließlich können wir die Rolle simulieren:

aws sts assume-role 
  --role-arn arn:aws:iam::${ACCOUNT_ID}:role/iam-sudo-demo-power-user 
  --role-session-name simulate-iam-sudo-demo-my-task 
  --policy "$(<inline-policies.json)" 
  $(<attached-policies.txt)

Das sieht immer noch recht aufwendig aus. Deshalb haben wir dies in das Dienstprogramm iam-sudo integriert.

mit dem IAM-Dienstprogramm sudo

Das IAM sudo-Dienstprogramm vereinfacht die Arbeit von
, indem es eine Rolle simuliert. Um das zu tun, was oben gezeigt wird, geben Sie einfach ein:

pip3 install iam-sudo

iam-sudo simulate --local 
    --role-name iam-sudo-demo-my-task 
    --base-role iam-sudo-demo-power-user 
    --profile iam-sudo-demo-my-task 
    aws sts get-caller-identity

INFO: credentials saved under AWS profile iam-sudo-demo-my-task.
{
    "UserId": "AROAWOZQJPZZRMGYEX3NX:iam-sudo-iam-sudo-demo-my-task",
    "Account": "**********15",
    "Arn": "arn:aws:sts::***********15:assumed-role/iam-sudo-demo-power-user/iam-sudo-iam-sudo-demo-my-task"
}

Es speichert die Anmeldeinformationen unter dem angegebenen Profilnamen und führt den Befehl mit ihnen aus.

Privilegienerhöhung mit AWS Lambda

Auch wenn die Simulation von Rollenrichtlinien schön ist, müssen wir dennoch eine Rolle annehmen, die mächtig genug
ist, um eine effektive Sitzungsrichtlinie zu erstellen. Im obigen Beispiel haben wir die Rolle
mit Poweruser-Rechten angenommen. Dieses Privileg macht den ganzen Zweck der Übung
zunichte.Um dieses Problem zu lösen, haben wir einen AWS Lambda erstellt, der Anmeldeinformationen nur auf der Grundlage einer simulierten IAM-Rolle
ausgibt. Welche Rollen Sie annehmen dürfen, wird durch eine Richtlinie geregelt. Um diesen Lambda zu installieren, geben Sie ein:

aws cloudformation create-stack 
     --stack-name iam-sudo 
    --template-url  https://binxio-public-eu-central-1.s3.amazonaws.com/lambdas/iam-sudo-0.2.0.yaml 
    --capabilities CAPABILITY_NAMED_IAM
aws cloudformation wait stack-create-complete --stack-name iam-sudo

Wenn Sie die Berechtigung haben, den Lambda aufzurufen, können Sie die Rolle mit den vom Lambda bereitgestellten
Anmeldedaten simulieren:

iam-sudo simulate --remote 
   --role-name iam-sudo-demo-my-task 
   aws sts get-caller-identity
{
    "UserId": "AROAWOZQJPZZT625X67RB:iam-sudo-iam-sudo-demo-my-task",
    "Account": "444093529715",
    "Arn": "arn:aws:sts::444093529715:assumed-role/IAMSudoUser/iam-sudo-iam-sudo-demo-my-task"
}

Der eingesetzte Lambda generiert nur Anmeldeinformationen für Rollen für den Dienst ecs-tasks und deren Name
mit iam-sudo-demo beginnt. Sie können die Richtlinie
nach Ihren Bedürfnissen ändern.

Fazit

Damit Entwickler jede Rolle in der Entwicklungsumgebung übernehmen können, muss
jede der Rollen die Berechtigung "Rolle übernehmen" für das AWS-Konto enthalten. Eine bedingte
Erlaubnis zur Übernahme dieser Rollen kann mithilfe von IAM-Ressourcen-Tags implementiert werden. Das Dienstprogramm iam-sudo ist eine alternative Lösung, die eine definierte Rolle simuliert, auch wenn
Sie nicht die Erlaubnis haben, sie zu übernehmen. Die lokale Implementierung ist harmlos. Die Remote-Implementierung
bietet eine Hintertür für die Erhöhung von Berechtigungen, daher empfehle ich, sie nur in
einer Entwicklungsumgebung einzusetzen. Photo by wildan alfani on Unsplash