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.
AWS CodePipeline Beispiele für identitätsbasierte -Richtlinien
Standardmäßig sind IAM-Benutzer und -Rollen nicht berechtigt, CodePipeline Ressourcen zu erstellen oder zu ändern. Sie können auch keine Aufgaben mit der AWS Management Console AWS CLI, oder AWS API ausführen. Ein IAM-Administrator muss IAM-Richtlinien erstellen, die Benutzern und Rollen die Berechtigung zum Ausführen bestimmter API-Operationen für die angegebenen Ressourcen gewähren, die diese benötigen. Der Administrator muss diese Richtlinien anschließend den IAM-Benutzern oder -Gruppen anfügen, die diese Berechtigungen benötigen.
Informationen dazu, wie Sie unter Verwendung dieser beispielhaften JSON-Richtliniendokumente eine identitätsbasierte IAM-Richtlinie erstellen, finden Sie unter Erstellen von Richtlinien auf der JSON-Registerkarte im IAM-Benutzerhandbuch.
Informationen zum Erstellen einer Pipeline, die Ressourcen von einem anderen Konto verwendet, sowie die entsprechenden Beispielrichtlinien finden Sie unterErstellen Sie eine Pipeline CodePipeline , in der Ressourcen von einem anderen AWS Konto verwendet werden.
Themen
- Bewährte Methoden für Richtlinien
- Anzeigen von Ressourcen in der Konsole
- Gewähren der Berechtigung zur Anzeige der eigenen Berechtigungen für Benutzer
- Beispiele für identitätsbasierte Richtlinien (IAM)
- Verwenden von Tags zur Steuerung des Zugriffs auf Ressourcen CodePipeline
- Erforderliche Berechtigungen für die Verwendung der CodePipeline -Konsole
- AWS verwaltete Richtlinien für AWS CodePipeline
- Beispiele für vom Kunden verwaltete Richtlinien
Beispiele für vom Kunden verwaltete Richtlinien
In diesem Abschnitt finden Sie Beispielbenutzerrichtlinien, die Berechtigungen für verschiedene CodePipeline Aktionen gewähren. Diese Richtlinien funktionieren, wenn Sie die CodePipeline API, AWS SDKs oder die AWS CLI verwenden. Bei Verwendung der Konsole müssen Sie zusätzliche konsolenspezifische Berechtigungen erteilen. Weitere Informationen finden Sie unter Erforderliche Berechtigungen für die Verwendung der CodePipeline -Konsole.
Anmerkung
In allen Beispielen werden die Region USA West (Oregon) (us-west-2) und fiktive Konto-IDs verwendet.
Beispiele
Beispiel 1: Gewähren von Berechtigungen zum Abrufen des Status einer Pipeline
Im folgenden Beispiel werden Berechtigungen vergeben, um den Status der Pipeline namens MyFirstPipeline abzurufen:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:GetPipelineState" ], "Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline" } ] }
Beispiel 2: Gewähren von Berechtigungen zum Aktivieren und Deaktivieren von Übergängen zwischen Stufen
Im folgenden Beispiel werden Berechtigungen zum Deaktivieren und Aktivieren von Übergängen zwischen allen Stufen in der Pipeline namens MyFirstPipeline vergeben:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:DisableStageTransition", "codepipeline:EnableStageTransition" ], "Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/*" } ] }
Um dem Benutzer das Deaktivieren und Aktivieren von Übergängen für eine einzelne Stufe in einer Pipeline zu erlauben, müssen Sie die Stufe festlegen. So können Sie z. B. dem Benutzer das Aktivieren und Deaktivieren von Übergängen für eine Stufe mit der Bezeichnung Staging in einer Pipeline namens MyFirstPipeline erlauben:
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/Staging"
Beispiel 3: Gewähren von Berechtigungen zum Abrufen einer Liste mit allen verfügbaren Aktionstypen
Im folgenden Beispiel werden Berechtigungen zum Abrufen einer Liste mit allen Aktionstypen vergeben, die für Pipelines in der Region us-west-2 verfügbar sind:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:ListActionTypes" ], "Resource": "arn:aws:codepipeline:us-west-2:111222333444:actiontype:*" } ] }
Beispiel 4: Gewähren von Berechtigungen für das Erlauben oder Ablehnen von manuellen Genehmigungsaktionen
Im folgenden Beispiel werden Berechtigungen vergeben, um manuelle Genehmigungsaktionen in einer Stufe mit der Bezeichnung Staging in einer Pipeline namens MyFirstPipeline zu erlauben oder abzulehnen:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:PutApprovalResult" ], "Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/Staging/*" } ] }
Beispiel 5: Gewähren von Berechtigungen zum Abfragen von Aufträgen für eine benutzerdefinierte Aktion
Im folgenden Beispiel werden Berechtigungen für das Pipeline-übergreifende Abfragen von Aufträgen für die benutzerdefinierte Aktion mit der Bezeichnung TestProvider vergeben, die ein Test-Aktionstyp in der ersten Version ist:
Anmerkung
Der Job Worker für eine benutzerdefinierte Aktion ist möglicherweise unter einem anderen AWS Konto konfiguriert oder erfordert eine bestimmte IAM-Rolle, um zu funktionieren.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:PollForJobs" ], "Resource": [ "arn:aws:codepipeline:us-west-2:111222333444:actionType:Custom/Test/TestProvider/1" ] } ] }
Beispiel 6: Eine Richtlinie für die Jenkins-Integration mit anhängen oder bearbeiten AWS CodePipeline
Wenn Sie eine Pipeline so konfigurieren, dass sie Jenkins für Build oder Test verwendet, erstellen Sie eine separate Identität für diese Integration und fügen Sie eine IAM-Richtlinie hinzu, die über die Mindestberechtigungen verfügt, die für die Integration zwischen Jenkins und erforderlich sind. CodePipeline Die Richtlinie ist die gleiche wie die verwaltete Richtlinie AWSCodePipelineCustomActionAccess. Das folgende Beispiel zeigt eine Richtlinie für die Jenkins-Integration:
{ "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:AcknowledgeJob", "codepipeline:GetJobDetails", "codepipeline:PollForJobs", "codepipeline:PutJobFailureResult", "codepipeline:PutJobSuccessResult" ], "Resource": "*" } ], "Version": "2012-10-17" }
Beispiel 7: Konfigurieren des kontoübergreifenden Zugriffs auf eine Pipeline
Sie können den Pipeline-Zugriff für Benutzer und Gruppen in einem anderen AWS -Konto konfigurieren. Die empfohlene Methode besteht darin, eine Rolle in dem Konto zu erstellen, in dem die Pipeline erstellt wurde. Die Rolle sollte es Benutzern des anderen AWS Kontos ermöglichen, diese Rolle anzunehmen und auf die Pipeline zuzugreifen. Weitere Informationen finden Sie unter Anleitung: Kontenübergreifender Zugriff mithilfe von Rollen.
Das folgende Beispiel zeigt eine Richtlinie im 80398EXAMPLE-Konto, die es Benutzern ermöglicht, die MyFirstPipeline in der Konsole angegebene Pipeline anzuzeigen, aber nicht zu ändern. CodePipeline Diese Richtlinie basiert auf der verwalteten Richtlinie AWSCodePipeline_ReadOnlyAccess, aber da sie spezifisch für die Pipeline MyFirstPipeline gilt, kann sie die verwaltete Richtlinie nicht direkt verwenden. Wenn Sie die Richtlinie nicht auf eine bestimmte Pipeline beschränken möchten, sollten Sie in Erwägung ziehen, eine der verwalteten Richtlinien zu verwenden, die von erstellt und verwaltet wurden. CodePipeline Weitere Informationen finden Sie unter Arbeiten mit verwalteten Richtlinien. Sie müssen diese Richtlinie einer IAM-Rolle zuordnen, die Sie für den Zugriff erstellen, z. B. einer Rolle mit dem NamenCrossAccountPipelineViewers:
{ "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:GetPipeline", "codepipeline:GetPipelineState", "codepipeline:ListActionTypes", "codepipeline:ListPipelines", "iam:ListRoles", "s3:GetBucketPolicy", "s3:GetObject", "s3:ListAllMyBuckets", "s3:ListBucket", "codedeploy:GetApplication", "codedeploy:GetDeploymentGroup", "codedeploy:ListApplications", "codedeploy:ListDeploymentGroups", "elasticbeanstalk:DescribeApplications", "elasticbeanstalk:DescribeEnvironments", "lambda:GetFunctionConfiguration", "lambda:ListFunctions" ], "Resource": "arn:aws:codepipeline:us-east-2:80398EXAMPLE:MyFirstPipeline" } ], "Version": "2012-10-17" }
Nachdem Sie diese Richtlinie erstellt haben, erstellen Sie die IAM-Rolle im 80398EXAMPLE-Konto und fügen Sie die Richtlinie dieser Rolle hinzu. Zu den Vertrauensstellungen der Rolle müssen Sie das AWS Konto hinzufügen, das diese Rolle übernimmt. Das folgende Beispiel zeigt eine Richtlinie, die es Benutzern des Kontos 1111111111 ermöglicht, Rollen anzunehmen, die im AWS Konto 80398EXAMPLE definiert sind:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111111111111:root" }, "Action": "sts:AssumeRole" } ] }
Das folgende Beispiel zeigt eine im Konto 111111111111 erstellte Richtlinie, die es Benutzern ermöglicht, die im AWS Konto 80398EXAMPLE angegebene Rolle anzunehmen: CrossAccountPipelineViewers
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::80398EXAMPLE:role/CrossAccountPipelineViewers" } ] }
Beispiel 8: Verwenden von AWS -Ressourcen, die mit einem anderen Konto in einer Pipeline verknüpft sind
Sie können Richtlinien konfigurieren, die es einem Benutzer ermöglichen, eine Pipeline zu erstellen, die Ressourcen in einem anderen Konto verwendet. AWS Dies erfordert die Konfiguration von Richtlinien und Rollen sowohl im Konto, das die Pipeline erstellen wird (AccountA), als auch im Konto, das die Ressourcen erstellt hat, die in der Pipeline verwendet werden sollen (AccountB). Sie müssen auch ein vom Kunden verwaltetes Key-In erstellen AWS Key Management Service , das Sie für den kontoübergreifenden Zugriff verwenden können. Weitere Informationen und step-by-step Beispiele finden Sie unter Erstellen Sie eine Pipeline CodePipeline , in der Ressourcen von einem anderen AWS Konto verwendet werden undKonfigurieren Sie die serverseitige Verschlüsselung für in Amazon S3 gespeicherte Artefakte für CodePipeline.
Das folgende Beispiel zeigt eine Richtlinie, die von AccountA für einen S3-Bucket konfiguriert wurde, der zum Speichern von Pipeline-Artefakten verwendet wird. Die Richtlinie gewährt Zugriff auf AccountB. Im folgenden Beispiel lautet der ARN für AccountB 012ID_ACCOUNT_B. Der ARN für den S3-Bucket lautet codepipeline-us-east-2-1234567890. Ersetzen Sie diese ARNs durch die ARNs für den S3-Bucket und das Konto, für die Sie Zugriff erlauben möchten:
{ "Version": "2012-10-17", "Id": "SSEAndSSLPolicy", "Statement": [ { "Sid": "DenyUnEncryptedObjectUploads", "Effect": "Deny", "Principal": "*", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890/*", "Condition": { "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" } } }, { "Sid": "DenyInsecureConnections", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890/*", "Condition": { "Bool": { "aws:SecureTransport": false } } }, { "Sid": "", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::012ID_ACCOUNT_B:root" }, "Action": [ "s3:Get*", "s3:Put*" ], "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890/*" }, { "Sid": "", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::012ID_ACCOUNT_B:root" }, "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::codepipeline-us-east-2-1234567890" } ] }
Das folgende Beispiel zeigt eine von AccountA konfigurierte Richtlinie, die von AccountB ermöglicht, eine Rolle anzunehmen. Diese Richtlinie muss auf die Servicerolle für CodePipeline (CodePipeline_Service_Role) angewendet werden. Weitere Informationen zum Anwenden von Richtlinien auf Rollen in IAM finden Sie unter Rolle ändern. Im folgenden Beispiel ist 012ID_ACCOUNT_B der ARN für AccountB:
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::012ID_ACCOUNT_B:role/*" ] } }
Das folgende Beispiel zeigt eine Richtlinie, die von AccountB konfiguriert und auf die EC2-Instance-Rolle für angewendet wurde. CodeDeploy Diese Richtlinie gewährt Zugriff auf den S3-Bucket, der von AccountA zum Speichern von Pipeline-Artefakten verwendet wird (codepipeline-us-east-2-1234567890):
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:Get*" ], "Resource": [ "arn:aws:s3:::codepipeline-us-east-2-1234567890/*" ] }, { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::codepipeline-us-east-2-1234567890" ] } ] }
Das folgende Beispiel zeigt eine Richtlinie dafür, AWS KMS wo sich der ARN des vom Kunden verwalteten Schlüssels arn:aws:kms:us-east-1:012ID_ACCOUNT_A:key/2222222-3333333-4444-556677EXAMPLE
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:DescribeKey", "kms:GenerateDataKey*", "kms:Encrypt", "kms:ReEncrypt*", "kms:Decrypt" ], "Resource": [ "arn:aws:kms:us-east-1:012ID_ACCOUNT_A:key/2222222-3333333-4444-556677EXAMPLE" ] } ] }
Das folgende Beispiel zeigt eine Inline-Richtlinie für eine von AccountB erstellte IAM-Rolle (CrossAccount_Role), die den Zugriff auf CodeDeploy Aktionen ermöglicht, die für die Pipeline in AccountA erforderlich sind.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codedeploy:CreateDeployment", "codedeploy:GetDeployment", "codedeploy:GetDeploymentConfig", "codedeploy:GetApplicationRevision", "codedeploy:RegisterApplicationRevision" ], "Resource": "*" } ] }
Das folgende Beispiel zeigt eine Inline-Richtlinie für eine von AccountB erstellte IAM-Rolle (CrossAccount_Role), die den Zugriff auf den S3-Bucket ermöglicht, um Eingabeartefakte herunterzuladen und Ausgabeartefakte hochzuladen:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject*", "s3:PutObject", "s3:PutObjectAcl" ], "Resource": [ "arn:aws:s3:::codepipeline-us-east-2-1234567890/*" ] } ] }
Weitere Informationen zum Bearbeiten einer Pipeline für kontenübergreifenden Zugriff auf Ressourcen finden Sie unter Schritt 2: Bearbeiten der Pipeline .
