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.
Referenz zum Integrationsmodell
Es gibt mehrere vorgefertigte Integrationen für Dienste von Drittanbietern, mit deren Hilfe bestehende Kundentools in den Pipeline-Release-Prozess integriert werden können. Partner oder Drittanbieter verwenden ein Integrationsmodell, um Aktionstypen für den Einsatz in zu implementieren. CodePipeline
Verwenden Sie diese Referenz, wenn Sie Aktionstypen planen oder damit arbeiten, die mit einem unterstützten Integrationsmodell verwaltet werden CodePipeline.
Um Ihren Aktionstyp eines Drittanbieters als Partnerintegration mit zu zertifizieren CodePipeline, verweisen Sie auf das AWS Partnernetzwerk (APN). Diese Informationen stellen eine Ergänzung zur AWS CLI Referenz dar.
Themen
So funktionieren Aktionstypen von Drittanbietern mit dem Integrator
Sie können Aktionstypen von Drittanbietern zu Kunden-Pipelines hinzufügen, um Aufgaben im Zusammenhang mit Kundenressourcen zu erledigen. Der Integrator verwaltet Jobanfragen und führt die Aktion mit aus. CodePipeline Das folgende Diagramm zeigt einen Aktionstyp eines Drittanbieters, der für Kunden zur Verwendung in ihrer Pipeline erstellt wurde. Nachdem der Kunde die Aktion konfiguriert hat, wird die Aktion ausgeführt und es werden Jobanfragen erstellt, die von der Action Engine des Integrators bearbeitet werden.
Das Diagramm zeigt die folgenden Schritte:
-
Die Aktionsdefinition wird registriert und in verfügbar gemacht CodePipeline. Die Drittanbieter-Aktion ist für Kunden des Drittanbieters verfügbar.
-
Der Kunde des Anbieters wählt und konfiguriert die Aktion in CodePipeline.
-
Die Aktion wird ausgeführt und Jobs werden in die Warteschlange gestellt. CodePipeline Wenn der Job bereit ist CodePipeline, sendet er eine Job-Anfrage.
-
Der Integrator (der Job Worker für Drittanbieterabfragen APIs oder die Lambda-Funktion) nimmt die Jobanfrage entgegen, gibt eine Bestätigung zurück und bearbeitet die Artefakte für die Aktionen.
-
Der Integrator gibt Erfolg/Misserfolge-Ausgabe (der Job-Worker verwendet Erfolg/Misserfolg APIs oder die Lambda-Funktion sendet Erfolgs-/Fehlschlagsausgabe) mit einem Job-Ergebnis und einem Fortsetzungstoken zurück.
Informationen zu den Schritten, mit denen Sie einen Aktionstyp anfordern, anzeigen und aktualisieren können, finden Sie unter. Mit Aktionstypen arbeiten
Konzepte
In diesem Abschnitt werden die folgenden Begriffe für Aktionstypen von Drittanbietern verwendet:
- Aktionstyp
-
Ein wiederholbarer Prozess, der in Pipelines wiederverwendet werden kann, die dieselben Continuous Delivery-Workloads ausführen. Aktionstypen werden durch ein
Owner
,,Category
und identifiziert.Provider
Version
Beispielsweise:{ "Category": "Deploy", "Owner": "AWS", "Provider": "CodeDeploy", "Version": "1" },
Alle Aktionen desselben Typs haben dieselbe Implementierung.
- Aktion
-
Eine einzelne Instanz eines Aktionstyps, einer der diskreten Prozesse, die innerhalb einer Phase einer Pipeline ablaufen. Dazu gehören in der Regel die Benutzerwerte, die für die Pipeline spezifisch sind, in der diese Aktion ausgeführt wird.
- Definition der Aktion
-
Das Schema für einen Aktionstyp, das die Eigenschaften definiert, die für die Konfiguration der Aktion und der Eingabe-/Ausgabeartefakte erforderlich sind.
- Aktionsausführung
-
Eine Sammlung von Aufträgen, die ausgeführt wurden, um festzustellen, ob die Aktion in der Pipeline des Kunden erfolgreich war oder nicht.
- Engine zur Ausführung von Aktionen
-
Eine Eigenschaft der Konfiguration zur Aktionsausführung, die den Integrationstyp definiert, der von einem Aktionstyp verwendet wird. Gültige Werte sind
JobWorker
undLambda
. - Integration
-
Beschreibt eine Software, die von einem Integrator ausgeführt wird, um einen Aktionstyp zu implementieren. CodePipeline unterstützt zwei Integrationstypen, die den beiden unterstützten Action Engines
JobWorker
undLambda
entsprechen. - Integrator
-
Die Person, der die Implementierung eines Aktionstyps gehört.
- Aufgabe
-
Eine Arbeit mit Pipeline und Kundenkontext zur Ausführung einer Integration. Eine Aktionsausführung besteht aus einem oder mehreren Jobs.
- Arbeitsnehmer
-
Der Dienst, der die Kundeneingaben verarbeitet und einen Job ausführt.
Unterstützte Integrationsmodelle
CodePipeline hat zwei Integrationsmodelle:
-
Lambda-Integrationsmodell: Dieses Integrationsmodell ist die bevorzugte Methode, um mit Aktionstypen in CodePipeline zu arbeiten. Das Lambda-Integrationsmodell verwendet eine Lambda-Funktion, um Jobanfragen zu verarbeiten, wenn Ihre Aktion ausgeführt wird.
-
Integrationsmodell für Job Worker: Das Job Worker-Integrationsmodell ist das bisher verwendete Modell für Integrationen von Drittanbietern. Das Job-Worker-Integrationsmodell verwendet einen Job Worker, der so konfiguriert ist, dass er den kontaktiert CodePipeline APIs, um Jobanfragen zu bearbeiten, wenn Ihre Aktion ausgeführt wird.
Zum Vergleich werden in der folgenden Tabelle die Funktionen der beiden Modelle beschrieben:
Lambda-Integrationsmodell | Modell zur Eingliederung von Arbeitern | |
---|---|---|
Beschreibung | Der Integrator schreibt die Integration als Lambda-Funktion, die immer dann aufgerufen wird, CodePipeline wenn ein Job für die Aktion verfügbar ist. Die Lambda-Funktion fragt nicht nach verfügbaren Jobs ab, sondern wartet, bis die nächste Jobanfrage eingeht. | Der Integrator schreibt die Integration als Job Worker, der ständig nach verfügbaren Jobs in den Pipelines des Kunden sucht. Der Jobworker führt dann den Job aus und sendet das Auftragsergebnis zurück an by using. CodePipeline CodePipeline APIs |
Infrastruktur | AWS Lambda | Stellen Sie Job Worker-Code in der Infrastruktur des Integrators bereit, z. B. in EC2 Amazon-Instances. |
Entwicklungsanstrengungen | Die Integration beinhaltet nur die Geschäftslogik. | Die Integration muss nicht nur mit CodePipeline APIs der Geschäftslogik interagieren, sondern auch mit ihr interagieren. |
Aufwand der Operation | Geringerer operativer Aufwand, da es sich bei der Infrastruktur nur AWS um Ressourcen handelt. | Höherer operativer Aufwand, da der Arbeitsarbeiter seine eigenständige Hardware benötigt. |
Max. Job-Laufzeit | Wenn die Integration länger als 15 Minuten aktiv ausgeführt werden muss, kann dieses Modell nicht verwendet werden. Diese Aktion richtet sich an Integratoren, die einen Prozess starten (z. B. einen Build auf dem Code-Artefakt des Kunden initiieren) und nach Abschluss ein Ergebnis zurückgeben müssen. Es wird nicht empfohlen, dass der Integrator weiterhin darauf wartet, dass der Build abgeschlossen ist. Geben Sie stattdessen eine Fortsetzung zurück. CodePipelineerstellt in weiteren 30 Sekunden einen neuen Job, wenn eine Fortsetzung vom Code des Integrators empfangen wird, der den Job überprüft, bis er abgeschlossen ist. | Mit diesem Modell können Aufträge mit sehr langer Laufzeit (Stunden/Tage) aufrechterhalten werden. |
Lambda-Integrationsmodell
Das unterstützte Lambda-Integrationsmodell umfasst die Erstellung der Lambda-Funktion und die Definition der Ausgabe für den Aktionstyp eines Drittanbieters.
Aktualisieren Sie Ihre Lambda-Funktion, um die Eingabe von zu verarbeiten CodePipeline
Sie können eine neue Lambda-Funktion erstellen. Sie können Ihrer Lambda-Funktion Geschäftslogik hinzufügen, die immer dann ausgeführt wird, wenn in Ihrer Pipeline ein Job für Ihren Aktionstyp verfügbar ist. Wenn Sie beispielsweise den Kontext des Kunden und der Pipeline berücksichtigen, möchten Sie vielleicht einen Build in Ihrem Service für den Kunden starten.
Verwenden Sie die folgenden Parameter, um Ihre Lambda-Funktion so zu aktualisieren, dass sie die Eingabe von CodePipeline verarbeitet.
Format:
-
jobId
:-
Die eindeutige, vom System generierte ID des Jobs.
-
Typ: Zeichenfolge
-
Muster: [0-9a-f] {8} - [0-9a-f] {4} - [0-9a-f] {4} - [0-9a-f] {4} - [0-9a-f] {12}
-
-
accountId
:-
Die ID des AWS Kundenkontos, das bei der Ausführung des Auftrags verwendet werden soll.
-
Typ: Zeichenfolge
-
Muster: [0-9] {12}
-
-
data
:-
Andere Informationen über einen Job, die von einer Integration verwendet werden, um den Job abzuschließen.
-
Enthält eine Übersicht der folgenden Elemente:
-
actionConfiguration
:-
Die Konfigurationsdaten für die Aktion. Die Felder für die Aktionskonfiguration sind eine Zuordnung von Schlüssel-Wert-Paaren, sodass Ihr Kunde Werte eingeben kann. Die Schlüssel werden durch die Schlüsselparameter in der Aktionstyp-Definitionsdatei bestimmt, wenn Sie Ihre Aktion einrichten. In diesem Beispiel werden die Werte vom Benutzer der Aktion bestimmt, der Informationen in den
Password
FeldernUsername
und angibt. -
Typ: Zuordnung von Zeichenfolge zu Zeichenfolge, optional vorhanden
Beispiel:
"configuration": { "Username": "MyUser", "Password": "MyPassword" },
-
-
encryptionKey
:-
Stellt Informationen über den Schlüssel dar, der zum Verschlüsseln von Daten im Artefaktspeicher verwendet wird, z. B. einen AWS KMS Schlüssel.
-
Inhalt: Typ des Datentyps
encryptionKey
, optional vorhanden
-
-
inputArtifacts
:-
Liste mit Informationen über ein Artefakt, an dem gearbeitet werden soll, z. B. ein Test- oder Build-Artefakt.
-
Inhalt: Liste des Datentyps
Artifact
, optional vorhanden
-
-
outputArtifacts
:-
Liste mit Informationen über die Ausgabe einer Aktion.
-
Inhalt: Liste des Datentyps
Artifact
, optional vorhanden
-
-
actionCredentials
:-
Stellt ein Objekt mit AWS Sitzungsanmeldedaten dar. Bei diesen Anmeldeinformationen handelt es sich um temporäre Anmeldeinformationen, die von ausgestellt werden AWS STS. Sie können verwendet werden, um auf Eingabe- und Ausgabeartefakte im S3-Bucket zuzugreifen, in dem Artefakte für die Pipeline gespeichert werden CodePipeline.
Diese Anmeldeinformationen haben auch dieselben Berechtigungen wie die angegebene Vorlage für Richtlinienerklärungen in der Aktionstyp-Definitionsdatei.
-
Inhalt: Typ des Datentyps
AWSSessionCredentials
, optional vorhanden
-
-
actionExecutionId
:-
Die externe ID der Ausführung der Aktion.
-
Typ: Zeichenfolge
-
-
continuationToken
:-
Ein vom System generiertes Token, z. B. eine Bereitstellungs-ID, das von einem Job benötigt wird, um den Job asynchron fortzusetzen.
-
Typ: Zeichenfolge, optional vorhanden
-
-
-
Datentypen:
-
encryptionKey
:-
id
:-
Die ID, die verwendet wurde, um den Schlüssel zu identifizieren. Für einen AWS KMS Schlüssel können Sie die Schlüssel-ID, den Schlüssel ARN oder den Alias verwendenARN.
-
Typ: Zeichenfolge
-
-
type
:-
Der Typ des Verschlüsselungsschlüssels, z. B. ein AWS KMS Schlüssel.
-
Typ: Zeichenfolge
-
Zulässige Werte:
KMS
-
-
-
Artifact
:-
name
:-
Der Name des Artefakts.
-
Typ: Zeichenfolge, optional vorhanden
-
-
revision
:-
Die Revisions-ID des Artefakts. Je nach Objekttyp kann dies eine Commit-ID (GitHub) oder eine Revision-ID (Amazon S3) sein.
-
Typ: Zeichenfolge, optional vorhanden
-
-
location
:-
Der Standort eines Artefakts.
-
Inhalt: Typ des Datentyps
ArtifactLocation
, optional vorhanden
-
-
-
ArtifactLocation
:-
type
:-
Der Typ des Artefakts am Standort.
-
Typ: Zeichenfolge, optional vorhanden
-
Zulässige Werte:
S3
-
-
s3Location
:-
Der Speicherort des S3-Buckets, der eine Revision enthält.
-
Inhalt: Typ des Datentyps
S3Location
, optional vorhanden
-
-
-
S3Location
:-
bucketName
:-
Der Name des S3-Buckets.
-
Typ: Zeichenfolge
-
-
objectKey
:-
Der Schlüssel des Objekts im S3-Bucket, der das Objekt im Bucket eindeutig identifiziert.
-
Typ: Zeichenfolge
-
-
-
AWSSessionCredentials
:-
accessKeyId
:-
Der Zugriffsschlüssel für die Sitzung.
-
Typ: Zeichenfolge
-
-
secretAccessKey
:-
Der geheime Zugriffsschlüssel für die Sitzung.
-
Typ: Zeichenfolge
-
-
sessionToken
:-
Das Token für die Sitzung.
-
Typ: Zeichenfolge
-
-
Beispiel:
{ "jobId": "
01234567-abcd-abcd-abcd-012345678910
", "accountId": "012345678910
", "data": { "actionConfiguration": { "key1": "value1
", "key2": "value2
" }, "encryptionKey": { "id": "123-abc
", "type": "KMS
" }, "inputArtifacts": [ { "name": "input-art-name
", "location": { "type": "S3
", "s3Location": { "bucketName": "inputBucket
", "objectKey": "inputKey
" } } } ], "outputArtifacts": [ { "name": "output-art-name
", "location": { "type": "S3
", "s3Location": { "bucketName": "outputBucket
", "objectKey": "outputKey
" } } } ], "actionExecutionId": "actionExecutionId
", "actionCredentials": { "accessKeyId": "access-id
", "secretAccessKey": "secret-id
", "sessionToken": "session-id
" }, "continuationToken": "continueId-xxyyzz
" } }
Geben Sie die Ergebnisse Ihrer Lambda-Funktion zurück an CodePipeline
Die Job-Worker-Ressource des Integrators muss bei Erfolg, Misserfolg oder Fortführung eine gültige Nutzlast zurückgeben.
Format:
-
result
: Das Ergebnis des Jobs.-
Erforderlich
-
Gültige Werte (Groß- und Kleinschreibung wird nicht beachtet):
-
Success
: Zeigt an, dass ein Job erfolgreich und terminal ist. -
Continue
: Zeigt an, dass ein Job erfolgreich ist und fortgesetzt werden muss, z. B. wenn der Job-Worker für dieselbe Aktionsausführung erneut aufgerufen wird. -
Fail
: Zeigt an, dass ein Job fehlgeschlagen ist und es sich um ein Terminal handelt.
-
-
-
failureType
: Ein Fehlertyp, der einem fehlgeschlagenen Job zugeordnet werden soll.Die
failureType
Kategorie für Partneraktionen beschreibt die Art des Fehlers, der bei der Ausführung des Jobs aufgetreten ist. Integratoren legen den Typ zusammen mit der Fehlermeldung fest, wenn das Ergebnis eines Auftragsfehlers zurückgegeben wird. CodePipeline-
Optional. Erforderlich, wenn das Ergebnis ist
Fail
. -
Muss Null sein, wenn
result
istSuccess
oderContinue
-
Zulässige Werte:
-
ConfigurationError
-
JobFailed
-
PermissionsError
-
RevisionOutOfSync
-
RevisionUnavailable
-
SystemUnavailable
-
-
-
continuation
: Fortsetzungsstatus, der an den nächsten Job innerhalb der aktuellen Aktionsausführung übergeben werden soll.-
Optional. Erforderlich, wenn das Ergebnis ist
Continue
. -
Muss Null sein, wenn
result
esSuccess
oder istFail
. -
Eigenschaften:
-
State
: Ein Hash des Status, der übergeben werden soll.
-
-
-
status
: Status der Ausführung der Aktion.-
Optional.
-
Eigenschaften:
-
ExternalExecutionId
: Eine optionale externe Ausführungs- oder Commit-ID, die dem Job zugeordnet werden soll. -
Summary
: Eine optionale Zusammenfassung dessen, was passiert ist. In Ausfallszenarien wird dies zur Fehlermeldung, die dem Benutzer angezeigt wird.
-
-
-
outputVariables
: Eine Reihe von Schlüssel/Wert-Paaren, die an die nächste Aktionsausführung übergeben werden.-
Optional.
-
Muss Null sein, wenn es oder
result
istContinue
.Fail
-
Beispiel:
{ "result":
"success"
, "failureType": null, "continuation": null, "status": { "externalExecutionId":"my-commit-id-123"
, "summary":"everything is dandy"
}, "outputVariables": { "FirstOne":"Nice"
, "SecondOne":"Nicest"
, ... } }
Verwenden Sie Fortsetzungstoken, um auf Ergebnisse eines asynchronen Prozesses zu warten
Das continuation
Token ist Teil der Nutzlast und das Ergebnis Ihrer Lambda-Funktion. Es ist eine Möglichkeit, den Status eines Jobs zu übergeben CodePipeline und darauf hinzuweisen, dass der Job fortgesetzt werden muss. Wenn ein Integrator beispielsweise einen Build für den Kunden auf seiner Ressource gestartet hat, wartet er nicht darauf, dass der Build abgeschlossen ist, sondern signalisiert, CodePipeline dass er kein Endergebnis hat, indem er das result
as zurückgibt continue
und die eindeutige ID des Builds an das CodePipeline continuation
as-Token zurückgibt.
Anmerkung
Lambda-Funktionen können nur bis zu 15 Minuten ausgeführt werden. Wenn der Job länger ausgeführt werden muss, können Sie Fortsetzungstoken verwenden.
Das CodePipeline Team ruft den Integrator nach 30 Sekunden mit demselben continuation
Token in seiner Payload auf, sodass es überprüfen kann, ob er abgeschlossen ist. Wenn der Build abgeschlossen ist, gibt der Integrator das Terminal-Erfolg/Fehlschlagen zurück, andernfalls fährt er fort.
Stellen Sie CodePipeline die Berechtigungen bereit, um die Lambda-Funktion des Integrators zur Laufzeit aufzurufen
Sie fügen Ihrer Integrator-Lambda-Funktion Berechtigungen hinzu, um dem CodePipeline Dienst Berechtigungen zu geben, ihn mithilfe des CodePipeline Dienstprinzipals aufzurufen:. codepipeline.amazonaws.com
Sie können Berechtigungen mithilfe AWS CloudFormation oder der Befehlszeile hinzufügen. Ein Beispiel finden Sie unter Mit Aktionstypen arbeiten.
Modell zur Eingliederung von Arbeitern
Nachdem Sie Ihren allgemeinen Arbeitsablauf entworfen haben, können Sie Ihren Job Worker erstellen. Die Besonderheiten der Drittanbieter-Aktion bestimmen zwar, was für den Job Worker benötigt wird, aber die meisten Job Worker für Drittanbieter-Aktionen verfügen über die folgenden Funktionen:
-
Abfrage von Aufträgen aus der Verwendung von CodePipeline .
PollForThirdPartyJobs
-
Bestätigen von Aufträgen und Rückgabe von Ergebnissen bei CodePipeline Verwendung von
AcknowledgeThirdPartyJob
,PutThirdPartyJobSuccessResult
, und.PutThirdPartyJobFailureResult
-
Artefakte werden aus dem Amazon S3-Bucket abgerufen und/oder in den Amazon S3 S3-Bucket für die Pipeline gelegt. Um Artefakte aus dem Amazon S3 S3-Bucket herunterzuladen, müssen Sie einen Amazon S3 S3-Client erstellen, der Signature Version 4-Signatur (Sig V4) verwendet. Sig V4 ist erforderlich für AWS KMS.
Um Artefakte in den Amazon S3 S3-Bucket hochzuladen, müssen Sie auch die Amazon S3
PutObject
S3-Anfrage so konfigurieren, dass sie Verschlüsselung durch AWS Key Management Service (AWS KMS) verwendet. AWS KMS verwendet AWS KMS keys. Um zu wissen, ob der Von AWS verwalteter Schlüssel oder ein vom Kunden verwalteter Schlüssel zum Hochladen von Artefakten verwendet werden soll, muss sich Ihr Auftragsmitarbeiter die Auftragsdaten ansehen und die Eigenschaft des Verschlüsselungsschlüssels überprüfen. Wenn die Eigenschaft festgelegt ist, sollten Sie bei der Konfiguration diese vom Kunden verwaltete Schlüssel-ID verwenden AWS KMS. Wenn die Schlüsseleigenschaft Null ist, verwenden Sie die Von AWS verwalteter Schlüssel. CodePipeline verwendet die, Von AWS verwalteter Schlüssel sofern nicht anders konfiguriert.Für ein Beispiel, das zeigt, wie die AWS KMS Parameter in Java erstellt werden oder. NET, siehe Spezifizieren von AWS Key Management Service in Amazon S3 mithilfe von AWS SDKs. Weitere Informationen zum Amazon S3 S3-Bucket für CodePipeline finden Sie unterCodePipeline Konzepte .
Wählen und Konfigurieren einer Strategie für die Berechtigungsverwaltung Ihres Auftragsworkers
Um einen Job Worker für Ihre Drittanbieter-Aktion zu entwickeln CodePipeline, benötigen Sie eine Strategie für die Integration von Benutzer- und Rechteverwaltung.
Die einfachste Strategie besteht darin, die Infrastruktur, die Sie für Ihren Job Worker benötigen, hinzuzufügen, indem Sie EC2 Amazon-Instances mit einer Instance-Rolle AWS Identity and Access Management (IAM) erstellen, sodass Sie die Ressourcen, die Sie für Ihre Integration benötigen, problemlos skalieren können. Sie können die integrierte Integration mit verwenden AWS , um die Interaktion zwischen Ihrem Jobarbeiter und zu vereinfachen CodePipeline.
Erfahren Sie mehr über Amazon EC2 und finden Sie heraus, ob es die richtige Wahl für Ihre Integration ist. Weitere Informationen finden Sie unter Amazon EC2 — Virtual Server Hosting
Eine weitere Strategie, die Sie in Betracht ziehen sollten, ist der Einsatz von Identity Federation IAM zur Integration Ihres vorhandenen Identitätsanbietersystems und Ihrer Ressourcen. Diese Strategie ist nützlich, wenn Sie bereits über einen Corporate Identity Provider verfügen oder bereits so konfiguriert sind, dass Benutzer, die Web-Identitätsanbieter verwenden, unterstützt werden. Mithilfe eines Identitätsverbunds können Sie sicheren Zugriff auf AWS Ressourcen gewähren CodePipeline, auch ohne IAM Benutzer erstellen oder verwalten zu müssen. Sie können Funktionen und Richtlinien für die Sicherheitsanforderungen bezüglich Passwörtern und die Rotation von Anmeldeinformationen nutzen. Sie können Beispielanwendungen als Vorlage für Ihre selbsterstellten Anwendungen verwenden. Weitere Informationen finden Sie unter Manage Federation
Um Zugriff zu gewähren, fügen Sie Ihren Benutzern, Gruppen oder Rollen Berechtigungen hinzu:
-
Benutzer und Gruppen in AWS IAM Identity Center:
Erstellen Sie einen Berechtigungssatz. Befolgen Sie die Anweisungen unter Erstellen eines Berechtigungssatzes im AWS IAM Identity Center -Benutzerhandbuch.
-
Benutzer, IAM die über einen Identitätsanbieter verwaltet werden:
Erstellen Sie eine Rolle für den Identitätsverbund. Folgen Sie den Anweisungen unter Erstellen einer Rolle für einen externen Identitätsanbieter (Federation) im IAMBenutzerhandbuch.
-
IAMBenutzer:
-
Erstellen Sie eine Rolle, die Ihr Benutzer annehmen kann. Folgen Sie den Anweisungen unter Eine Rolle für einen IAM Benutzer erstellen im IAMBenutzerhandbuch.
-
(Nicht empfohlen) Weisen Sie einem Benutzer eine Richtlinie direkt zu oder fügen Sie einen Benutzer zu einer Benutzergruppe hinzu. Folgen Sie den Anweisungen unter Hinzufügen von Berechtigungen für einen Benutzer (Konsole) im IAMBenutzerhandbuch.
-
Im Folgenden finden Sie ein Beispiel für eine Richtlinie, die Sie für die Verwendung mit Ihrem Job Worker eines Drittanbieters erstellen könnten. Diese Richtlinie dient lediglich als Beispiel und wird unverändert bereitgestellt.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:PollForThirdPartyJobs", "codepipeline:AcknowledgeThirdPartyJob", "codepipeline:GetThirdPartyJobDetails", "codepipeline:PutThirdPartyJobSuccessResult", "codepipeline:PutThirdPartyJobFailureResult" ], "Resource": [ "arn:aws:codepipeline:
us-east-2
::actionType:ThirdParty/Build/Provider
/1/" ] } ] }