

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.

# AWS CodePipeline exemples de politiques basées sur l'identité
<a name="security_iam_id-based-policy-examples"></a>

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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) dans le *Guide de l'utilisateur IAM*.

Pour savoir comment créer un pipeline utilisant les ressources d'un autre compte, et pour obtenir des exemples de politiques connexes, consultez[Créez un pipeline CodePipeline qui utilise les ressources d'un autre AWS compte](pipelines-create-cross-account.md).

**Topics**
+ [Bonnes pratiques en matière de politiques](security_iam_service-with-iam-policy-best-practices.md)
+ [Affichage des ressources dans la console](security-iam-resources-console.md)
+ [Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations](security_iam_id-based-policy-examples-view-own-permissions.md)
+ [Exemples de politiques basées sur l'identité (IAM)](security-iam-id-policies-examples.md)
+ [Utilisation de balises pour contrôler l'accès aux CodePipeline ressources](tag-based-access-control.md)
+ [Autorisations requises pour utiliser la console](security-iam-permissions-console.md)
+ [Autorisations requises pour consulter les journaux de calcul dans la console](security-iam-permissions-console-logs.md)
+ [AWS politiques gérées pour AWS CodePipeline](managed-policies.md)
+ [Exemples de politiques gérées par le client](#customer-managed-policies)

## Exemples de politiques gérées par le client
<a name="customer-managed-policies"></a>

Dans cette section, vous trouverez des exemples de politiques utilisateur qui accordent des autorisations pour diverses actions . Ces politiques fonctionnent lorsque vous utilisez l'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](security-iam-permissions-console.md).

**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](#identity-based-policies-example-1)
+ [Exemple 2 : Octroi d'autorisations pour activer et désactiver les transitions entre les étapes](#identity-based-policies-example-2)
+ [Exemple 3 : Octroi d'autorisations pour obtenir la liste de tous les types d'action disponibles](#identity-based-policies-example-3)
+ [Exemple 4 : Octroi d'autorisations pour approuver ou rejeter des actions d'approbation manuelle](#identity-based-policies-example-4)
+ [Exemple 5 : Octroi d'autorisations pour interroger les tâches d'une action personnalisée](#identity-based-policies-example-5)
+ [Exemple 6 : joindre ou modifier une politique pour l'intégration de Jenkins avec AWS CodePipeline](#identity-based-policies-example-6)
+ [Exemple 7 : Configuration d'un accès entre comptes à un pipeline](#identity-based-policies-example-7)

### Exemple 1 : Octroi d'autorisations pour obtenir l'état d'un pipeline
<a name="identity-based-policies-example-1"></a>

L'exemple suivant accorde des autorisations pour obtenir l'état du pipeline nommé `MyFirstPipeline` :

------
#### [ JSON ]

****  

```
{
    "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
<a name="identity-based-policies-example-2"></a>

L'exemple suivant accorde des autorisations pour activer et désactiver les transitions entre toutes les étapes du pipeline nommé `MyFirstPipeline` :

------
#### [ JSON ]

****  

```
{
    "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
<a name="identity-based-policies-example-3"></a>

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` :

------
#### [ JSON ]

****  

```
{
    "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
<a name="identity-based-policies-example-4"></a>

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` : 

------
#### [ JSON ]

****  

```
{
    "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
<a name="identity-based-policies-example-5"></a>

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.

------
#### [ JSON ]

****  

```
{
    "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
<a name="identity-based-policies-example-6"></a>

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. Cette stratégie est similaire à la stratégie gérée `AWSCodePipelineCustomActionAccess`. L'exemple suivant montre une politique d'intégration de Jenkins :

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 

    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "codepipeline:AcknowledgeJob",
                "codepipeline:GetJobDetails",
                "codepipeline:PollForJobs",
                "codepipeline:PutJobFailureResult",
                "codepipeline:PutJobSuccessResult"
            ],
            "Resource": "*"
        }
    ]
}
```

------

### Exemple 7 : Configuration d'un accès entre comptes à un pipeline
<a name="identity-based-policies-example-7"></a>

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](https://docs.aws.amazon.com/IAM/latest/UserGuide/walkthru_cross-account-with-roles.html).

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. 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 . Pour plus d'informations, consultez [Utilisation des politiques gérées](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-using.html). Vous devez associer cette politique à un rôle IAM que vous créez pour y accéder, par exemple un rôle nommé `CrossAccountPipelineViewers` :

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 

    "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:{{111122223333}}:MyFirstPipeline"
        }
    ]
}
```

------

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

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::{{111122223333}}:role/{{CrossAccountPipelineViewers}}"
        }
    ]
}
```

------