Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Stellen Sie IAM-Rollen mit den geringsten Rechten bereit, indem Sie eine Rollenautomatenlösung bereitstellen *Benjamin Morris, Nima Fotouhi, Aman Kaur Gandhi und Tschad Moon, Amazon Web Services* ## Zusammenfassung Rollenberechtigungen mit übermäßigem Geltungsbereich AWS Identity and Access Management (IAM) für Pipelines können zu unnötigen Risiken für ein Unternehmen führen. Entwickler gewähren manchmal während der Entwicklung weitreichende Berechtigungen, vernachlässigen es jedoch, nach der Fehlerbehebung im Code die Zugriffsrechte einzuschränken. Dies führt zu Problemen, wenn leistungsstarke Rollen ohne geschäftliche Notwendigkeit vorhanden sind und möglicherweise noch nie von einem Sicherheitsingenieur überprüft wurden. Dieses Muster bietet eine Lösung für dieses Problem: der Rollenverkaufsautomat (RVM). Mithilfe eines sicheren und zentralisierten Bereitstellungsmodells demonstriert das RVM, wie IAM-Rollen mit den geringsten Rechten für die Pipelines einzelner GitHub Repositorys mit minimalem Aufwand für Entwickler bereitgestellt werden können. Da es sich bei der RVM um eine zentrale Lösung handelt, können Sie Ihre Sicherheitsteams als Prüfer konfigurieren, die Änderungen genehmigen müssen. Dieser Ansatz ermöglicht es der Sicherheitsabteilung, zu viele Anfragen an Pipeline-Rollen zurückzuweisen. Die RVM verwendet Terraform-Code als Eingabe und generiert Pipeline-bereite IAM-Rollen als Ausgabe. Die erforderlichen Eingaben sind die AWS-Konto ID, der GitHub Repository-Name und die Berechtigungsrichtlinie. Die RVM verwendet diese Eingaben, um die Vertrauensrichtlinie und die Berechtigungsrichtlinie der Rolle zu erstellen. Die daraus resultierende Vertrauensrichtlinie ermöglicht es dem angegebenen GitHub Repository, die Rolle zu übernehmen und sie für Pipeline-Operationen zu verwenden. Die RVM verwendet eine IAM-Rolle (die beim Bootstrap konfiguriert wurde). Diese Rolle ist berechtigt, role-provisioning-role in jedem Konto der Organisation eine anzunehmen. Die Rolle wird entweder über AWS Control Tower Account Factory for Terraform (AFT) oder konfiguriert. AWS CloudFormation StackSets Dies role-provisioning-roles sind die Rollen, die tatsächlich die Pipeline-Rollen für Entwickler erstellen. ## Voraussetzungen und Einschränkungen **Voraussetzungen** + Ein aktiver AWS-Konto. + Eine GitHub Organisation, die zur Bereitstellung von Infrastructure as Code (IaC) im Rahmen von GitHub Aktionen verwendet wird. (GitHub Enterprise/Premium/Ultimatesind *nicht***** erforderlich.) + Eine AWS Umgebung mit mehreren Konten. Diese Umgebung muss nicht Teil davon AWS Organizations sein. + Ein Mechanismus für die Bereitstellung einer IAM-Rolle in allen Bereichen AWS-Konten (z. B. AFT oder CloudFormation StackSets). + Terraform Version 1.3 oder höher wurde [installiert](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) und konfiguriert. + [https://github.com/hashicorp/terraform-provider-aws/releases](https://github.com/hashicorp/terraform-provider-aws/releases) **Einschränkungen** + Der Code dieses Musters ist spezifisch für GitHub Actions und Terraform. Die allgemeinen Konzepte des Musters können jedoch in anderen Continuous Integration and Delivery (CI/CD) -Frameworks wiederverwendet werden. + Einige AWS-Services sind nicht in allen verfügbar. AWS-Regionen Informationen zur Verfügbarkeit in den einzelnen Regionen finden Sie unter [AWS Dienste nach Regionen](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/). Informationen zu bestimmten Endpunkten finden Sie unter [Dienstendpunkte und Kontingente](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html). Wählen Sie dort den Link für den Dienst aus. ## Architektur Das folgende Diagramm veranschaulicht den Arbeitsablauf für dieses Muster. ![Workflow zur Automatisierung der Erstellung und Bereitstellung von IAM-Rollen mithilfe von GitHub Aktionen.](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/images/pattern-img/215c590e-0c84-411d-be6e-b1739f1e19d2/images/82fcdc9f-9576-4e7c-b7fe-b45046ba79d2.png) Der Arbeitsablauf für die typische Verwendung der Rolle Verkaufsautomat besteht aus den folgenden Schritten: 1. Ein Entwickler überträgt Code, der Terraform-Code für eine neu angeforderte IAM-Rolle enthält, in das RVM-Repository. GitHub Diese Aktion löst die RVM-Aktionspipeline aus. GitHub 1. Die Pipeline verwendet eine OpenID Connect (OIDC) -Vertrauensrichtlinie, um die Rolle der RVM-Rollenübernahme zu übernehmen. 1. Bei der Ausführung der RVM-Pipeline übernimmt sie die RVM-Workflow-Rolle in dem Konto, in dem sie die neue IAM-Rolle des Entwicklers bereitstellt. (Die RVM-Workflow-Rolle wurde mithilfe von AFT oder bereitgestellt.) CloudFormation StackSets 1. Die RVM erstellt die IAM-Rolle des Entwicklers mit den entsprechenden Berechtigungen und der entsprechenden Vertrauensstellung, sodass die Rolle von anderen Anwendungspipelines übernommen werden kann. 1. App-Entwickler können ihre App-Pipelines so konfigurieren, dass sie diese vom RVM bereitgestellte Rolle übernehmen. Die erstellte Rolle umfasst die vom Entwickler angeforderten Berechtigungen und eine Richtlinie. `ReadOnlyAccess` Die Rolle kann nur von Pipelines übernommen werden, die für den `main` Zweig des vom Entwickler angegebenen Repositorys ausgeführt werden. Dieser Ansatz trägt dazu bei, dass Branch-Schutz und Überprüfungen erforderlich sein können, um die Rolle nutzen zu können. **Automatisierung und Skalierung** Bei den Berechtigungen mit den geringsten Rechten ist für jede Rolle, die bereitgestellt wird, besondere Aufmerksamkeit erforderlich. Dieses Modell reduziert die Komplexität, die für die Erstellung dieser Rollen erforderlich ist, und ermöglicht es Entwicklern, die Rollen zu erstellen, die sie benötigen, ohne dass viel zusätzliches Lernen oder Aufwand erforderlich ist. ## Tools **AWS-Services** + [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) hilft Ihnen dabei, den Zugriff auf Ihre AWS Ressourcen sicher zu verwalten, indem kontrolliert wird, wer authentifiziert und autorisiert ist, diese zu verwenden. + [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)ist ein Kontoverwaltungsservice, mit dem Sie mehrere Konten zu einer Organisation AWS-Konten zusammenfassen können, die Sie erstellen und zentral verwalten. **Andere Tools** + [Git](https://git-scm.com/docs) ist ein verteiltes Open-Source-Versionskontrollsystem. Es beinhaltet die Möglichkeit, ein [Organisationskonto](https://docs.github.com/en/get-started/learning-about-github/types-of-github-accounts#organization-accounts) zu erstellen. + [GitHub Actions](https://docs.github.com/en/actions/writing-workflows/quickstart) ist eine CI/CD-Plattform (Continuous Integration and Continuous Delivery), die eng in Repositorys integriert GitHub ist. Sie können GitHub Actions verwenden, um Ihre Build-, Test- und Bereitstellungspipeline zu automatisieren. + [Terraform](https://www.terraform.io/) ist ein IaC-Tool (Infrastructure as Code) HashiCorp , mit dem Sie Cloud- und lokale Ressourcen erstellen und verwalten können. **Code-Repository** Der Code für dieses Muster ist im GitHub [role-vending-machine](https://github.com/aws-samples/role-vending-machine)Repository verfügbar. ## Best Practices + **Machen Sie den richtigen Weg einfach und den falschen Weg schwer** — Machen Sie es einfach, das Richtige zu tun. Wenn Entwickler Probleme mit dem RVM-Bereitstellungsprozess haben, versuchen sie möglicherweise, Rollen auf andere Weise zu erstellen, wodurch der zentrale Charakter von RVM untergraben wird. Stellen Sie sicher, dass Ihr Sicherheitsteam klare Anweisungen zur sicheren und effektiven Verwendung der RVM gibt. Sie sollten es Entwicklern auch schwer machen, das Falsche zu tun. Verwenden Sie Dienststeuerungsrichtlinien (SCPs) oder Berechtigungsgrenzen, um einzuschränken, welche Rollen andere Rollen erstellen können. Dieser Ansatz kann dazu beitragen, die Rollenerstellung auf RVM und andere vertrauenswürdige Quellen zu beschränken. + **Nennen Sie gute Beispiele** — Es ist unvermeidlich, dass einige Entwickler bestehende Rollen im RVM-Repository als informelle Vorlagen für die Erteilung von Berechtigungen für ihre neuen Rollen anpassen. Wenn Sie über Beispiele mit den geringsten Berechtigungen verfügen, von denen sie kopieren können, kann das Risiko verringert werden, dass Entwickler umfassende Berechtigungen mit Platzhaltern anfordern. Wenn Sie mit Rollen mit hohen Rechten und vielen Platzhaltern beginnen, kann sich dieses Problem mit der Zeit noch vergrößern. + **Benennungskonventionen und -bedingungen verwenden** — Selbst wenn ein Entwickler nicht alle Ressourcennamen kennt, die seine Anwendung erstellen wird, sollte er dennoch die Rollenberechtigungen mithilfe einer Namenskonvention einschränken. Wenn sie beispielsweise Amazon S3 S3-Buckets erstellen, könnte der Wert ihres Ressourcenschlüssels `arn:aws:s3:::myorg-myapp-dev-*` so aussehen, dass ihre Rolle keine Berechtigungen hat, die über Buckets hinausgehen, die diesem Namen entsprechen. Die Durchsetzung der Namenskonvention durch eine IAM-Richtlinie hat den zusätzlichen Vorteil, dass die Einhaltung der Namenskonvention verbessert wird. Diese Verbesserung ist darauf zurückzuführen, dass nicht übereinstimmende Ressourcen nicht erstellt werden dürfen. + **Pull-Request-Reviews (PR) erforderlich** — Der Vorteil der RVM-Lösung besteht darin, dass sie einen zentralen Ort schafft, an dem neue Pipeline-Rollen überprüft werden können. Dieses Design ist jedoch nur dann sinnvoll, wenn es Schutzmaßnahmen gibt, die sicherstellen, dass sicherer, qualitativ hochwertiger Code an die RVM übergeben wird. Schützt die Branches, die zum Bereitstellen von Code verwendet werden (z. B.`main`), vor direkten Pushs und erfordert Genehmigungen für alle Merge-Anfragen, die auf sie abzielen. + **Schreibgeschützte Rollen konfigurieren** — Standardmäßig stellt die RVM eine `readonly` Version jeder angeforderten Rolle bereit. Diese Rolle kann in CI/CD Pipelines verwendet werden, die keine Daten schreiben, z. B. in einem Pipeline-Workflow. `terraform plan` Dieser Ansatz trägt dazu bei, unerwünschte Änderungen zu verhindern, wenn sich ein schreibgeschützter Workflow schlecht verhält. Standardmäßig ist die AWS verwaltete `ReadOnlyAccess` Richtlinie sowohl den Rollen mit Schreibzugriff als auch den Rollen mit Lese-/Schreibzugriff zugeordnet. Diese Richtlinie reduziert den Bedarf an Wiederholungen bei der Festlegung der erforderlichen Berechtigungen, kann jedoch für einige Organisationen zu freizügig sein. Wenn Sie möchten, können Sie die Richtlinie aus dem Terraform-Code entfernen. + **Mindestberechtigungen gewähren** — Folgen Sie dem Prinzip der geringsten Rechte und gewähren Sie die Mindestberechtigungen, die zur Ausführung einer Aufgabe erforderlich sind. Weitere Informationen finden Sie in der IAM-Dokumentation unter [Gewährung der geringsten Rechte](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#grant-least-priv) und [bewährte Methoden zur Sicherheit](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html). ## Epen ### Bereite die Umgebung vor | Aufgabe | Description | Erforderliche Fähigkeiten | | --- | --- | --- | | Kopieren Sie das Beispiel-Repository in Ihre GitHub Organisation. | [Klonen](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository) Sie das Repository dieses [Musters](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo) oder teilen Sie dieses Repository auf Ihre GitHub Organisation ab, sodass Sie es an Ihre Bedürfnisse anpassen können.[See the AWS documentation website for more details](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.html) | DevOps Ingenieur | | Ermitteln Sie den AWS-Konto für das RVM. | Ermitteln Sie, welche Infrastrukturbereitstellung für die RVM verwendet werden AWS-Konto soll. Verwenden Sie nicht das Management- oder Root-Konto. | Cloud-Architekt | | (Optional) Erlauben Sie, dass die Pipelines der Organisation erstellt PRs werden. | Dieser Schritt ist nur erforderlich, wenn Sie die Erstellung PRs des `generate_providers_and_account_vars` Workflows zulassen möchten.Gehen Sie wie folgt vor PRs, damit die Pipelines Ihrer Organisation erstellt werden können:[See the AWS documentation website for more details](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.html)
Weitere Informationen finden Sie in der GitHub Dokumentation unter [ GitHub Aktionseinstellungen für ein Repository verwalten](https://docs.github.com/en/enterprise-server@3.10/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#preventing-github-actions-from-creating-or-approving-pull-requests). | DevOps Ingenieur | | Gewähren Sie dem RVM-Konto nur Leseberechtigungen. | Erstellen Sie in Ihrem Verwaltungskonto eine Delegierungsrichtlinie, die Ihrem RVM-Konto nur Leseberechtigungen gewährt. Auf diese Weise können Ihre GitHub RVM-Workflows dynamisch eine Liste der Konten Ihrer AWS Organisation abrufen, wenn das Skript ausgeführt wird. `generate_providers_and_account_vars.py`
Verwenden Sie den folgenden Code und `` ersetzen Sie ihn durch die AWS-Konto ID, die Sie in Schritt 2 ausgewählt haben:
{
  "Version": "2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "Statement",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam:::root"
      },
      "Action": [
        "organizations:ListAccounts",
        "organizations:DescribeOrganization",
        "organizations:DescribeOrganizationalUnit",
        "organizations:ListRoots",
        "organizations:ListAWSServiceAccessForOrganization",
        "organizations:ListDelegatedAdministrators"
      ],
      "Resource": "*"
    }
  ]
}
| Cloud-Administrator | | Aktualisieren Sie die Standardwerte aus dem Beispiel-Repository. | Gehen Sie wie folgt vor, um die RVM für den Betrieb in Ihrer spezifischen Umgebung zu konfigurieren: AWS-Region[See the AWS documentation website for more details](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.html) | DevOps Ingenieur | ### Infrastruktur initialisieren | Aufgabe | Description | Erforderliche Fähigkeiten | | --- | --- | --- | | Bootstrap für das RVM-Repo. | Dieser Schritt ist erforderlich, um die OIDC-Vertrauens- und IAM-Rollen zu erstellen, die von der RVM-Pipeline selbst verwendet werden, sodass sie den Betrieb aufnehmen und andere Rollen verkaufen kann.
Führen Sie im Kontext Ihres RVM-Kontos manuell einen `terraform apply` Befehl aus dem Verzeichnis aus. `scripts/bootstrap` Geben Sie alle erforderlichen Werte auf der Grundlage der Variablendokumentation an. | DevOps Ingenieur | ### Operationen konfigurieren | Aufgabe | Description | Erforderliche Fähigkeiten | | --- | --- | --- | | Stellen Sie die `github-workflow-rvm-readonly` Rollen `github-workflow-rvm` und für alle Konten bereit. | Wählen Sie eine Bereitstellungsmethode, die den Praktiken Ihres Unternehmens entspricht, z. B. AFT oder StackSets. Verwenden Sie diese Methode, um die beiden IAM-Rollen in der `scripts/assumed_role/main.tf` Datei (Standardnamen `github-workflow-rvm` und`github-workflow-rvm-readonly`) für jedes Konto bereitzustellen, für das die RVM Pipeline-Rollen erstellen soll.
Diese IAM-Rollen verfügen über Vertrauensrichtlinien, die es der Rolle des RVM-Kontos (oder einer gleichwertigen Rolle) ermöglichen, diese Rolle zu übernehmen. `readonly` Die Rollen verfügen außerdem über IAM-Berechtigungsrichtlinien, die es ihnen ermöglichen, übereinstimmende Rollen zu lesen und zu schreiben (sofern sie nicht die `readonly` Rolle verwenden). `github-workflow-role-*` | AWS-Administrator | | Führen Sie den `generate_providers_and_account_vars` Workflow aus. | Gehen Sie wie folgt vor, um Ihre RVM so zu konfigurieren, dass sie bereit ist, Pipeline-Rollen zu erstellen:[See the AWS documentation website for more details](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.html)
Nach Abschluss des Workflows ist die RVM bereit für:[See the AWS documentation website for more details](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/provision-least-privilege-iam-roles-by-deploying-a-role-vending-machine-solution.html) | DevOps Ingenieur | ## Fehlerbehebung | Problem | Lösung | | --- | --- | | Ich habe mit dem RVM eine Rolle erstellt, kann sie aber GitHub nicht übernehmen. | Stellen Sie sicher, dass der Name des GitHub Repositorys mit dem Namen übereinstimmt, der dem `github_workflow_roles` Modul zur Verfügung gestellt wurde. Rollen sind so begrenzt, dass sie nur von einem Repository übernommen werden können.
Stellen Sie auf ähnliche Weise sicher, dass der in der GitHub Pipeline verwendete Branch mit dem Namen des Branches übereinstimmt, der dem Modul zur Verfügung gestellt wurde. `github_workflow_roles` In der Regel können von RVM erstellte Rollen mit Schreibberechtigungen nur von Workflows verwendet werden, die auf den `main` Branch beschränkt sind (d. h. Bereitstellungen, aus denen sie stammen). `main` | | Meine schreibgeschützte Rolle kann ihre Pipeline nicht ausführen, da ihr die Berechtigungen zum Lesen einer bestimmten Ressource fehlen. | Die `ReadOnlyAccess` Richtlinie bietet zwar umfangreiche Leseberechtigungen, einige Leseaktionen (z. B. bestimmte Aktionen) sind in der Richtlinie jedoch nicht vorgesehen. AWS Security Hub CSPM
Sie können spezifische Aktionsberechtigungen hinzufügen, indem Sie den `inline_policy_readonly` Parameter des `github-workflow-roles` Moduls verwenden. | ## Zugehörige Ressourcen + [Bewährte Methoden für die Verwendung AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-bestpractices.html) + [Organisieren Sie Ihre AWS Umgebung mithilfe mehrerer Konten](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) + [Überblick über AWS Control Tower Account Factory for Terraform (AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) + [Bewährte Methoden für Richtlinien](https://docs.aws.amazon.com/codepipeline/latest/userguide/security_iam_service-with-iam-policy-best-practices.html) ## Zusätzliche Informationen ** GitHub Umgebungen verwenden** GitHub Umgebungen sind ein alternativer Ansatz zu branchenbasierten Einschränkungen des Rollenzugriffs. Wenn Sie lieber eine GitHub Umgebung verwenden möchten, finden Sie im Folgenden ein Beispiel für die Syntax für eine zusätzliche Bedingung in der IAM-Vertrauensrichtlinie. Diese Syntax gibt an, dass die Rolle nur verwendet werden kann, wenn die GitHub Aktion in der `Production` Umgebung ausgeführt wird. ``` "StringLike": { "token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:environment:Production" } ``` Die Beispielsyntax verwendet die folgenden Platzhalterwerte: + `octo-org`ist der Name der GitHub Organisation. + `octo-repo`ist der Name des Repositorys. + `Production`ist der spezifische GitHub Umgebungsname.