Exemples de politiques gérées par le client

Exemples de politiques basées sur l’identité AWS CodePipeline

Par défaut, IAM les utilisateurs et les rôles ne sont pas autorisés à créer ou à modifier CodePipeline des ressources. Ils ne peuvent pas non plus effectuer de tâches à l'aide du AWS Management Console AWS CLI, ou AWS API. Un IAM administrateur doit créer des IAM politiques qui accordent aux utilisateurs et aux rôles l'autorisation d'effectuer des API opérations spécifiques sur les ressources spécifiques dont ils ont besoin. L'administrateur doit ensuite associer ces politiques aux IAM utilisateurs ou aux groupes qui ont besoin de ces autorisations.

Pour savoir comment créer une politique IAM basée sur l'identité à l'aide de ces exemples de documents de JSON stratégie, voir Création de politiques dans l'JSONonglet du guide de l'IAMutilisateur.

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

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 le 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 avoir besoin d'un IAM rôle 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 IAM politique comportant les 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 EXAMPLE compte 80398 qui permet aux utilisateurs de consulter, mais pas de modifier, le pipeline nommé MyFirstPipeline dans la CodePipeline console. 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 politique à un pipeline spécifique, pensez à utiliser l'une des politiques gérées créées et gérées par CodePipeline. Pour plus d'informations, consultez Utilisation des politiques gérées. Vous devez associer cette politique à un IAM rôle 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 IAM rôle dans le EXAMPLE compte 80398 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 de 111111111111 AWS compte pour assumer les rôles définis dans le EXAMPLE compte 80398 :


{
    "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 111111111111 AWS compte qui permet aux utilisateurs d'assumer le rôle indiqué CrossAccountPipelineViewers dans le EXAMPLE compte 80398 :


{
    "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, ARN pour AccountB est. 012ID_ACCOUNT_B ARNPour le compartiment S3, c'estcodepipeline-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 politique 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 dansIAM, consultez la section Modification d'un rôle. Dans l'exemple suivant, 012ID_ACCOUNT_B c'est ARN pour 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 politique donne accès au compartiment S3 utilisé par AccountA pour stocker les artefacts du 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 trouve ARN la clé gérée par le client créée dans AccountA et configurée pour autoriser AccountB à l'utiliser :


{
    "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 IAM rôle (CrossAccount_Role) créé par AccountB qui permet d'accéder CodeDeploy aux 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 IAM rôle (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 .

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Comment AWS CodePipeline fonctionne avec IAM

Bonnes pratiques en matière de politiques