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 dem AWS Management Console AWS CLI, oder ausführen AWS API. Ein IAM Administrator muss IAM Richtlinien erstellen, die Benutzern und Rollen die Berechtigung gewähren, bestimmte API Operationen mit den angegebenen Ressourcen auszuführen, die sie benötigen. Der Administrator muss diese Richtlinien dann den IAM Benutzern oder Gruppen zuordnen, für die diese Berechtigungen erforderlich sind.
Informationen zum Erstellen einer IAM identitätsbasierten Richtlinie anhand dieser JSON Beispieldokumente finden Sie unter Richtlinien auf der JSON Registerkarte erstellen im IAMBenutzerhandbuch.
Informationen zum Erstellen einer Pipeline, die Ressourcen von einem anderen Konto verwendet, sowie die entsprechenden Beispielrichtlinien finden Sie unter. Erstellen 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 CodePipeline Ressourcen
- Erforderliche Berechtigungen für die Verwendung der CodePipeline -Konsole
- Zum Anzeigen von Rechenprotokollen in der CodePipeline Konsole sind Berechtigungen erforderlich
- 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 verwenden AWS CLI. 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
Alle Beispiele verwenden die Region USA West (Oregon) (us-west-2) und enthalten ein fiktives Konto. IDs
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 EXAMPLE 80398-Konto, die es Benutzern ermöglicht, die MyFirstPipeline in der CodePipeline Konsole angegebene Pipeline anzuzeigen, aber nicht zu ändern. 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 CodePipeline erstellt und verwaltet wurden. 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 EXAMPLE 80398-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 aus dem ermöglicht 111111111111 AWS Konto, um Rollen anzunehmen, die im EXAMPLE 80398-Konto definiert sind:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111111111111:root" }, "Action": "sts:AssumeRole" } ] }
Das folgende Beispiel zeigt eine Richtlinie, die erstellt wurde in 111111111111 AWS Konto, das es Benutzern ermöglicht, die CrossAccountPipelineViewers im EXAMPLE 80398-Konto angegebene Rolle anzunehmen:
{ "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 AWS Konto verwendet. 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 einen vom Kunden verwalteten Schlüssel für AWS Key Management Service den kontoübergreifenden Zugriff erstellen. 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 ist 012ID_ACCOUNT_B der ARN für AccountB. Der ARN für den S3-Bucket istcodepipeline-us-east-2-1234567890. Ersetzen Sie diese ARNs durch die ARNs für den S3-Bucket und das Konto, dem Sie den Zugriff gewähren 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 finden Sie unter Rolle ändern inIAM. Im folgenden Beispiel 012ID_ACCOUNT_B ist 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 EC2Instanzrolle für CodeDeploy angewendet wurde. 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 für den AWS KMS Speicherort ARN des vom Kunden verwalteten Schlüssels, der in AccountA erstellt und so konfiguriert 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 IAM Rolle (CrossAccount_Role), die von AccountB erstellt wurde und 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 IAM Rolle (CrossAccount_Role), die von AccountB erstellt wurde und 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 .
