AWS CodeCommit ist für Neukunden nicht mehr verfügbar. Bestandskunden von AWS CodeCommit können den Service weiterhin wie gewohnt nutzen. Erfahren Sie mehr“
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.
Beispiele für vom Kunden verwaltete Richtlinien
Sie können Ihre eigenen benutzerdefinierten IAM Richtlinien erstellen, um Berechtigungen für CodeCommit Aktionen und Ressourcen zu gewähren. Sie können diese benutzerdefinierten Richtlinien den IAM Benutzern oder Gruppen zuordnen, die diese Berechtigungen benötigen. Sie können auch Ihre eigenen benutzerdefinierten IAM Richtlinien für die Integration zwischen CodeCommit und anderen AWS Diensten erstellen.
Themen
Beispiele für vom Kunden verwaltete Identitätsrichtlinien
Die folgenden IAM Beispielrichtlinien gewähren Berechtigungen für verschiedene CodeCommit Aktionen. Verwenden Sie sie, um CodeCommit den Zugriff für Ihre IAM Benutzer und Rollen einzuschränken. Diese Richtlinien steuern die Fähigkeit, Aktionen mit der CodeCommit Konsole, API AWS SDKs, oder der auszuführen AWS CLI.
Anmerkung
Alle Beispiele verwenden die Region USA West (Oregon) (us-west-2) und enthalten ein fiktives Konto. IDs
Beispiele
Beispiel 1: Erlauben Sie einem Benutzer, Operationen CodeCommit in einem einzigen AWS-Region
Die folgende Berechtigungsrichtlinie verwendet ein Platzhalterzeichen ("codecommit:*"), damit Benutzer alle CodeCommit Aktionen in der Region us-east-2 und nicht von anderen aus ausführen können. AWS-Regionen
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "codecommit:*", "Resource": "arn:aws:codecommit:us-east-2:111111111111:*", "Condition": { "StringEquals": { "aws:RequestedRegion": "us-east-2" } } }, { "Effect": "Allow", "Action": "codecommit:ListRepositories", "Resource": "*", "Condition": { "StringEquals": { "aws:RequestedRegion": "us-east-2" } } } ] }
Beispiel 2: Erlaube einem Benutzer, Git für ein einzelnes Repository zu verwenden
CodeCommitIn gelten die GitPull IAM Richtlinienberechtigungen für jeden Git-Client-Befehl CodeCommit, von dem Daten abgerufen werden git fetchgit clone, einschließlich, usw. In ähnlicher Weise gelten die GitPush IAM Richtlinienberechtigungen für jeden Git-Client-Befehl, an den Daten gesendet werden CodeCommit. Wenn die GitPush IAM Richtlinienberechtigung beispielsweise auf gesetzt istAllow, kann ein Benutzer das Löschen eines Branches mithilfe des Git-Protokolls vorantreiben. Dieser Push wird nicht von den Berechtigungen beeinflusst, die für diesen IAM Benutzer auf den DeleteBranch Vorgang angewendet wurden. Die DeleteBranch Berechtigung gilt für Aktionen, die mit der Konsole, dem AWS CLI, dem und dem SDKsAPI, aber nicht mit dem Git-Protokoll ausgeführt werden.
Das folgende Beispiel ermöglicht es dem angegebenen Benutzer, Daten aus dem angegebenen CodeCommit Repository abzurufen und dorthin zu pushenMyDemoRepo:
{ "Version": "2012-10-17", "Statement" : [ { "Effect" : "Allow", "Action" : [ "codecommit:GitPull", "codecommit:GitPush" ], "Resource" : "arn:aws:codecommit:us-east-2:111111111111:MyDemoRepo" } ] }
Beispiel 3: Erlaubt einem Benutzer, der von einem bestimmten IP-Adressbereich aus eine Verbindung herstellt, Zugriff auf ein Repository
Sie können eine Richtlinie erstellen, die es Benutzern nur erlaubt, eine Verbindung zu einem CodeCommit Repository herzustellen, wenn ihre IP-Adresse innerhalb eines bestimmten IP-Adressbereichs liegt. Dazu gibt es zwei gleichwertige Ansätze. Sie können eine Deny Richtlinie erstellen, die CodeCommit Operationen verbietet, wenn sich die IP-Adresse des Benutzers nicht in einem bestimmten Block befindet, oder Sie können eine Allow Richtlinie erstellen, die CodeCommit Operationen zulässt, wenn sich die IP-Adresse des Benutzers innerhalb eines bestimmten Blocks befindet.
Sie können eine Deny-Richtlinie erstellen, die den Zugriff für alle Benutzer verweigert, die sich nicht aus einem bestimmten IP-Adressbereich stammen. Sie könnten beispielsweise allen Benutzern, die AWSCodeCommitPowerUser Zugriff auf Ihr Repository benötigen, die verwaltete Richtlinie und eine vom Kunden verwaltete Richtlinie zuordnen. Die folgende Beispielrichtlinie verweigert Benutzern, deren IP-Adressen nicht innerhalb des angegebenen IP-Adressblocks 203.0.113.0/16 liegen, alle CodeCommit Berechtigungen:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "codecommit:*" ], "Resource": "*", "Condition": { "NotIpAddress": { "aws:SourceIp": [ "203.0.113.0/16" ] } } } ] }
Mit der folgenden Beispielrichtlinie kann der angegebene Benutzer nur dann auf ein CodeCommit Repository zugreifen, das MyDemoRepo mit den entsprechenden Berechtigungen der AWSCodeCommitPowerUser verwalteten Richtlinie benannt ist, wenn sich seine IP-Adresse innerhalb des angegebenen Adressblocks 203.0.113.0/16 befindet:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codecommit:BatchGetRepositories", "codecommit:CreateBranch", "codecommit:CreateRepository", "codecommit:Get*", "codecommit:GitPull", "codecommit:GitPush", "codecommit:List*", "codecommit:Put*", "codecommit:Post*", "codecommit:Merge*", "codecommit:TagResource", "codecommit:Test*", "codecommit:UntagResource", "codecommit:Update*" ], "Resource": "arn:aws:codecommit:us-east-2:111111111111:MyDemoRepo", "Condition": { "IpAddress": { "aws:SourceIp": [ "203.0.113.0/16" ] } } } ] }
Beispiel 4: Aktionen für Branches verweigern oder zulassen
Sie können eine Richtlinie erstellen, die Benutzern die Berechtigungen für Aktionen verweigert, die Sie für eine oder mehrere Verzweigungen angeben. Alternativ können Sie eine Richtlinie erstellen, die Aktionen für eine oder mehrere Verzweigungen erlaubt, die sie sonst nicht in anderen Verzweigungen eines Repositories haben. Sie können diese Richtlinien mit den entsprechenden verwalteten (vordefinierten) Richtlinien verwenden. Weitere Informationen finden Sie unter Beschränken Sie die Anzahl von Pushs und Merges auf Branches in AWS CodeCommit.
Sie können beispielsweise eine Deny Richtlinie erstellen, die Benutzern die Möglichkeit verweigert, Änderungen an einem Branch namens main vorzunehmen, einschließlich des Löschens dieses Branches, in einem Repository mit dem Namen MyDemoRepo. Sie können diese Richtlinie zusammen mit der AWSCodeCommitPowerUserverwalteten Richtlinie verwenden. Benutzer, auf die diese beiden Richtlinien angewendet werden, könnten Branches erstellen und löschen, Pull Requests erstellen und alle anderen Aktionen ausführen AWSCodeCommitPowerUser, sofern dies von erlaubt ist. Sie könnten jedoch keine Änderungen an dem Branch mit dem Namen main übertragen, keine Datei im Hauptzweig der CodeCommit Konsole hinzufügen oder bearbeiten oder Branches oder eine Pull-Anfrage mit dem Main Branch zusammenführen. Da Deny auf GitPush angewendet wird,, müssen Sie eine Null-Anweisung in die Richtlinie aufnehmen, um die Analyse anfänglicher GitPush-Aufrufe auf Gültigkeit zu gestatten, wenn Benutzer Sendeoperationen von ihren lokalen Repositories aus ausführen.
Tipp
Wenn Sie eine Richtlinie erstellen möchten, die für alle Branches mit dem Namen main in allen Repositorys in Ihrem Amazon Web Services Services-Konto giltResource, geben Sie statt eines Repositorys ein Sternchen (*) an. ARN
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "codecommit:GitPush", "codecommit:DeleteBranch", "codecommit:PutFile", "codecommit:Merge*" ], "Resource": "arn:aws:codecommit:us-east-2:111111111111:MyDemoRepo", "Condition": { "StringEqualsIfExists": { "codecommit:References": [ "refs/heads/main" ] }, "Null": { "codecommit:References": "false" } } } ] }
Die folgende Beispielrichtlinie ermöglicht es einem Benutzer, Änderungen an einem Branch namens main in allen Repositorys eines Amazon Web Services Services-Kontos vorzunehmen. Sie erlaubt keine Änderungen an anderen Zweigen. Sie können diese Richtlinie zusammen mit der AWSCodeCommitReadOnly verwalteten Richtlinie verwenden, um automatisierte Pushs an das Repository im Hauptzweig zu ermöglichen. Da der Effekt bestehtAllow, würde diese Beispielrichtlinie nicht mit verwalteten Richtlinien wie AWSCodeCommitPowerUser funktionieren.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codecommit:GitPush", "codecommit:Merge*" ], "Resource": "*", "Condition": { "StringEqualsIfExists": { "codecommit:References": [ "refs/heads/main" ] } } } ] }
Beispiel 5: Aktionen für Repositorys mit Tags verweigern oder zulassen
Sie können eine Richtlinie erstellen, die Aktionen in Repositorys auf der Grundlage der mit diesen Repositorys verknüpften AWS Tags erlaubt oder verweigert, und diese Richtlinien dann auf die IAM Gruppen anwenden, die Sie für die Verwaltung von Benutzern konfigurieren. IAM Sie können beispielsweise eine Richtlinie erstellen, die alle CodeCommit Aktionen auf beliebigen Repositorys mit dem AWS Tag-Schlüssel Status und dem Schlüsselwert Secret verweigert, und diese Richtlinie dann auf die IAM Gruppe anwenden, die Sie für allgemeine Entwickler erstellt haben (Developers). Sie müssen dann sicherstellen, dass die Entwickler, die an diesen markierten Repositorien arbeiten, nicht Mitglieder dieses Generals sind Developers Gruppe, gehören aber stattdessen zu einer anderen IAM Gruppe, auf die die restriktive Richtlinie nicht angewendet wurde (SecretDevelopers).
Im folgenden Beispiel werden alle CodeCommit Aktionen für Repositorys verweigert, die mit dem Schlüssel Status und dem Schlüsselwert Secret gekennzeichnet sind:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "codecommit:Associate*", "codecommit:Batch*", "codecommit:CancelUploadArchive", "codecommit:CreateBranch", "codecommit:CreateCommit", "codecommit:CreatePullRequest*", "codecommit:CreateRepository", "codecommit:CreateUnreferencedMergeCommit", "codecommit:DeleteBranch", "codecommit:DeleteCommentContent", "codecommit:DeleteFile", "codecommit:DeletePullRequest*", "codecommit:DeleteRepository", "codecommit:Describe*", "codecommit:DisassociateApprovalRuleTemplateFromRepository", "codecommit:EvaluatePullRequestApprovalRules", "codecommit:GetBlob", "codecommit:GetBranch", "codecommit:GetComment*", "codecommit:GetCommit", "codecommit:GetDifferences*", "codecommit:GetFile", "codecommit:GetFolder", "codecommit:GetMerge*", "codecommit:GetObjectIdentifier", "codecommit:GetPullRequest*", "codecommit:GetReferences", "codecommit:GetRepository*", "codecommit:GetTree", "codecommit:GetUploadArchiveStatus", "codecommit:Git*", "codecommit:ListAssociatedApprovalRuleTemplatesForRepository", "codecommit:ListBranches", "codecommit:ListPullRequests", "codecommit:ListTagsForResource", "codecommit:Merge*", "codecommit:OverridePullRequestApprovalRules", "codecommit:Post*", "codecommit:Put*", "codecommit:TagResource", "codecommit:TestRepositoryTriggers", "codecommit:UntagResource", "codecommit:UpdateComment", "codecommit:UpdateDefaultBranch", "codecommit:UpdatePullRequest*", "codecommit:UpdateRepository*", "codecommit:UploadArchive" ], "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/Status": "Secret" } } } ] }
Sie können diese Strategie weiter verfeinern, indem Sie bestimmte Repositorys und nicht alle Repositorys als Ressourcen angeben. Sie können auch Richtlinien erstellen, die CodeCommit Aktionen für alle Repositorys zulassen, die nicht mit bestimmten Tags gekennzeichnet sind. Die folgende Richtlinie erlaubt beispielsweise das Äquivalent von AWSCodeCommitPowerUserBerechtigungen für CodeCommit Aktionen, mit der Ausnahme, dass sie nur Aktionen für Repositorys zulässt CodeCommit , die nicht mit den angegebenen Tags gekennzeichnet sind:
Anmerkung
Dieses Richtlinienbeispiel umfasst nur Aktionen für CodeCommit. Es umfasst keine Aktionen für andere AWS Dienste, die in der AWSCodeCommitPowerUserverwalteten Richtlinie enthalten sind. Weitere Informationen finden Sie unter AWS verwaltete Richtlinie: AWSCodeCommitPowerUser..
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codecommit:Associate*", "codecommit:Batch*", "codecommit:CancelUploadArchive", "codecommit:CreateBranch", "codecommit:CreateCommit", "codecommit:CreatePullRequest*", "codecommit:CreateRepository", "codecommit:CreateUnreferencedMergeCommit", "codecommit:DeleteBranch", "codecommit:DeleteCommentContent", "codecommit:DeleteFile", "codecommit:DeletePullRequest*", "codecommit:Describe*", "codecommit:DisassociateApprovalRuleTemplateFromRepository", "codecommit:EvaluatePullRequestApprovalRules", "codecommit:GetBlob", "codecommit:GetBranch", "codecommit:GetComment*", "codecommit:GetCommit", "codecommit:GetDifferences*", "codecommit:GetFile", "codecommit:GetFolder", "codecommit:GetMerge*", "codecommit:GetObjectIdentifier", "codecommit:GetPullRequest*", "codecommit:GetReferences", "codecommit:GetRepository*", "codecommit:GetTree", "codecommit:GetUploadArchiveStatus", "codecommit:Git*", "codecommit:ListAssociatedApprovalRuleTemplatesForRepository", "codecommit:ListBranches", "codecommit:ListPullRequests", "codecommit:ListTagsForResource", "codecommit:Merge*", "codecommit:OverridePullRequestApprovalRules", "codecommit:Post*", "codecommit:Put*", "codecommit:TagResource", "codecommit:TestRepositoryTriggers", "codecommit:UntagResource", "codecommit:UpdateComment", "codecommit:UpdateDefaultBranch", "codecommit:UpdatePullRequest*", "codecommit:UpdateRepository*", "codecommit:UploadArchive" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:ResourceTag/Status": "Secret", "aws:ResourceTag/Team": "Saanvi" } } }, { "Effect": "Allow", "Action": [ "codecommit:CreateApprovalRuleTemplate", "codecommit:GetApprovalRuleTemplate", "codecommit:ListApprovalRuleTemplates", "codecommit:ListRepositories", "codecommit:ListRepositoriesForApprovalRuleTemplate", "codecommit:UpdateApprovalRuleTemplateContent", "codecommit:UpdateApprovalRuleTemplateDescription", "codecommit:UpdateApprovalRuleTemplateName" ], "Resource": "*" } ] }
Beispiele für vom Kunden verwaltete Integrationsrichtlinien
Dieser Abschnitt enthält Beispiele für vom Kunden verwaltete Benutzerrichtlinien, die Berechtigungen für Integrationen zwischen CodeCommit und anderen AWS Diensten gewähren. Konkrete Beispiele für Richtlinien, die kontoübergreifenden Zugriff auf ein CodeCommit Repository ermöglichen, finden Sie unter. Konfiguriere den kontoübergreifenden Zugriff auf ein AWS CodeCommit Repository mithilfe von Rollen
Anmerkung
Alle Beispiele verwenden die Region USA West (Oregon) (us-west-2), wenn ein erforderlich AWS-Region ist, und enthalten ein fiktives Konto. IDs
Beispiele
Beispiel 1: Erstellen Sie eine Richtlinie, die den kontoübergreifenden Zugriff auf ein SNS Amazon-Thema ermöglicht
Sie können ein CodeCommit Repository so konfigurieren, dass Code-Pushs oder andere Ereignisse Aktionen auslösen, z. B. das Senden einer Benachrichtigung von Amazon Simple Notification Service (AmazonSNS). Wenn Sie das SNS Amazon-Thema mit demselben Konto erstellen, mit dem Sie das CodeCommit Repository erstellt haben, müssen Sie keine zusätzlichen IAM Richtlinien oder Berechtigungen konfigurieren. Sie können das Thema und dann den Auslöser für das Repository erstellen. Weitere Informationen finden Sie unter Einen Auslöser für ein SNS Amazon-Thema erstellen.
Wenn Sie Ihren Auslöser jedoch so konfigurieren möchten, dass er ein SNS Amazon-Thema in einem anderen Amazon Web Services-Konto verwendet, müssen Sie dieses Thema zunächst mit einer Richtlinie konfigurieren, die es ermöglicht, CodeCommit zu diesem Thema zu veröffentlichen. Öffnen Sie von diesem anderen Konto aus die SNS Amazon-Konsole, wählen Sie das Thema aus der Liste aus und wählen Sie für Andere Themenaktionen die Option Themenrichtlinie bearbeiten aus. Ändern Sie auf der Registerkarte „Erweitert“ die Richtlinie für das Thema, sodass es CodeCommit zu diesem Thema veröffentlicht werden kann. Wenn es sich bei der Richtlinie beispielsweise um die Standardrichtlinie handelt, würden Sie die Richtlinie wie folgt ändern und dabei die Elemente in ändern red italic text um die Werte für Ihr Repository, Ihr SNS Amazon-Thema und Ihr Konto abzugleichen:
{ "Version": "2008-10-17", "Id": "__default_policy_ID", "Statement": [ { "Sid": "__default_statement_ID", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "sns:Subscribe", "sns:ListSubscriptionsByTopic", "sns:DeleteTopic", "sns:GetTopicAttributes", "sns:Publish", "sns:RemovePermission", "sns:AddPermission", "sns:SetTopicAttributes" ], "Resource": "arn:aws:sns:us-east-2:111111111111:NotMySNSTopic", "Condition": { "StringEquals": { "AWS:SourceOwner": "111111111111" } } }, { "Sid": "CodeCommit-Policy_ID", "Effect": "Allow", "Principal": { "Service": "codecommit.amazonaws.com" }, "Action": "sns:Publish", "Resource": "arn:aws:sns:us-east-2:111111111111:NotMySNSTopic", "Condition": { "StringEquals": { "AWS:SourceArn": "arn:aws:codecommit:us-east-2:111111111111:MyDemoRepo", "AWS:SourceAccount": "111111111111" } } } ] }
Beispiel 2: Erstellen Sie eine Amazon Simple Notification Service (AmazonSNS) -Themenrichtlinie, damit Amazon CloudWatch Events CodeCommit Ereignisse zu diesem Thema veröffentlichen kann
Sie können CloudWatch Ereignisse so konfigurieren, dass sie bei Eintreten von Ereignissen, einschließlich CodeCommit Ereignissen, in einem SNS Amazon-Thema veröffentlicht werden. Dazu müssen Sie sicherstellen, dass CloudWatch Events berechtigt ist, Ereignisse zu Ihrem SNS Amazon-Thema zu veröffentlichen, indem Sie eine Richtlinie für das Thema erstellen oder eine bestehende Richtlinie für das Thema ändern, die der folgenden ähnelt:
{ "Version": "2008-10-17", "Id": "__default_policy_ID", "Statement": [ { "Sid": "__default_statement_ID", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "sns:Publish", "Resource": "arn:aws:sns:us-east-2:123456789012:MyTopic", "Condition": { "StringEquals": { "AWS:SourceOwner": "123456789012" } } }, { "Sid": "Allow_Publish_Events", "Effect": "Allow", "Principal": { "Service": "events.amazonaws.com" }, "Action": "sns:Publish", "Resource": "arn:aws:sns:us-east-2:123456789012:MyTopic" } ] }
Weitere Informationen zu CloudWatch Veranstaltungen CodeCommit und Veranstaltungen finden Sie unter Beispiele für CloudWatch Veranstaltungen unter Unterstützte Dienste. Weitere Informationen zu IAM und zur Sprache der Richtlinien finden Sie unter Grammatik der IAM JSON Richtliniensprache.
Beispiel 3: Erstellen Sie eine Richtlinie für die AWS Lambda Integration mit einem CodeCommit Trigger
Sie können ein CodeCommit Repository so konfigurieren, dass Code-Pushs oder andere Ereignisse Aktionen auslösen, z. B. das Aufrufen einer Funktion in. AWS Lambda Weitere Informationen finden Sie unter Erstellen Sie einen Trigger für eine Lambda-Funktion. Diese Informationen beziehen sich nur auf Trigger und nicht CloudWatch auf Ereignisse.
Wenn Sie möchten, dass Ihr Trigger eine Lambda-Funktion direkt ausführt (anstatt ein SNS Amazon-Thema zum Aufrufen der Lambda-Funktion zu verwenden) und Sie den Trigger nicht in der Lambda-Konsole konfigurieren, müssen Sie eine Anweisung ähnlich der folgenden in die ressourcenbasierte Richtlinie der Funktion aufnehmen:
{ "Statement":{ "StatementId":"Id-1", "Action":"lambda:InvokeFunction", "Principal":"codecommit.amazonaws.com", "SourceArn":"arn:aws:codecommit:us-east-2:111111111111:MyDemoRepo", "SourceAccount":"111111111111" } }
Wenn Sie einen CodeCommit Trigger manuell konfigurieren, der eine Lambda-Funktion aufruft, müssen Sie auch den AddPermissionLambda-Befehl verwenden, um die Erlaubnis zum Aufrufen der Funktion CodeCommit zu erteilen. Ein Beispiel finden Sie im Abschnitt Um die Ausführung einer Lambda-Funktion CodeCommit zu ermöglichen von Einen Trigger für eine bestehende Lambda-Funktion erstellen.
Weitere Informationen zu Ressourcenrichtlinien für Lambda-Funktionen finden Sie unter AddPermissionund The Pull/Push Event Models im AWS Lambda Developer Guide.
