Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Par défaut, les utilisateurs et les rôles IAM ne sont pas autorisés à créer ou modifier les ressources CodePipeline . Ils ne peuvent pas non plus effectuer de tâches à l'aide de l' AWS API AWS Management Console AWS CLI, ou. Un administrateur IAM doit créer des politiques IAM autorisant les utilisateurs et les rôles à exécuter des opérations d'API spécifiques sur les ressources spécifiées dont ils ont besoin. Il doit ensuite attacher ces politiques aux utilisateurs ou aux groupes IAM ayant besoin de ces autorisations.
Pour savoir comment créer une stratégie IAM basée sur l'identité à l'aide de ces exemples de documents de stratégie JSON, veuillez consulter Création de stratégies dans l'onglet JSON dans le Guide de l'utilisateur IAM.
Pour savoir comment créer un pipeline qui utilise les ressources d'un autre compte, et pour obtenir des exemples de politiques connexes, consultezCréez un pipeline CodePipeline qui utilise les ressources d'un autre AWS compte.
Rubriques
Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations
Utilisation de balises pour contrôler l'accès aux ressources CodePipeline
Autorisations requises pour utiliser la console CodePipeline
Autorisations requises pour consulter les journaux de calcul dans la CodePipeline console
Exemples de politiques gérées par le client
Dans cette section, vous trouverez des exemples de politiques utilisateur qui accordent des autorisations pour diverses CodePipeline actions. Ces politiques fonctionnent lorsque vous utilisez l' CodePipeline API AWS SDKs, ou le AWS CLI. Lorsque vous utilisez la console, vous devez accorder des autorisations supplémentaires spécifiques à la console. Pour de plus amples informations, veuillez consulter Autorisations requises pour utiliser la console CodePipeline .
Note
Tous les exemples utilisent la région de l'Ouest des États-Unis (Oregon) (us-west-2) et contiennent un récit fictif. IDs
Exemples
-
Exemple 1 : Octroi d'autorisations pour obtenir l'état d'un pipeline
-
Exemple 2 : Octroi d'autorisations pour activer et désactiver les transitions entre les étapes
-
Exemple 3 : Octroi d'autorisations pour obtenir la liste de tous les types d'action disponibles
-
Exemple 4 : Octroi d'autorisations pour approuver ou rejeter des actions d'approbation manuelle
-
Exemple 5 : Octroi d'autorisations pour interroger les tâches d'une action personnalisée
-
Exemple 6 : joindre ou modifier une politique pour l'intégration de Jenkins avec AWS CodePipeline
-
Exemple 7 : Configuration d'un accès entre comptes à un pipeline
-
Exemple 8 : Utilisation de ressources AWS associées à un autre compte dans un pipeline
Exemple 1 : Octroi d'autorisations pour obtenir l'état d'un pipeline
L'exemple suivant accorde des autorisations pour obtenir l'état du pipeline nommé MyFirstPipeline :
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:GetPipelineState"
],
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline"
}
]
}Exemple 2 : Octroi d'autorisations pour activer et désactiver les transitions entre les étapes
L'exemple suivant accorde des autorisations pour activer et désactiver les transitions entre toutes les étapes du pipeline nommé MyFirstPipeline :
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:DisableStageTransition",
"codepipeline:EnableStageTransition"
],
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/*"
}
]
}Pour permettre à l'utilisateur d'activer et de désactiver les transitions pour une seule étape d'un pipeline, vous devez spécifier l'étape. Par exemple, pour permettre à l'utilisateur d'activer et de désactiver les transitions pour une étape nommée Staging d'un pipeline nommé MyFirstPipeline :
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/Staging"Exemple 3 : Octroi d'autorisations pour obtenir la liste de tous les types d'action disponibles
L'exemple suivant accorde les autorisations nécessaires pour obtenir une liste de tous les types d'action disponibles pour les pipelines dans la région us-west-2 :
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:ListActionTypes"
],
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:actiontype:*"
}
]
}Exemple 4 : Octroi d'autorisations pour approuver ou rejeter des actions d'approbation manuelle
L'exemple suivant accorde les autorisations nécessaires pour approuver ou rejeter des actions d'approbation manuelle lors d'une étape nommée Staging dans un pipeline nommé MyFirstPipeline :
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:PutApprovalResult"
],
"Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/Staging/*"
}
]
}Exemple 5 : Octroi d'autorisations pour interroger les tâches d'une action personnalisée
L'exemple suivant accorde les autorisations nécessaires pour rechercher, dans tous les pipelines, les tâches de l'action personnalisée nommée TestProvider, qui est une action de type Test dans sa première version :
Note
Le job worker chargé d'une action personnalisée peut être configuré sous un autre AWS compte ou nécessiter un rôle IAM spécifique pour fonctionner.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "codepipeline:PollForJobs" ], "Resource": [ "arn:aws:codepipeline:us-west-2:111222333444:actionType:Custom/Test/TestProvider/1" ] } ] }
Exemple 6 : joindre ou modifier une politique pour l'intégration de Jenkins avec AWS CodePipeline
Si vous configurez un pipeline pour utiliser Jenkins à des fins de génération ou de test, créez une identité distincte pour cette intégration et associez une politique IAM dotée des autorisations minimales requises pour l'intégration entre Jenkins et. CodePipeline Cette stratégie est similaire à la stratégie gérée AWSCodePipelineCustomActionAccess. L'exemple suivant montre une politique d'intégration de Jenkins :
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"codepipeline:AcknowledgeJob",
"codepipeline:GetJobDetails",
"codepipeline:PollForJobs",
"codepipeline:PutJobFailureResult",
"codepipeline:PutJobSuccessResult"
],
"Resource": "*"
}
],
"Version": "2012-10-17"
}Exemple 7 : Configuration d'un accès entre comptes à un pipeline
Vous pouvez configurer l'accès aux pipelines pour les utilisateurs et groupes d'un autre compte AWS . La méthode recommandée consiste à créer un rôle dans le compte où le pipeline a été créé. Le rôle doit permettre aux utilisateurs de l'autre AWS compte d'assumer ce rôle et d'accéder au pipeline. Pour plus d'informations, consultez Procédure pas à pas : Accès entre comptes à l'aide des rôles.
L'exemple suivant montre une politique du compte 80398EXAMPLE qui permet aux utilisateurs de consulter, mais pas de modifier, le pipeline nommé MyFirstPipeline dans la console. CodePipeline Cette stratégie s'appuie sur la stratégie gérée AWSCodePipeline_ReadOnlyAccess, mais elle ne peut pas utiliser la stratégie gérée directement car elle est spécifique au pipeline MyFirstPipeline. Si vous ne souhaitez pas limiter la stratégie à un pipeline spécifique, il est conseillé d'utiliser l'une des stratégies gérées créées et stockées par CodePipeline. Pour plus d'informations, consultez Utilisation des politiques gérées. Vous devez associer cette politique à un rôle IAM que vous créez pour y accéder, par exemple un rôle nommé CrossAccountPipelineViewers :
{
"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"
}Après avoir créé cette politique, créez le rôle IAM dans le compte 80398EXAMPLE et associez la politique à ce rôle. Dans les relations de confiance du rôle, vous devez ajouter le AWS compte qui assume ce rôle. L'exemple suivant montre une politique qui permet aux utilisateurs du 111111111111 AWS compte d'assumer les rôles définis dans le compte 80398EXAMPLE :
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111111111111:root" }, "Action": "sts:AssumeRole" } ] }
L'exemple suivant montre une politique créée dans le 111111111111 AWS compte qui permet aux utilisateurs d'assumer le rôle nommé CrossAccountPipelineViewers dans le compte 80398EXAMPLE :
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::80398EXAMPLE:role/CrossAccountPipelineViewers" } ] }
Exemple 8 : Utilisation de ressources AWS associées à un autre compte dans un pipeline
Vous pouvez configurer des politiques qui permettent à un utilisateur de créer un pipeline utilisant les ressources d'un autre AWS compte. Pour ce faire, il est nécessaire de configurer des stratégies et des rôles à la fois dans le compte qui crée le pipeline (AccountA) et dans celui qui a créé les ressources à utiliser dans ce pipeline (AccountB). Vous devez également créer une clé gérée par le client AWS Key Management Service à utiliser pour l'accès entre comptes. Pour plus d'informations et des step-by-step exemples, reportez-vous Créez un pipeline CodePipeline qui utilise les ressources d'un autre AWS compte aux sections etConfigurer le chiffrement côté serveur pour les artefacts stockés dans Amazon S3 pour CodePipeline.
L'exemple suivant montre une stratégie configurée par AccountA pour un compartiment S3 utilisé pour stocker des artefacts de pipeline. La stratégie accorde l'accès à AccountB. Dans l'exemple suivant, l'ARN du compte AccountB est 012ID_ACCOUNT_B. L'ARN du compartiment S3 est codepipeline-us-east-2-1234567890. ARNsRemplacez-les par ceux ARNs correspondant au compartiment S3 et au compte auquel vous souhaitez autoriser l'accès :
{ "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" } ] }
L'exemple suivant montre une stratégie configurée par AccountA qui permet à AccountB d'assumer un rôle. Cette stratégie doit être appliquée au rôle de service pour CodePipeline (CodePipeline_Service_Role). Pour plus d'informations sur la façon d'appliquer des politiques aux rôles dans IAM, consultez la section Modification d'un rôle. Dans l'exemple suivant, 012ID_ACCOUNT_B est l'ARN du compte AccountB :
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::012ID_ACCOUNT_B:role/*" ] } }
L'exemple suivant montre une politique configurée par AccountB et appliquée au rôle d'EC2instance pour. CodeDeploy Cette stratégie accorde l'accès au compartiment S3 utilisé par AccountA pour stocker les artefacts de pipeline (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" ] } ] }
L'exemple suivant montre une politique indiquant AWS KMS où se 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" ] } ] }
L'exemple suivant montre une politique intégrée pour un rôle IAM (CrossAccount_Role) créé par AccountB qui permet d'accéder aux CodeDeploy actions requises par le pipeline dans AccountA.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"codedeploy:CreateDeployment",
"codedeploy:GetDeployment",
"codedeploy:GetDeploymentConfig",
"codedeploy:GetApplicationRevision",
"codedeploy:RegisterApplicationRevision"
],
"Resource": "*"
}
]
}L'exemple suivant montre une politique intégrée pour un rôle IAM (CrossAccount_Role) créé par AccountB qui permet d'accéder au compartiment S3 pour télécharger des artefacts d'entrée et des artefacts de sortie :
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject*", "s3:PutObject", "s3:PutObjectAcl" ], "Resource": [ "arn:aws:s3:::codepipeline-us-east-2-1234567890/*" ] } ] }
Pour plus d'informations sur la modification d'un pipeline pour l'accès entre comptes aux ressources, consultez Étape 2 : Modifier le pipeline .
