

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.

# Sécurité dans AWS CodePipeline
<a name="security"></a>

La sécurité du cloud AWS est la priorité absolue. En tant que AWS client, vous bénéficiez de centres de données et d'architectures réseau conçus pour répondre aux exigences des entreprises les plus sensibles en matière de sécurité.

La sécurité est une responsabilité partagée entre vous AWS et vous. Le [modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) décrit ceci comme la sécurité *du* cloud et la sécurité *dans* le cloud :
+ **Sécurité du cloud** : AWS est chargée de protéger l'infrastructure qui exécute les AWS services dans le AWS Cloud. AWS vous fournit également des services que vous pouvez utiliser en toute sécurité. Des auditeurs tiers testent et vérifient régulièrement l'efficacité de notre sécurité dans le cadre des programmes de [AWS conformité Programmes](https://aws.amazon.com/compliance/programs/) de de conformité. Pour en savoir plus sur les programmes de conformité qui s'appliquent à AWS CodePipeline, voir [AWS Services concernés par programme de conformitéAWS](https://aws.amazon.com/compliance/services-in-scope/) .
+ **Sécurité dans le cloud** — Votre responsabilité est déterminée par le AWS service que vous utilisez. Vous êtes également responsable d’autres facteurs, y compris la sensibilité de vos données, les exigences de votre entreprise, ainsi que la législation et la réglementation applicables. 

Cette documentation vous aide à comprendre comment appliquer le modèle de responsabilité partagée lors de son utilisation CodePipeline. Les rubriques suivantes expliquent comment procéder à la configuration CodePipeline pour atteindre vos objectifs de sécurité et de conformité. Vous apprendrez également à utiliser d'autres AWS services qui vous aident à surveiller et à sécuriser vos CodePipeline ressources. 

**Topics**
+ [Protection des données dans AWS CodePipeline](data-protection.md)
+ [Gestion des identités et des accès pour AWS CodePipeline](security-iam.md)
+ [Connexion et surveillance CodePipeline](incident-response.md)
+ [Validation de conformité pour AWS CodePipeline](compliance-validation.md)
+ [Résilience dans AWS CodePipeline](disaster-recovery-resiliency.md)
+ [Sécurité de l'infrastructure dans AWS CodePipeline](infrastructure-security.md)
+ [Bonnes pratiques de sécurité](security-best-practices.md)

# Protection des données dans AWS CodePipeline
<a name="data-protection"></a>

Le [modèle de responsabilité AWS partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) de s'applique à la protection des données dans. Comme décrit dans ce modèle, AWS est chargé de protéger l'infrastructure mondiale qui gère tous les AWS Cloud. La gestion du contrôle de votre contenu hébergé sur cette infrastructure relève de votre responsabilité. Vous êtes également responsable des tâches de configuration et de gestion de la sécurité des Services AWS que vous utilisez. Pour plus d’informations sur la confidentialité des données, consultez [Questions fréquentes (FAQ) sur la confidentialité des données](https://aws.amazon.com/compliance/data-privacy-faq/). Pour en savoir plus sur la protection des données en Europe, consultez le billet de blog [Modèle de responsabilité partagée d’AWS et RGPD (Règlement général sur la protection des données)](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) sur le *Blog de sécuritéAWS *.

À des fins de protection des données, nous vous recommandons de protéger les Compte AWS informations d'identification et de configurer les utilisateurs individuels avec AWS IAM Identity Center ou Gestion des identités et des accès AWS (IAM). Ainsi, chaque utilisateur se voit attribuer uniquement les autorisations nécessaires pour exécuter ses tâches. Nous vous recommandons également de sécuriser vos données comme indiqué ci-dessous :
+ Utilisez l’authentification multifactorielle (MFA) avec chaque compte.
+  SSL/TLS À utiliser pour communiquer avec AWS les ressources. Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Configurez l'API et la journalisation de l'activité des utilisateurs avec AWS CloudTrail. Pour plus d'informations sur l'utilisation des CloudTrail sentiers pour capturer AWS des activités, consultez la section [Utilisation des CloudTrail sentiers](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) dans le *guide de AWS CloudTrail l'utilisateur*.
+ Utilisez des solutions de AWS chiffrement, ainsi que tous les contrôles de sécurité par défaut qu'ils contiennent Services AWS.
+ Utilisez des services de sécurité gérés avancés tels qu’Amazon Macie, qui contribuent à la découverte et à la sécurisation des données sensibles stockées dans Amazon S3.
+ Si vous avez besoin de modules cryptographiques validés par la norme FIPS 140-3 pour accéder AWS via une interface de ligne de commande ou une API, utilisez un point de terminaison FIPS. Pour plus d’informations sur les points de terminaison FIPS disponibles, consultez [Norme FIPS (Federal Information Processing Standard) 140-3](https://aws.amazon.com/compliance/fips/).

Nous vous recommandons fortement de ne jamais placer d’informations confidentielles ou sensibles, telles que les adresses e-mail de vos clients, dans des balises ou des champs de texte libre tels que le champ **Nom**. Cela inclut lorsque vous travaillez avec ou d'autres Services AWS utilisateurs de la console, de l'API ou AWS SDKs. AWS CLI Toutes les données que vous entrez dans des balises ou des champs de texte de forme libre utilisés pour les noms peuvent être utilisées à des fins de facturation ou dans les journaux de diagnostic. Si vous fournissez une adresse URL à un serveur externe, nous vous recommandons fortement de ne pas inclure d’informations d’identification dans l’adresse URL permettant de valider votre demande adressée à ce serveur.

Les bonnes pratiques de sécurité suivantes s'appliquent également à la protection des données dans CodePipeline :
+ [Configurer le chiffrement côté serveur pour les artefacts stockés dans Amazon S3 pour CodePipeline](S3-artifact-encryption.md)
+ [AWS Secrets Manager À utiliser pour suivre les mots de passe de base de données ou les clés d'API tierces](parameter-store-encryption.md)

## Confidentialité du trafic inter-réseau
<a name="inter-network-traffic-privacy"></a>

 Amazon VPC est un système Service AWS que vous pouvez utiliser pour lancer AWS des ressources dans un réseau virtuel (*cloud privé virtuel*) que vous définissez. CodePipelineprend en charge les points de terminaison Amazon VPC basés sur une AWS technologie qui facilite la communication privée entre les Services AWS utilisateurs d'une interface Elastic Network avec des adresses IP privées. AWS PrivateLink Cela signifie que vous pouvez vous connecter directement CodePipeline via un point de terminaison privé dans votre VPC, en conservant tout le trafic à l'intérieur de votre VPC et du réseau. AWS Auparavant, les applications exécutées dans un VPC nécessitaient un accès Internet pour la connexion à CodePipeline. Avec un VPC, vous contrôlez vos paramètres réseau, tels que :
+ plage d'adresses IP,
+ Sous-réseaux,
+ tables de routage, et
+ Passerelles réseau

Pour connecter votre VPC à CodePipeline, vous définissez un point de terminaison VPC d'interface pour. CodePipeline Ce type de point de terminaison vous permet de connecter votre VPC à. Services AWS Le point de terminaison fournit une connectivité fiable et évolutive CodePipeline sans nécessiter de passerelle Internet, d'instance de traduction d'adresses réseau (NAT) ou de connexion VPN. Pour plus d'informations sur la configuration d'un VPC, consultez le [Guide de l'utilisateur VPC](https://docs.aws.amazon.com/vpc/latest/userguide/).

## Chiffrement au repos
<a name="encryption-at-rest"></a>

Les données entrantes CodePipeline sont cryptées au repos à l'aide de AWS KMS keys. Les artefacts de code sont stockés dans un compartiment S3 appartenant au client et chiffrés à l'aide de la clé Clé gérée par AWS ou d'une clé gérée par le client. Pour de plus amples informations, veuillez consulter [Configurer le chiffrement côté serveur pour les artefacts stockés dans Amazon S3 pour CodePipeline](S3-artifact-encryption.md).

## Chiffrement en transit
<a name="encryption-in-transit"></a>

Toutes les service-to-service communications sont cryptées en transit à l'aide du protocole SSL/TLS. 

## Gestion des clés de chiffrement
<a name="key-management"></a>

Si vous choisissez l'option par défaut pour chiffrer les artefacts de code, CodePipeline utilise le Clé gérée par AWS. Vous ne pouvez ni le modifier ni le supprimer Clé gérée par AWS. Si vous utilisez une clé gérée par le client AWS KMS pour chiffrer ou déchiffrer des artefacts dans le compartiment S3, vous pouvez modifier ou faire pivoter cette clé gérée par le client si nécessaire.

**Important**  
CodePipeline ne prend en charge que les clés KMS symétriques. N'utilisez pas de clé KMS asymétrique pour chiffrer les données de votre compartiment S3.

**Topics**

# Configurer le chiffrement côté serveur pour les artefacts stockés dans Amazon S3 pour CodePipeline
<a name="S3-artifact-encryption"></a>

Il existe deux manières de configurer le chiffrement côté serveur pour les artefacts Amazon S3 :
+ CodePipeline crée un compartiment d'artefacts S3 et un compartiment par défaut Clé gérée par AWS lorsque vous créez un pipeline à l'aide de l'assistant de création de pipeline. Clé gérée par AWS Il est crypté avec les données des objets et géré par AWS.
+ Vous pouvez créer et gérer votre propre clé gérée par le client.

**Important**  
CodePipeline ne prend en charge que les clés KMS symétriques. N'utilisez pas de clé KMS asymétrique pour chiffrer les données de votre compartiment S3.

Si vous utilisez la clé S3 par défaut, vous ne pouvez ni la modifier ni la supprimer Clé gérée par AWS. Si vous utilisez une clé gérée par le client AWS KMS pour chiffrer ou déchiffrer des artefacts dans le compartiment S3, vous pouvez modifier ou faire pivoter cette clé gérée par le client si nécessaire.

Amazon S3 prend en charge les politiques de compartiment que vous pouvez utiliser si vous exigez un chiffrement côté serveur pour tous les objets stockés dans le compartiment. Par exemple, la politique de compartiment suivante n'autorise pas le chargement d'objet (`s3:PutObject`) si la demande n'inclut pas l'en-tête `x-amz-server-side-encryption` demandant le chiffrement côté serveur avec des SSE-KMS.

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

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Id": "SSEAndSSLPolicy",
    "Statement": [
        {
            "Sid": "DenyUnEncryptedObjectUploads",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::codepipeline-us-west-2-89050EXAMPLE/*",
            "Condition": {
                "StringNotEquals": {
                    "s3:x-amz-server-side-encryption": "aws:kms"
                }
            }
        },
        {
            "Sid": "DenyInsecureConnections",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::codepipeline-us-west-2-89050EXAMPLE/*",
            "Condition": {
                "Bool": {
                    "aws:SecureTransport": "false"
                }
            }
        }
    ]
}
```

------

Pour plus d'informations sur le chiffrement côté serveur AWS KMS, voir [Protection des données à l'aide du chiffrement côté serveur et Protection des données à l'aide du chiffrement côté](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) [serveur avec des clés KMS stockées dans (SSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html). AWS Key Management Service 

Pour plus d'informations à ce sujet AWS KMS, consultez le [guide du AWS Key Management Service développeur](https://docs.aws.amazon.com/kms/latest/developerguide/).

**Topics**
+ [Consultez votre Clé gérée par AWS](#S3-view-default-keys)
+ [Configurez le chiffrement côté serveur pour les compartiments S3 à l'aide ou CloudFormation AWS CLI](#S3-rotate-customer-key)

## Consultez votre Clé gérée par AWS
<a name="S3-view-default-keys"></a>

Lorsque vous utilisez l'assistant **Création d'un pipeline** pour créer votre premier pipeline, un compartiment S3 est créé automatiquement dans la région où vous avez créé ce pipeline. Ce compartiment permet de stocker les artefacts du pipeline. Lorsqu'un pipeline s'exécute, les artefacts sont placés dans le compartiment S3 et en sont extraits. Par défaut, CodePipeline utilise le chiffrement côté serveur à AWS KMS l'aide de la `aws/s3` clé Clé gérée par AWS pour Amazon S3. Il Clé gérée par AWS est créé et enregistré dans votre AWS compte. Lorsque des artefacts sont extraits du compartiment S3, CodePipeline utilise le même processus SSE-KMS pour déchiffrer l'artefact.

**Pour consulter les informations relatives à votre Clé gérée par AWS**

1. Connectez-vous à la AWS KMS console AWS Management Console et ouvrez-la.

1. Si une page de bienvenue apparaît, choisissez **Commencer maintenant**.

1. Dans le volet de navigation du service, choisissez **les clés AWS gérées**. 

1. Choisissez la région de votre pipeline. Par exemple, si le pipeline a été créé en`us-east-2`, assurez-vous que le filtre est défini sur US East (Ohio).

   Pour plus d'informations sur les régions et les points de terminaison disponibles CodePipeline, consultez la section [AWS CodePipeline Points de terminaison et quotas](https://docs.aws.amazon.com/general/latest/gr/codepipeline.html).

1. Dans la liste, choisissez la clé avec l'alias utilisé pour votre pipeline (par défaut, **aws/s3**). Les informations de base sur la clé s'affichent.



## Configurez le chiffrement côté serveur pour les compartiments S3 à l'aide ou CloudFormation AWS CLI
<a name="S3-rotate-customer-key"></a>

Lorsque vous utilisez CloudFormation ou AWS CLI pour créer un pipeline, vous devez configurer le chiffrement côté serveur manuellement. Utilisez l'exemple de politique de compartiment ci-dessus, puis créez votre propre clé gérée par le client. Vous pouvez également utiliser vos propres clés au lieu de Clé gérée par AWS. Voici quelques raisons de choisir votre propre clé :
+ Vous souhaitez effectuer une rotation de la clé sur un planning afin de répondre aux exigences relatives aux activités et à la sécurité de votre organisation.
+ Vous souhaitez créer un pipeline qui utilise des ressources associées à un autre compte AWS . Cette opération nécessite l'utilisation d'une clé gérée par le client. Pour de plus amples informations, veuillez consulter [Créez un pipeline CodePipeline qui utilise les ressources d'un autre AWS compte](pipelines-create-cross-account.md). 

Les bonnes pratiques de chiffrement décourage la réutilisation étendue des clés de chiffrement. La bonne pratique consiste à effectuer régulièrement une rotation de votre clé. Pour créer un nouveau matériel cryptographique pour vos AWS KMS clés, vous pouvez créer une clé gérée par le client, puis modifier vos applications ou alias afin d'utiliser la nouvelle clé gérée par le client. Vous pouvez également activer la rotation automatique des clés pour une clé gérée par le client existante. 

Pour faire pivoter votre clé gérée par le client, voir [Rotation des clés](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html). 

**Important**  
CodePipeline ne prend en charge que les clés KMS symétriques. N'utilisez pas de clé KMS asymétrique pour chiffrer les données de votre compartiment S3.

# AWS Secrets Manager À utiliser pour suivre les mots de passe de base de données ou les clés d'API tierces
<a name="parameter-store-encryption"></a>

Nous vous recommandons de les utiliser AWS Secrets Manager pour alterner, gérer et récupérer les informations d'identification de base de données, les clés d'API et autres **secrets** tout au long de leur cycle de vie. Secrets Manager vous permet de remplacer les informations d'identification codées en dur dans votre code (y compris les mots de passe) par un appel d'API à Secrets Manager pour récupérer le secret par programmation. Pour plus d'informations, consultez [Qu'est-ce que AWS Secrets Manager ?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) dans le *Guide de l'utilisateur de AWS Secrets Manager*.

Pour les pipelines dans lesquels vous transmettez des paramètres secrets (tels que des OAuth informations d'identification) dans un CloudFormation modèle, vous devez inclure des références dynamiques dans votre modèle qui accèdent aux secrets que vous avez stockés dans Secrets Manager. Pour le modèle d'ID de référence et des exemples, voir [Secrets Manager Secrets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/dynamic-references.html#dynamic-references-secretsmanager) dans le *guide de AWS CloudFormation l'utilisateur*. Pour un exemple qui utilise des références dynamiques dans un extrait de modèle pour un GitHub webhook dans un pipeline, voir Configuration des ressources du [webhook](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-codepipeline-webhook.html#aws-resource-codepipeline-webhook--examples).



## Consultez aussi
<a name="related-resources-managing-secrets"></a>

Les ressources connexes suivantes peuvent s'avérer utiles pour la gestion des secrets.
+ Secrets Manager peut automatiquement alterner les informations d'identification de base de données, par exemple pour la rotation des secrets Amazon RDS. Pour plus d'informations, consultez [Rotating Your AWS Secrets Manager Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html) dans le *guide de l'utilisateur de AWS Secrets Manager*.
+ Pour voir les instructions permettant d'ajouter des références dynamiques Secrets Manager à vos modèles CloudFormation , veuillez consulter [https://aws.amazon.com/blogs/security/how-to-create-and-retrieve-secrets-managed-in-aws-secrets-manager-using-aws-cloudformation-template/](https://aws.amazon.com/blogs/security/how-to-create-and-retrieve-secrets-managed-in-aws-secrets-manager-using-aws-cloudformation-template/). 

# Gestion des identités et des accès pour AWS CodePipeline
<a name="security-iam"></a>

Gestion des identités et des accès AWS (IAM) est un outil Service AWS qui permet à un administrateur de contrôler en toute sécurité l'accès aux AWS ressources. Les administrateurs IAM contrôlent qui peut être *authentifié* (connecté) et *autorisé (autorisé*) à utiliser CodePipeline les ressources. IAM est un Service AWS outil que vous pouvez utiliser sans frais supplémentaires.

**Topics**
+ [Public ciblé](#security_iam_audience)
+ [Authentification par des identités](#security_iam_authentication)
+ [Gestion de l’accès à l’aide de politiques](#security_iam_access-manage)
+ [Comment AWS CodePipeline fonctionne avec IAM](security_iam_service-with-iam.md)
+ [AWS CodePipeline exemples de politiques basées sur l'identité](security_iam_id-based-policy-examples.md)
+ [AWS CodePipeline exemples de politiques basées sur les ressources](security_iam_resource-based-policy-examples.md)
+ [Résolution des problèmes AWS CodePipeline d'identité et d'accès](security_iam_troubleshoot.md)
+ [référence des autorisations](permissions-reference.md)
+ [Gérer le rôle CodePipeline de service](how-to-custom-role.md)

## Public ciblé
<a name="security_iam_audience"></a>

La façon dont vous utilisez Gestion des identités et des accès AWS (IAM) varie en fonction de votre rôle :
+ **Utilisateur du service** : demandez des autorisations à votre administrateur si vous ne pouvez pas accéder aux fonctionnalités (voir [Résolution des problèmes AWS CodePipeline d'identité et d'accès](security_iam_troubleshoot.md))
+ **Administrateur du service** : déterminez l’accès des utilisateurs et soumettez les demandes d’autorisation (voir [Comment AWS CodePipeline fonctionne avec IAM](security_iam_service-with-iam.md))
+ **Administrateur IAM** : rédigez des politiques pour gérer l’accès (voir [AWS CodePipeline exemples de politiques basées sur l'identité](security_iam_id-based-policy-examples.md))

## Authentification par des identités
<a name="security_iam_authentication"></a>

L'authentification est la façon dont vous vous connectez à AWS l'aide de vos informations d'identification. Vous devez être authentifié en tant qu'utilisateur IAM ou en assumant un rôle IAM. Utilisateur racine d'un compte AWS

Vous pouvez vous connecter en tant qu'identité fédérée à l'aide d'informations d'identification provenant d'une source d'identité telle que AWS IAM Identity Center (IAM Identity Center), d'une authentification unique ou d'informations d'identification. Google/Facebook Pour plus d’informations sur la connexion, consultez [Connexion à votre Compte AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) dans le *Guide de l’utilisateur Connexion à AWS *.

Pour l'accès par programmation, AWS fournit un SDK et une CLI pour signer les demandes de manière cryptographique. Pour plus d’informations, consultez [Signature AWS Version 4 pour les demandes d’API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) dans le *Guide de l’utilisateur IAM*.

### Utilisateur racine d'un compte AWS
<a name="security_iam_authentication-rootuser"></a>

 Lorsque vous créez un Compte AWS, vous commencez par une seule identité de connexion appelée *utilisateur Compte AWS root* qui dispose d'un accès complet à toutes Services AWS les ressources. Il est vivement déconseillé d’utiliser l’utilisateur racine pour vos tâches quotidiennes. Pour les tâches qui requièrent des informations d’identification de l’utilisateur racine, consultez [Tâches qui requièrent les informations d’identification de l’utilisateur racine](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) dans le *Guide de l’utilisateur IAM*. 

### Utilisateurs et groupes IAM
<a name="security_iam_authentication-iamuser"></a>

Un *[utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* est une identité qui dispose d’autorisations spécifiques pour une seule personne ou application. Nous vous recommandons d’utiliser ces informations d’identification temporaires au lieu des utilisateurs IAM avec des informations d’identification à long terme. Pour plus d'informations, voir [Exiger des utilisateurs humains qu'ils utilisent la fédération avec un fournisseur d'identité pour accéder à AWS l'aide d'informations d'identification temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) dans le *guide de l'utilisateur IAM*.

[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) spécifient une collection d’utilisateurs IAM et permettent de gérer plus facilement les autorisations pour de grands ensembles d’utilisateurs. Pour plus d’informations, consultez [Cas d’utilisation pour les utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) dans le *Guide de l’utilisateur IAM*.

### Rôles IAM
<a name="security_iam_authentication-iamrole"></a>

Un *[rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* est une identité dotée d’autorisations spécifiques qui fournit des informations d’identification temporaires. Vous pouvez assumer un rôle en [passant d'un rôle d'utilisateur à un rôle IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) ou en appelant une opération d' AWS API AWS CLI ou d'API. Pour plus d’informations, consultez [Méthodes pour endosser un rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) dans le *Guide de l’utilisateur IAM*.

Les rôles IAM sont utiles pour l’accès des utilisateurs fédérés, les autorisations temporaires des utilisateurs IAM, les accès intercompte, les accès entre services et les applications exécutées sur Amazon EC2. Pour plus d’informations, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.

## Gestion de l’accès à l’aide de politiques
<a name="security_iam_access-manage"></a>

Vous contrôlez l'accès en AWS créant des politiques et en les associant à AWS des identités ou à des ressources. Une politique définit les autorisations lorsqu'elles sont associées à une identité ou à une ressource. AWS évalue ces politiques lorsqu'un directeur fait une demande. La plupart des politiques sont stockées AWS sous forme de documents JSON. Pour plus d’informations les documents de politique JSON, consultez [Vue d’ensemble des politiques JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) dans le *Guide de l’utilisateur IAM*.

À l’aide de politiques, les administrateurs précisent qui a accès à quoi en définissant quel **principal** peut effectuer des **actions** sur quelles **ressources** et dans quelles **conditions**.

Par défaut, les utilisateurs et les rôles ne disposent d’aucune autorisation. Un administrateur IAM crée des politiques IAM et les ajoute aux rôles, que les utilisateurs peuvent ensuite assumer. Les politiques IAM définissent les autorisations quelle que soit la méthode que vous utilisez pour exécuter l’opération.

### Politiques basées sur l’identité
<a name="security_iam_access-manage-id-based-policies"></a>

Les stratégies basées sur l’identité sont des documents de stratégie d’autorisations JSON que vous attachez à une identité (utilisateur, groupe ou rôle). Ces politiques contrôlent les actions que peuvent exécuter ces identités, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.

Les politiques basées sur l’identité peuvent être des *politiques intégrées* (intégrées directement dans une seule identité) ou des *politiques gérées (politiques* autonomes associées à plusieurs identités). Pour découvrir comment choisir entre des politiques gérées et en ligne, consultez [Choix entre les politiques gérées et les politiques en ligne](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) dans le *Guide de l’utilisateur IAM*.

### Politiques basées sur les ressources
<a name="security_iam_access-manage-resource-based-policies"></a>

Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Les exemples incluent *les politiques de confiance de rôle* IAM et les *stratégies de compartiment* Amazon S3. Dans les services qui sont compatibles avec les politiques basées sur les ressources, les administrateurs de service peuvent les utiliser pour contrôler l’accès à une ressource spécifique. Vous devez [spécifier un principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dans une politique basée sur les ressources.

Les politiques basées sur les ressources sont des politiques en ligne situées dans ce service. Vous ne pouvez pas utiliser les politiques AWS gérées par IAM dans une stratégie basée sur les ressources.

### Autres types de politique
<a name="security_iam_access-manage-other-policies"></a>

AWS prend en charge des types de politiques supplémentaires qui peuvent définir les autorisations maximales accordées par les types de politiques les plus courants :
+ **Limites d’autorisations** : une limite des autorisations définit le nombre maximum d’autorisations qu’une politique basée sur l’identité peut accorder à une entité IAM. Pour plus d’informations, consultez [Limites d’autorisations pour des entités IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) dans le *Guide de l’utilisateur IAM*.
+ **Politiques de contrôle des services (SCPs)** — Spécifiez les autorisations maximales pour une organisation ou une unité organisationnelle dans AWS Organizations. Pour plus d’informations, consultez [Politiques de contrôle de service](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) dans le *Guide de l’utilisateur AWS Organizations *.
+ **Politiques de contrôle des ressources (RCPs)** : définissez le maximum d'autorisations disponibles pour les ressources de vos comptes. Pour plus d'informations, voir [Politiques de contrôle des ressources (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) dans le *guide de AWS Organizations l'utilisateur*.
+ **Politiques de session** : politiques avancées que vous passez en tant que paramètre lorsque vous créez par programmation une session temporaire pour un rôle ou un utilisateur fédéré. Pour plus d’informations, consultez [Politiques de session](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) dans le *Guide de l’utilisateur IAM*.

# Comment AWS CodePipeline fonctionne avec IAM
<a name="security_iam_service-with-iam"></a>

Avant d'utiliser IAM pour gérer l'accès à CodePipeline, vous devez connaître les fonctionnalités IAM disponibles. CodePipeline Pour obtenir une vue d'ensemble de la manière dont IAM fonctionne CodePipeline et Services AWS des autres fonctionnalités, consultez Services AWS la section relative à l'utilisation [d'IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dans le Guide de l'utilisateur d'*IAM*.

**Topics**
+ [CodePipeline politiques basées sur l'identité](#security_iam_service-with-iam-id-based-policies)
+ [CodePipeline politiques basées sur les ressources](#security_iam_service-with-iam-resource-based-policies)
+ [Autorisation basée sur les CodePipeline tags](#security_iam_service-with-iam-tags)
+ [CodePipeline Rôles IAM](#security_iam_service-with-iam-roles)

## CodePipeline politiques basées sur l'identité
<a name="security_iam_service-with-iam-id-based-policies"></a>

Avec les politiques basées sur l'identité IAM, vous pouvez spécifier des actions et ressources autorisées ou refusées, ainsi que les conditions dans lesquelles les actions sont autorisées ou refusées. CodePipeline prend en charge des actions, ressources et clés de condition spécifiques. Pour en savoir plus sur tous les éléments que vous utilisez dans une politique JSON, consultez [Références des éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) dans le *Guide de l’utilisateur IAM*.

### Actions
<a name="security_iam_service-with-iam-id-based-policies-actions"></a>

Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.

L’élément `Action` d’une politique JSON décrit les actions que vous pouvez utiliser pour autoriser ou refuser l’accès à une politique. Intégration d’actions dans une politique afin d’accorder l’autorisation d’exécuter les opérations associées.

Les actions de politique en CodePipeline cours utilisent le préfixe suivant avant l'action :`codepipeline:`. 

Par exemple, pour accorder à quelqu'un l'autorisation d'afficher les pipelines existants dans le compte, vous incluez l'action `codepipeline:GetPipeline` dans sa stratégie. Les déclarations de politique doivent inclure un `NotAction` élément `Action` ou. CodePipeline définit son propre ensemble d'actions décrivant les tâches que vous pouvez effectuer avec ce service.

Pour spécifier plusieurs actions dans une seule déclaration, séparez-les par des virgules comme suit :

```
"Action": [
      "codepipeline:action1",
      "codepipeline:action2"
```

Vous pouvez aussi spécifier plusieurs actions à l’aide de caractères génériques (\$1). Par exemple, pour spécifier toutes les actions qui commencent par le mot `Get`, incluez l’action suivante :

```
"Action": "codepipeline:Get*"
```



Pour obtenir la liste des CodePipeline actions, reportez-vous à la section [Actions définies par AWS CodePipeline](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscodepipeline.html#awscodepipeline-actions-as-permissions) dans le *guide de l'utilisateur IAM*.

### Ressources
<a name="security_iam_service-with-iam-id-based-policies-resources"></a>

Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.

L’élément de politique JSON `Resource` indique le ou les objets auxquels l’action s’applique. Il est recommandé de définir une ressource à l’aide de son [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Pour les actions qui ne sont pas compatibles avec les autorisations de niveau ressource, utilisez un caractère générique (\$1) afin d’indiquer que l’instruction s’applique à toutes les ressources.

```
"Resource": "*"
```



#### ressources et opérations
<a name="ACP_ARN_Format"></a>

Dans , la principale ressource est le pipeline. Dans votre stratégie, vous utilisez un nom Amazon Resource Name (ARN) pour identifier la ressource à laquelle la stratégie s'applique. prend en charge d'autres ressources qui peuvent être utilisées avec la ressource principale, telles que les étapes, les actions et les actions personnalisées. Celles-ci sont appelées sous-ressources. Ces ressources et sous-ressources sont associées à des noms de ressources Amazon uniques (ARNs). Pour plus d'informations sur ARNs, consultez [Amazon Resource Names (ARN) et les Service AWS espaces de noms](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) dans le *Référence générale d'Amazon Web Services*. Pour obtenir l'ARN du pipeline associé à votre pipeline, vous pouvez le trouver sous **Paramètres** de la console. Pour de plus amples informations, veuillez consulter [Afficher l'ARN du pipeline et l'ARN du rôle de service (console)](pipelines-settings-console.md).


| Type de ressource | Format ARN | 
| --- | --- | 
|  Pipeline  |  arn:aws:codepipeline : : *region* *account* *pipeline-name*  | 
| Étape |  arn:aws:codepipeline : : :/*region**account**pipeline-name**stage-name*  | 
| Action |  arn:aws:codepipeline : : :/*region**account**pipeline-name**stage-name**action-name*  | 
| Action personnalisée | arn:aws:codepipeline : ::actiontype :///regionaccountownercategoryproviderversion | 
|  Toutes les ressources   |  arn:aws:codepipeline : \$1  | 
|  Toutes les ressources appartenant au compte spécifié dans la région indiquée  |  arn:aws:codepipeline : : : \$1 *region* *account*  | 

**Note**  
La plupart des services AWS traitent deux points (:)) ou une barre oblique (/) comme le même caractère dans ARNs. Cependant, recherche une correspondance exacte dans les modèles et règles d'événements. Veillez à utiliser les caractères ARN corrects lors de la création de modèles d'événements afin qu'ils correspondent à la syntaxe ARN dans le pipeline que vous souhaitez faire correspondre.

Dans , des appels d'API sont présents qui prennent en charge les autorisations au niveau des ressources. Les autorisations au niveau des ressources indiquent si un appel d'API peut spécifier une ressource ARN, ou s'il peut uniquement spécifier toutes les ressources à l'aide du caractère générique. Consultez [référence des autorisations](permissions-reference.md) pour obtenir une description détaillée des autorisations au niveau des ressources et une liste des appels d' CodePipeline API qui prennent en charge les autorisations au niveau des ressources.

Par exemple, vous pouvez indiquer un pipeline (*myPipeline*) spécifique dans votre instruction à l'aide de son ARN comme suit :

```
"Resource": "arn:aws:codepipeline:us-east-2:111222333444:myPipeline"
```

Vous pouvez aussi spécifier tous les pipelines qui appartiennent à un compte spécifique à l'aide du caractère générique (\$1) comme suit :

```
"Resource": "arn:aws:codepipeline:us-east-2:111222333444:*"
```

Pour spécifier toutes les ressources, ou si une action d'API spécifique n'est pas prise en charge ARNs, utilisez le caractère générique (\$1) dans l'`Resource`élément comme suit :

```
"Resource": "*"
```

**Note**  
Lorsque vous créez des politiques IAM, suivez les conseils de sécurité standard qui consistent à accorder le moindre privilège, c'est-à-dire à n'accorder que les autorisations nécessaires à l'exécution d'une tâche. Si un appel d'API est compatible ARNs, il prend en charge les autorisations au niveau des ressources et vous n'avez pas besoin d'utiliser le caractère générique (\$1).

Certains appels d'API acceptent plusieurs ressources (par exemple,`GetPipeline`). Pour spécifier plusieurs ressources dans une seule instruction, séparez-les ARNs par des virgules, comme suit :

```
"Resource": ["arn1", "arn2"]
```

 fournit un ensemble d'opérations permettant de travailler avec les ressources. Pour obtenir la liste des opérations disponibles, consultez [référence des autorisations](permissions-reference.md).

### Clés de condition
<a name="security_iam_service-with-iam-id-based-policies-conditionkeys"></a>

Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.

L’élément `Condition` indique à quel moment les instructions s’exécutent en fonction de critères définis. Vous pouvez créer des expressions conditionnelles qui utilisent des [opérateurs de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), tels que les signes égal ou inférieur à, pour faire correspondre la condition de la politique aux valeurs de la demande. Pour voir toutes les clés de condition AWS globales, voir les clés de [contexte de condition AWS globales](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*.

CodePipeline définit son propre ensemble de clés de condition et prend également en charge l'utilisation de certaines clés de condition globales. Pour voir toutes les clés de condition AWS globales, consultez la section [Clés contextuelles de condition AWS globale](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*.



 Toutes les actions Amazon EC2 prennent en charge les clés de condition `aws:RequestedRegion` et `ec2:Region`. Pour plus d’informations, consultez [Exemple : restriction de l’accès à une région spécifique](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region). 

Pour consulter la liste des clés de CodePipeline condition, reportez-vous à la section [Clés de AWS CodePipeline condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscodepipeline.html#awscodepipeline-policy-keys) du *guide de l'utilisateur IAM*. Pour savoir avec quelles actions et ressources vous pouvez utiliser une clé de condition, voir [Actions définies par AWS CodePipeline](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscodepipeline.html#awscodepipeline-actions-as-permissions).

### Exemples
<a name="security_iam_service-with-iam-id-based-policies-examples"></a>



Pour consulter des exemples de politiques CodePipeline basées sur l'identité, consultez. [AWS CodePipeline exemples de politiques basées sur l'identité](security_iam_id-based-policy-examples.md)

## CodePipeline politiques basées sur les ressources
<a name="security_iam_service-with-iam-resource-based-policies"></a>

CodePipeline ne prend pas en charge les politiques basées sur les ressources. Cependant, un exemple de politique basée sur les ressources pour le service S3 associé CodePipeline est fourni.

### Exemples
<a name="security_iam_service-with-iam-resource-based-policies-examples"></a>



Pour consulter des exemples de politiques CodePipeline basées sur les ressources, voir [AWS CodePipeline exemples de politiques basées sur les ressources](security_iam_resource-based-policy-examples.md)

## Autorisation basée sur les CodePipeline tags
<a name="security_iam_service-with-iam-tags"></a>

Vous pouvez associer des balises à CodePipeline des ressources ou transmettre des balises dans une demande à CodePipeline. Pour contrôler l’accès basé sur des étiquettes, vous devez fournir les informations d’étiquette dans l’[élément de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) d’une politique utilisant les clés de condition `codepipeline:ResourceTag/key-name`, `aws:RequestTag/key-name` ou `aws:TagKeys`. Pour plus d’informations sur le balisage des ressources CodePipeline , consultez [Balisage des ressources](tag-resources.md).

Pour afficher un exemple de stratégie basée sur l'identité permettant de limiter l'accès à une ressource basée sur les balises de cette ressource, veuillez consulter [Utilisation de balises pour contrôler l'accès aux CodePipeline ressources](tag-based-access-control.md).

## CodePipeline Rôles IAM
<a name="security_iam_service-with-iam-roles"></a>

Un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) est une entité de votre AWS compte dotée d'autorisations spécifiques.

### Utilisation d'informations d'identification temporaires avec CodePipeline
<a name="security_iam_service-with-iam-roles-tempcreds"></a>

Vous pouvez utiliser des informations d’identification temporaires pour vous connecter à l’aide de la fédération, endosser un rôle IAM ou encore pour endosser un rôle intercompte. Vous obtenez des informations d'identification de sécurité temporaires en appelant des opérations d' AWS STS API telles que [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)ou [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html). 

CodePipeline prend en charge l'utilisation d'informations d'identification temporaires. 

### Rôles du service
<a name="security_iam_service-with-iam-roles-service"></a>

CodePipeline permet à un service d'assumer un [rôle de service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-role) en votre nom. Ce rôle autorise le service à accéder à des ressources d’autres services pour effectuer une action en votre nom. Les rôles de service s’affichent dans votre compte IAM et sont la propriété du compte. Cela signifie qu’un administrateur IAM peut modifier les autorisations associées à ce rôle. Toutefois, une telle action peut perturber le bon fonctionnement du service.

CodePipeline soutient les rôles de service. 

# 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)

# Bonnes pratiques en matière de politiques
<a name="security_iam_service-with-iam-policy-best-practices"></a>

Les politiques basées sur l'identité déterminent si quelqu'un peut créer, accéder ou supprimer CodePipeline des ressources dans votre compte. Ces actions peuvent entraîner des frais pour votre Compte AWS. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations :
+ **Commencez AWS par les politiques gérées et passez aux autorisations du moindre privilège : pour commencer à accorder des autorisations** à vos utilisateurs et à vos charges de travail, utilisez les *politiques AWS gérées* qui accordent des autorisations pour de nombreux cas d'utilisation courants. Ils sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire davantage les autorisations en définissant des politiques gérées par les AWS clients spécifiques à vos cas d'utilisation. Pour plus d’informations, consultez [politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [politiques gérées par AWS pour les activités professionnelles](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*.
+ **Accordez les autorisations de moindre privilège** : lorsque vous définissez des autorisations avec des politiques IAM, accordez uniquement les autorisations nécessaires à l’exécution d’une seule tâche. Pour ce faire, vous définissez les actions qui peuvent être entreprises sur des ressources spécifiques dans des conditions spécifiques, également appelées *autorisations de moindre privilège*. Pour plus d’informations sur l’utilisation d’IAM pour appliquer des autorisations, consultez [politiques et autorisations dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez des conditions dans les politiques IAM pour restreindre davantage l’accès** : vous pouvez ajouter une condition à vos politiques afin de limiter l’accès aux actions et aux ressources. Par exemple, vous pouvez écrire une condition de politique pour spécifier que toutes les demandes doivent être envoyées via SSL. Vous pouvez également utiliser des conditions pour accorder l'accès aux actions de service si elles sont utilisées par le biais d'un service spécifique Service AWS, tel que CloudFormation. Pour plus d’informations, consultez [Conditions pour éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez l’Analyseur d’accès IAM pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles** : l’Analyseur d’accès IAM valide les politiques nouvelles et existantes de manière à ce que les politiques IAM respectent le langage de politique IAM (JSON) et les bonnes pratiques IAM. IAM Access Analyzer fournit plus de 100 vérifications de politiques et des recommandations exploitables pour vous aider à créer des politiques sécurisées et fonctionnelles. Pour plus d’informations, consultez [Validation de politiques avec IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) dans le *Guide de l’utilisateur IAM*.
+ **Exiger l'authentification multifactorielle (MFA**) : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur root, activez l'authentification MFA pour une sécurité accrue. Compte AWS Pour exiger la MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour plus d’informations, consultez [Sécurisation de l’accès aux API avec MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) dans le *Guide de l’utilisateur IAM*.

Pour plus d’informations sur les bonnes pratiques dans IAM, consultez [Bonnes pratiques de sécurité dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dans le *Guide de l’utilisateur IAM*.

# Affichage des ressources dans la console
<a name="security-iam-resources-console"></a>

La console doit être `ListRepositories` autorisée à afficher la liste des référentiels de votre AWS compte dans la AWS région où vous êtes connecté. La console comprend également une fonction **Go to resource (Accéder aux ressources)** qui permet d'effectuer rapidement une recherche de ressources sensible à la casse. Cette recherche est effectuée dans votre AWS compte dans la AWS région où vous êtes connecté. Les ressources suivantes sont affichées pour les services suivants :
+ AWS CodeBuild : Projets de génération
+ AWS CodeCommit : Référentiels
+ AWS CodeDeploy : Applications
+ AWS CodePipeline : Pipelines

Pour effectuer cette recherche pour les ressources dans tous les services, vous devez disposer des autorisations suivantes :
+ AWS CodeBuild: `ListProjects`
+ CodeCommit: `ListRepositories`
+ CodeDeploy: `ListApplications`
+ CodePipeline: `ListPipelines`

Les résultats ne sont pas renvoyés pour les ressources d'un service si vous ne disposez pas d'autorisations pour ce service. Même si vous êtes autorisé à afficher des ressources, certaines ressources ne sont pas renvoyées si une valeur `Deny` explicite est définie pour l'affichage de ces ressources.

# Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations
<a name="security_iam_id-based-policy-examples-view-own-permissions"></a>

Cet exemple montre comment créer une politique qui permet aux utilisateurs IAM d’afficher les politiques en ligne et gérées attachées à leur identité d’utilisateur. Cette politique inclut les autorisations permettant d'effectuer cette action sur la console ou par programmation à l'aide de l'API AWS CLI or AWS .

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ViewOwnUserInfo",
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:ListGroupsForUser",
                "iam:ListAttachedUserPolicies",
                "iam:ListUserPolicies",
                "iam:GetUser"
            ],
            "Resource": ["arn:aws:iam::*:user/${aws:username}"]
        },
        {
            "Sid": "NavigateInConsole",
            "Effect": "Allow",
            "Action": [
                "iam:GetGroupPolicy",
                "iam:GetPolicyVersion",
                "iam:GetPolicy",
                "iam:ListAttachedGroupPolicies",
                "iam:ListGroupPolicies",
                "iam:ListPolicyVersions",
                "iam:ListPolicies",
                "iam:ListUsers"
            ],
            "Resource": "*"
        }
    ]
}
```

# Exemples de politiques basées sur l'identité (IAM)
<a name="security-iam-id-policies-examples"></a>

Vous pouvez attacher des politiques à des identités IAM. Par exemple, vous pouvez effectuer les opérations suivantes : 
+ **Associer une politique d'autorisation à un utilisateur ou à un groupe de votre compte** : pour autoriser un utilisateur à consulter les pipelines dans la console, vous pouvez associer une politique d'autorisations à un utilisateur ou à un groupe auquel l'utilisateur appartient.
+ **Attacher une politique d'autorisations à un rôle (accorder des autorisations entre comptes)** : vous pouvez attacher une politique d'autorisation basée sur une identité à un rôle IAM afin d'accorder des autorisations entre comptes. Par exemple, l'administrateur du compte A peut créer un rôle pour accorder des autorisations entre comptes à un autre AWS compte (par exemple, le compte B) ou à un compte Service AWS comme suit :

  1. L'administrateur du Compte A crée un rôle IAM et attache une politique d'autorisation à ce rôle qui accorde des autorisations sur les ressources dans le Compte A.

  1. L'administrateur du Compte A attache une politique d'approbation au rôle identifiant le Compte B comme principal pouvant assumer ce rôle. 

  1. L'administrateur du compte B peut ensuite déléguer les autorisations nécessaires pour assumer le rôle à n'importe quel utilisateur du compte B. Cela permet aux utilisateurs du compte B de créer ou d'accéder aux ressources du compte A. Le principal de la politique de confiance peut également être un Service AWS principal si vous souhaitez accorder l' Service AWS autorisation d'assumer le rôle.

  Pour en savoir plus sur l'utilisation d'IAM pour déléguer des autorisations, consultez [Gestion des accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) dans le *Guide de l'utilisateur IAM*.

Voici un exemple de politique d'autorisation qui accorde des autorisations pour désactiver et activer les transitions entre toutes les étapes du pipeline nommé `MyFirstPipeline` dans le `us-west-2 region` :

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

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement" : [
    {
      "Effect" : "Allow",
      "Action" : [
        "codepipeline:EnableStageTransition",
        "codepipeline:DisableStageTransition"
      ],
      "Resource" : [
        "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline/*"
      ]
    }
  ]
}
```

------

L'exemple suivant montre une politique du compte 111222333444 qui permet aux utilisateurs d'afficher, 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": [
    {
      "Action": [
        "codepipeline:GetPipeline",
        "codepipeline:GetPipelineState",
        "codepipeline:GetPipelineExecution",
        "codepipeline:ListPipelineExecutions",
        "codepipeline:ListActionExecutions",
        "codepipeline:ListActionTypes",
        "codepipeline:ListPipelines",
        "codepipeline:ListTagsForResource",
        "iam:ListRoles",
        "s3:ListAllMyBuckets",
        "codecommit:ListRepositories",
        "codedeploy:ListApplications",
        "lambda:ListFunctions",
        "codestar-notifications:ListNotificationRules",
        "codestar-notifications:ListEventTypes",
        "codestar-notifications:ListTargets"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline"
    },
    {
      "Action": [
        "codepipeline:GetPipeline",
        "codepipeline:GetPipelineState",
        "codepipeline:GetPipelineExecution",
        "codepipeline:ListPipelineExecutions",
        "codepipeline:ListActionExecutions",
        "codepipeline:ListActionTypes",
        "codepipeline:ListPipelines",
        "codepipeline:ListTagsForResource",
        "iam:ListRoles",
        "s3:GetBucketPolicy",
        "s3:GetObject",
        "s3:ListBucket",
        "codecommit:ListBranches",
        "codedeploy:GetApplication",
        "codedeploy:GetDeploymentGroup",
        "codedeploy:ListDeploymentGroups",
        "elasticbeanstalk:DescribeApplications",
        "elasticbeanstalk:DescribeEnvironments",
        "lambda:GetFunctionConfiguration",
        "opsworks:DescribeApps",
        "opsworks:DescribeLayers",
        "opsworks:DescribeStacks"
      ],
      "Effect": "Allow",
      "Resource": "*"
    },
    {
      "Sid": "CodeStarNotificationsReadOnlyAccess",
      "Effect": "Allow",
      "Action": [
        "codestar-notifications:DescribeNotificationRule"
      ],
      "Resource": "*",
      "Condition": {
        "ArnLike": {
          "codestar-notifications:NotificationsForResource": "arn:aws:iam::*:role/Service*"
        }
      }
    }
  ]
}
```

------

Après avoir créé cette politique, créez le rôle IAM dans le compte 111222333444 et associez la politique à ce rôle. Dans les relations de confiance du rôle, vous devez ajouter le AWS compte qui assumera 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 111222333444 :

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

****  

```
{
    "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 111222333444 :

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

****  

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

------

Vous pouvez créer des politiques IAM pour restreindre les appels et les ressources auxquels les utilisateurs de votre compte ont accès, puis associer ces politiques à votre utilisateur administratif. Pour plus d'informations sur la création de rôles IAM et pour découvrir des exemples de déclarations de politique IAM pour, voir. [Exemples de politiques gérées par le client](security_iam_id-based-policy-examples.md#customer-managed-policies) 

# Utilisation de balises pour contrôler l'accès aux CodePipeline ressources
<a name="tag-based-access-control"></a>

Les conditions figurant dans les déclarations de politique IAM font partie de la syntaxe que vous utilisez pour spécifier les autorisations relatives aux ressources requises par CodePipeline les actions. L'utilisation des balises dans les conditions est un moyen de contrôler l'accès aux ressources et demandes. Pour plus d'informations sur le balisage CodePipeline des ressources, consultez[Balisage des ressources](tag-resources.md). Cette rubrique explique le contrôle d'accès basé sur les balises.

Lorsque vous concevez des stratégies IAM, vous pouvez définir des autorisations granulaires en accordant l'accès à des ressources spécifiques. Au fur et à mesure que le nombre de ressources que vous gérez s'accroît, cette tâche devient plus difficile. Le balisage des ressources et l'utilisation de balises dans les déclarations de politique peuvent rendre cette tâche plus facile. Vous accordez l'accès en bloc à toute ressource avec une balise spécifique. Puis, vous appliquez cette balise à plusieurs reprises aux ressources correspondantes, lors de la création ou ultérieurement.

Les balises peuvent être attachées à la ressource ou transmises dans la demande aux services qui prennent en charge le balisage. Dans CodePipeline, les ressources peuvent avoir des balises, et certaines actions peuvent inclure des balises. Lorsque vous créez une politique IAM, vous pouvez utiliser des clés de condition de balise pour contrôler :
+ quels utilisateurs peuvent effectuer des actions sur une ressource de pipeline, en fonction des balises que la ressource possède déjà ;
+ quelles balises peuvent être transmises dans une demande d’action ;
+ si des clés de balise spécifiques peuvent être utilisées dans une demande.

Les opérateurs de condition de chaîne permettent de créer des éléments `Condition` qui limitent l'accès après comparaison d'une clé à une valeur de chaîne. Vous pouvez ajouter `IfExists` à la fin de n'importe quel nom d'opérateur de condition, à l'exception de la condition Null. Ceci équivaut à spécifier que « Si la clé de politique est présente dans le contexte de la demande, la clé doit être traitée comme spécifié dans la politique. Si la clé n'est pas présente, la condition évalue l'élément de condition comme vrai. » Par exemple, vous pouvez utiliser `StringEqualsIfExists` pour restreindre par condition des clés qui peuvent ne pas être présentes sur d'autres types de ressources. 

Pour connaître la syntaxe et la sémantique complètes des clés de condition des balises, consultez la section [Contrôle de l'accès à l'aide](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html) de balises. Pour plus d'informations sur les clés de condition, consultez les ressources suivantes. Les exemples CodePipeline de politique présentés dans cette section s'alignent sur les informations suivantes sur les clés de condition et les développent avec des exemples de nuances, CodePipeline telles que l'imbrication des ressources.
+ [Opérateurs de condition de chaîne](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_String)
+ [Services AWS qui fonctionnent avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)
+ [Syntaxe d’une stratégie de contrôle de service](https://docs.aws.amazon.com/IAM/latest/UserGuide/orgs_manage_policies_scps_syntax.html)
+ [Éléments de politique JSON IAM : Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)
+ [aws : RequestTag /tag-key](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag)
+ [Clés de condition pour CodePipeline](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscodepipeline.html#awscodepipeline-policy-keys)

Les exemples suivants montrent comment spécifier des conditions de balises dans les stratégies pour les utilisateurs CodePipeline .

**Example 1 : Limiter les actions en fonction des balises dans la demande**  
La politique des utilisateurs `AWSCodePipeline_FullAccess` gérés donne aux utilisateurs des autorisations illimitées pour effectuer n'importe quelle CodePipeline action sur n'importe quelle ressource.  
La politique suivante limite ce pouvoir et refuse aux utilisateurs non autorisés l'autorisation de créer des pipelines dans lesquels des balises spécifiques sont répertoriées dans la demande. Pour ce faire, elle refuse l'action `CreatePipeline` si la demande spécifie une balise nommée `Project` avec une valeur `ProjectA` ou `ProjectB`. (La clé de condition `aws:RequestTag` est utilisée pour contrôler les balises qui peuvent être transmises dans une demande IAM.)   
Dans l'exemple suivant, le but de la politique est de refuser aux utilisateurs non autorisés l'autorisation de créer un pipeline avec les valeurs de balise spécifiées. Cependant, la création d'un pipeline nécessite d'accéder à des ressources en plus du pipeline lui-même (par exemple, les actions et les étapes du pipeline). Dans la mesure où la stratégie est `'Resource'` spécifiée`'*'`, la politique est évaluée par rapport à chaque ressource dotée d'un ARN et est créée lors de la création du pipeline. Ces ressources supplémentaires ne disposent pas de la clé de condition du tag, de sorte que la `StringEquals` vérification échoue et que l'utilisateur n'est pas autorisé à créer un pipeline. Pour éviter ce problème, utilisez l'opérateur de condition `StringEqualsIfExists` à la place. De cette façon, le test n'est effectué que si la clé de condition existe.   
Vous pourriez lire ce qui suit : « Si la ressource vérifiée possède une clé de `"RequestTag/Project"` condition de balise, autorisez l'action uniquement si la valeur de la clé commence par`projectA`. Si la ressource en cours de vérification n'est pas dotée de cette clé de condition, peu importe. »   
En outre, la politique empêche ces utilisateurs non autorisés d'altérer les ressources en utilisant la clé de `aws:TagKeys` condition pour empêcher les actions de modification des balises d'inclure ces mêmes valeurs de balise. L'administrateur d'un client doit associer cette politique IAM aux utilisateurs administratifs non autorisés, en plus de la politique des utilisateurs gérés.    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "codepipeline:CreatePipeline",
        "codepipeline:TagResource"
      ],
      "Resource": "*",
      "Condition": {
        "StringEqualsIfExists": {
          "aws:RequestTag/Project": ["ProjectA", "ProjectB"]
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": [
        "codepipeline:UntagResource"
      ],
      "Resource": "*",
      "Condition": {
        "ForAllValues:StringEquals": {
          "aws:TagKeys": ["Project"]
        }
      }
    }
  ]
}
```

**Example 2 : Limitez les actions de balisage en fonction des balises de ressources**  
La politique des utilisateurs `AWSCodePipeline_FullAccess` gérés donne aux utilisateurs des autorisations illimitées pour effectuer n'importe quelle CodePipeline action sur n'importe quelle ressource.  
La stratégie suivante limite cette possibilité et interdit aux utilisateurs non autorisés d'effectuer des actions sur les pipelines de projets spécifiés. Pour ce faire, elle refuse certaines actions si la ressource possède une balise nommée `Project` avec une valeur `ProjectA` ou `ProjectB`. (La clé de condition `aws:ResourceTag` est utilisée pour contrôler l'accès aux ressources en fonction des balises sur ces ressources.) L'administrateur d'un client peut attacher cette stratégie IAM aux utilisateurs IAM non autorisés et à la stratégie d'utilisateur gérée.    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "codepipeline:TagResource"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Project": ["ProjectA", "ProjectB"]
        }
      }
    }
  ]
}
```

**Example 3 : Limiter les actions en fonction des balises dans la demande**  
La stratégie suivante accorde aux utilisateurs l'autorisation de créer des pipelines de développement dans CodePipeline.  
Pour ce faire, elle autorise les actions `CreatePipeline` et `TagResource` si la demande spécifie une balise nommée `Project` avec la valeur `ProjectA`. En d'autres termes, la seule clé de balise qui peut être spécifiée est`Project`, et sa valeur doit être`ProjectA`.  
La clé de `aws:RequestTag` condition est utilisée pour contrôler les balises qui peuvent être transmises dans une demande IAM. La condition `aws:TagKeys` garantit que la clé de balise est sensible à la casse. Cette politique est utile pour les utilisateurs ou les rôles auxquels la politique d'utilisateur `AWSCodePipeline_FullAccess` géré n'est pas attachée. La politique gérée donne aux utilisateurs des autorisations illimitées pour effectuer n'importe quelle CodePipeline action sur n'importe quelle ressource.    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "codepipeline:CreatePipeline",
        "codepipeline:TagResource"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestTag/Project": "ProjectA"
        },
        "ForAllValues:StringEquals": {
          "aws:TagKeys": ["Project"]
        }
      }
    }
  ]
}
```

**Example 4 : Limitez les actions de débalisage en fonction des balises de ressources**  
La politique des utilisateurs `AWSCodePipeline_FullAccess` gérés donne aux utilisateurs des autorisations illimitées pour effectuer n'importe quelle CodePipeline action sur n'importe quelle ressource.  
La stratégie suivante limite cette possibilité et interdit aux utilisateurs non autorisés d'effectuer des actions sur les pipelines de projets spécifiés. Pour ce faire, elle refuse certaines actions si la ressource possède une balise nommée `Project` avec une valeur `ProjectA` ou `ProjectB`.   
La politique empêche également ces utilisateurs non autorisés d'altérer les ressources en utilisant la clé de `aws:TagKeys` condition pour empêcher les actions de modification des balises de supprimer complètement la `Project` balise. L'administrateur d'un client doit associer cette politique IAM à des utilisateurs ou à des rôles non autorisés, en plus de la politique d'utilisateur géré.    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "codepipeline:UntagResource"
      ],
      "Resource": "*",
      "Condition": {
        "ForAllValues:StringEquals": {
          "aws:TagKeys": ["Project"]
        }
      }
    }
  ]
}
```

# Autorisations requises pour utiliser la console
<a name="security-iam-permissions-console"></a>

Pour utiliser dans la console , vous devez disposer d'un ensemble minimal d'autorisations provenant des services suivants :
+ Gestion des identités et des accès AWS
+ Amazon Simple Storage Service

Ces autorisations vous permettent de décrire d'autres AWS ressources pour votre AWS compte.

Selon les autres services que vous intégrez dans vos pipelines, vous devrez peut-être demander des autorisations à un ou plusieurs des services suivants :
+ AWS CodeCommit
+ AWS CodeBuild
+ CloudFormation
+ AWS CodeDeploy
+ AWS Elastic Beanstalk
+ AWS Lambda
+ AWS OpsWorks

Si vous créez une politique IAM plus restrictive que les autorisations minimales requises, la console ne fonctionnera pas comme prévu pour les utilisateurs dotés de cette politique IAM. Pour garantir que ces utilisateurs puissent continuer à utiliser la console, attachez également la stratégie gérée `AWSCodePipeline_ReadOnlyAccess` à l’utilisateur, comme décrit dans [AWS politiques gérées pour AWS CodePipeline](managed-policies.md).

Il n'est pas nécessaire d'accorder des autorisations de console minimales aux utilisateurs qui appellent l'API AWS CLI ou l'API.

# Autorisations requises pour consulter les journaux de calcul dans la console
<a name="security-iam-permissions-console-logs"></a>

Pour consulter les journaux dans le cadre de l'action Commandes sur la CodePipeline console, le rôle de console doit disposer d'autorisations. Pour afficher les journaux dans la console, ajoutez les `logs:GetLogEvents` autorisations au rôle de console.

Dans la déclaration de politique relative au rôle de console, limitez les autorisations au niveau du pipeline, comme indiqué dans l'exemple suivant.

```
{
    "Effect": "Allow",
    "Action": [
        "Action": "logs:GetLogEvents"
    ],
    "Resource": "arn:aws:logs:*:YOUR_AWS_ACCOUNT_ID:log-group:/aws/codepipeline/YOUR_PIPELINE_NAME:*"
}
```

# AWS politiques gérées pour AWS CodePipeline
<a name="managed-policies"></a>





Une politique AWS gérée est une politique autonome créée et administrée par AWS. AWS les politiques gérées sont conçues pour fournir des autorisations pour de nombreux cas d'utilisation courants afin que vous puissiez commencer à attribuer des autorisations aux utilisateurs, aux groupes et aux rôles.

N'oubliez pas que les politiques AWS gérées peuvent ne pas accorder d'autorisations de moindre privilège pour vos cas d'utilisation spécifiques, car elles sont accessibles à tous les AWS clients. Nous vous recommandons de réduire encore les autorisations en définissant des [politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) qui sont propres à vos cas d’utilisation.

Vous ne pouvez pas modifier les autorisations définies dans les politiques AWS gérées. Si les autorisations définies dans une politique AWS gérée sont AWS mises à jour, la mise à jour affecte toutes les identités principales (utilisateurs, groupes et rôles) auxquelles la politique est attachée. AWS est le plus susceptible de mettre à jour une politique AWS gérée lorsqu'une nouvelle politique Service AWS est lancée ou lorsque de nouvelles opérations d'API sont disponibles pour les services existants.

Pour plus d’informations, consultez [Politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) dans le *Guide de l’utilisateur IAM*.

**Important**  
Les politiques `AWSCodePipelineFullAccess` gérées par AWS `AWSCodePipelineReadOnlyAccess` ont été remplacées. Utilisez les `AWSCodePipeline_ReadOnlyAccess` politiques `AWSCodePipeline_FullAccess` et.













## AWS politique gérée : `AWSCodePipeline_FullAccess`
<a name="security-iam-awsmanpol-AWSCodePipeline_FullAccess"></a>





Il s'agit d'une politique qui accorde un accès complet à CodePipeline. Pour consulter le document de politique JSON dans la console IAM, consultez [AWSCodePipeline\$1FullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCodePipeline_FullAccess).



**Détails de l’autorisation**

Cette politique inclut les autorisations suivantes.




+ `codepipeline`— Accorde des autorisations à CodePipeline.
+ `chatbot`— Accorde des autorisations permettant aux principaux de gérer les ressources dans Amazon Q Developer dans des applications de chat.
+ `cloudformation`— Accorde des autorisations permettant aux principaux de gérer les piles de ressources dans. CloudFormation
+ `cloudtrail`— Accorde des autorisations permettant aux principaux de gérer les ressources de connexion. CloudTrail
+ `codebuild`— Accorde des autorisations pour permettre aux principaux d'accéder aux ressources de construction. CodeBuild
+ `codecommit`— Accorde des autorisations permettant aux principaux d'accéder aux ressources sources dans CodeCommit.
+ `codedeploy`— Accorde des autorisations permettant aux principaux d'accéder aux ressources de déploiement dans CodeDeploy.
+ `codestar-notifications`— Accorde des autorisations permettant aux principaux d'accéder aux ressources dans AWS CodeStar les notifications.
+ `ec2`— Accorde des autorisations pour autoriser les déploiements CodeCatalyst afin de gérer l'équilibrage de charge élastique dans Amazon EC2.
+ `ecr`— Accorde des autorisations pour autoriser l'accès aux ressources dans Amazon ECR.
+ `elasticbeanstalk`— Accorde des autorisations permettant aux principaux d'accéder aux ressources dans Elastic Beanstalk.
+ `iam`— Accorde des autorisations permettant aux principaux de gérer les rôles et les politiques dans IAM.
+ `lambda`— Accorde des autorisations permettant aux principaux de gérer les ressources dans Lambda.
+ `events`— Accorde des autorisations permettant aux principaux de gérer les ressources dans CloudWatch Events.
+ `opsworks`— Accorde des autorisations permettant aux principaux de gérer les ressources dans AWS OpsWorks.
+ `s3`— Accorde des autorisations permettant aux principaux de gérer les ressources dans Amazon S3.
+ `sns`— Accorde des autorisations permettant aux principaux de gérer les ressources de notification dans Amazon SNS.
+ `states`— Accorde des autorisations permettant aux principaux de visualiser les machines d'état dans AWS Step Functions lesquelles ils se trouvent. Une machine à états consiste en un ensemble d'états qui gèrent les tâches et la transition entre les états.

Pour la politique, voir [AWSCodePipeline\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodePipeline_FullAccess.html). 

## AWS politique gérée : `AWSCodePipeline_ReadOnlyAccess`
<a name="security-iam-awsmanpol-AWSCodePipeline_ReadOnlyAccess"></a>





Il s'agit d'une politique qui accorde un accès en lecture seule à. CodePipeline Pour consulter le document de politique JSON dans la console IAM, consultez [AWSCodePipeline\$1ReadOnlyAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCodePipeline_ReadOnlyAccess).



**Détails de l’autorisation**

Cette politique inclut les autorisations suivantes.




+ `codepipeline`— Accorde des autorisations aux actions dans CodePipeline.
+ `codestar-notifications`— Accorde des autorisations permettant aux principaux d'accéder aux ressources dans AWS CodeStar les notifications.
+ `s3`— Accorde des autorisations permettant aux principaux de gérer les ressources dans Amazon S3.
+ `sns`— Accorde des autorisations permettant aux principaux de gérer les ressources de notification dans Amazon SNS.

Pour la politique, voir [AWSCodePipeline\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodePipeline_ReadOnlyAccess.html).



## AWS politique gérée : `AWSCodePipelineApproverAccess`
<a name="security-iam-awsmanpol-AWSCodePipeline_Approver"></a>





Il s'agit d'une politique qui autorise l'approbation ou le rejet d'une action d'approbation manuelle. Pour consulter le document de politique JSON dans la console IAM, consultez [AWSCodePipelineApproverAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCodePipelineApproverAccess).



**Détails de l’autorisation**

Cette politique inclut les autorisations suivantes.




+ `codepipeline`— Accorde des autorisations aux actions dans CodePipeline.

Pour la politique, voir [AWSCodePipelineApproverAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodePipelineApproverAccess.html).

## AWS politique gérée : `AWSCodePipelineCustomActionAccess`
<a name="security-iam-awsmanpol-AWSCodePipelineCustomActionAccess"></a>





Il s'agit d'une politique qui autorise la création d'actions personnalisées CodePipeline ou l'intégration des ressources Jenkins pour les actions de création ou de test. Pour consulter le document de politique JSON dans la console IAM, consultez [AWSCodePipelineCustomActionAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSCodePipelineCustomActionAccess).



**Détails de l’autorisation**

Cette politique inclut les autorisations suivantes.




+ `codepipeline`— Accorde des autorisations aux actions dans CodePipeline.

Pour la politique, voir [AWSCodePipelineCustomActionAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCodePipelineCustomActionAccess.html).

## CodePipeline politiques et notifications gérées
<a name="notifications-permissions"></a>

CodePipeline prend en charge les notifications, qui peuvent informer les utilisateurs des modifications importantes apportées aux pipelines. Les politiques gérées CodePipeline incluent des déclarations de politique relatives à la fonctionnalité de notification. Pour plus d'informations, consultez [En quoi consistent les notifications ?](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/welcome.html)

### Autorisations liées aux notifications dans les stratégies gérées d'accès complet
<a name="notifications-fullaccess"></a>

Cette politique gérée accorde des autorisations CodePipeline ainsi que les services CodeCommit, CodeBuild CodeDeploy, et AWS CodeStar notifications associés. La politique accorde également les autorisations dont vous avez besoin pour travailler avec d'autres services intégrés à vos pipelines, tels qu'Amazon S3, Elastic CloudTrail Beanstalk, Amazon EC2 et. CloudFormation Les utilisateurs auxquels cette politique gérée est appliquée peuvent également créer et gérer des sujets Amazon SNS pour les notifications, abonner et désinscrire des utilisateurs à des sujets, répertorier les sujets à choisir comme cibles pour les règles de notification et répertorier Amazon Q Developer dans les applications de chat clientes configurées pour Slack.

La stratégie gérée `AWSCodePipeline_FullAccess` inclut les déclarations suivantes pour permettre un accès complet aux notifications. 

```
    {
        "Sid": "CodeStarNotificationsReadWriteAccess",
        "Effect": "Allow",
        "Action": [
            "codestar-notifications:CreateNotificationRule",
            "codestar-notifications:DescribeNotificationRule",
            "codestar-notifications:UpdateNotificationRule",
            "codestar-notifications:DeleteNotificationRule",
            "codestar-notifications:Subscribe",
            "codestar-notifications:Unsubscribe"
        ],
        "Resource": "*",
        "Condition" : {
            "StringLike" : {"codestar-notifications:NotificationsForResource" : "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline"} 
        }
    },    
    {
        "Sid": "CodeStarNotificationsListAccess",
        "Effect": "Allow",
        "Action": [
            "codestar-notifications:ListNotificationRules",
            "codestar-notifications:ListTargets",
            "codestar-notifications:ListTagsforResource",
            "codestar-notifications:ListEventTypes"
        ],
        "Resource": "*"
    },
    {
        "Sid": "CodeStarNotificationsSNSTopicCreateAccess",
        "Effect": "Allow",
        "Action": [
            "sns:CreateTopic",
            "sns:SetTopicAttributes"
        ],
        "Resource": "arn:aws:sns:*:*:codestar-notifications*"
    },
    {
        "Sid": "SNSTopicListAccess",
        "Effect": "Allow",
        "Action": [
            "sns:ListTopics"
        ],
        "Resource": "*"
    },
    {
        "Sid": "CodeStarNotificationsChatbotAccess",
        "Effect": "Allow",
        "Action": [
            "chatbot:DescribeSlackChannelConfigurations",
            "chatbot:ListMicrosoftTeamsChannelConfigurations"
          ],
       "Resource": "*"
    }
```

### Autorisations liées aux notifications dans les stratégies gérées en lecture seule
<a name="notifications-readonly"></a>

La stratégie gérée `AWSCodePipeline_ReadOnlyAccess` inclut les déclarations suivantes pour autoriser l'accès en lecture seule aux notifications. Les utilisateurs auxquels s'applique cette stratégie peuvent voir des notifications pour les ressources, mais ne peuvent pas les créer, les gérer ni s'y abonner. 

```
   {
        "Sid": "CodeStarNotificationsPowerUserAccess",
        "Effect": "Allow",
        "Action": [
            "codestar-notifications:DescribeNotificationRule"
        ],
        "Resource": "*",
        "Condition" : {
            "StringLike" : {"codestar-notifications:NotificationsForResource" : "arn:aws:codepipeline:us-west-2:111222333444:MyFirstPipeline"} 
        }
    },    
    {
        "Sid": "CodeStarNotificationsListAccess",
        "Effect": "Allow",
        "Action": [
            "codestar-notifications:ListNotificationRules",
            "codestar-notifications:ListEventTypes",
            "codestar-notifications:ListTargets"
        ],
        "Resource": "*"
    }
```

Pour plus d'informations sur l'IAM et les notifications, consultez [Identity and Access Management for AWS CodeStar Notifications](https://docs.aws.amazon.com/codestar-notifications/latest/userguide/security-iam.html).

## AWS CodePipeline mises à jour des politiques AWS gérées
<a name="security-iam-awsmanpol-updates"></a>



Consultez les détails des mises à jour des politiques AWS gérées CodePipeline depuis que ce service a commencé à suivre ces modifications. Pour recevoir des alertes automatiques concernant les modifications apportées à cette page, abonnez-vous au flux RSS sur la CodePipeline Page historique du document [https://docs.aws.amazon.com/codepipeline/latest/userguide/history.html](https://docs.aws.amazon.com/codepipeline/latest/userguide/history.html).




| Modifier | Description | Date | 
| --- | --- | --- | 
| [AWSCodePipeline\$1FullAccess](#security-iam-awsmanpol-AWSCodePipeline_FullAccess)— Mises à jour de la politique existante | CodePipeline a ajouté une autorisation à cette politique pour la prise ListStacks en charge dans CloudFormation. | 15 mars 2024 | 
| [AWSCodePipeline\$1FullAccess](#security-iam-awsmanpol-AWSCodePipeline_FullAccess)— Mises à jour de la politique existante | Cette politique a été mise à jour afin d'ajouter des autorisations pour Amazon Q Developer dans les applications de chat. Pour de plus amples informations, veuillez consulter [CodePipeline politiques et notifications gérées](#notifications-permissions). | 21 juin 2023 | 
|  [AWSCodePipeline\$1FullAccess](#security-iam-awsmanpol-AWSCodePipeline_FullAccess)et politiques [AWSCodePipeline\$1ReadOnlyAccess](#security-iam-awsmanpol-AWSCodePipeline_ReadOnlyAccess)gérées — Mises à jour de la politique existante  |  CodePipeline a ajouté une autorisation à ces politiques pour prendre en charge un type de notification supplémentaire utilisant Amazon Q Developer dans les applications de chat,`chatbot:ListMicrosoftTeamsChannelConfigurations`.   | 16 mai 2023 | 
|  **AWSCodePipelineFullAccess** : obsolète  |  Cette stratégie a été remplacée par `AWSCodePipeline_FullAccess`. Après le 17 novembre 2022, cette politique ne pourra plus être associée à de nouveaux utilisateurs, groupes ou rôles. Pour de plus amples informations, veuillez consulter [AWS politiques gérées pour AWS CodePipeline](#managed-policies).  | 17 novembre 2022 | 
|  **AWSCodePipelineReadOnlyAccess** : obsolète  |  Cette stratégie a été remplacée par `AWSCodePipeline_ReadOnlyAccess`. Après le 17 novembre 2022, cette politique ne pourra plus être associée à de nouveaux utilisateurs, groupes ou rôles. Pour de plus amples informations, veuillez consulter [AWS politiques gérées pour AWS CodePipeline](#managed-policies).  | 17 novembre 2022 | 
|  CodePipeline a commencé à suivre les modifications  |  CodePipeline a commencé à suivre les modifications apportées AWS à ses politiques gérées.  | 12 mars 2021 | 

## 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"
        }
    ]
}
```

------

# AWS CodePipeline exemples de politiques basées sur les ressources
<a name="security_iam_resource-based-policy-examples"></a>

**Topics**

D’autres services, tels qu’Amazon S3, prennent également en charge les politiques d’autorisation basées sur une ressource. Par exemple, vous pouvez attacher une politique à un compartiment S3 pour gérer les autorisations d’accès à ce compartiment. Bien qu'il CodePipeline ne prenne pas en charge les politiques basées sur les ressources, il stocke les artefacts à utiliser dans des pipelines dans des compartiments S3 versionnés. 

**Example Pour créer une politique pour un compartiment S3 à utiliser comme magasin d'artefacts pour CodePipeline**  
Vous pouvez utiliser n'importe quel compartiment S3 versionné comme magasin d'artefacts pour. CodePipeline Si vous utilisez l'assistant **Création d'un pipeline** pour créer votre premier pipeline, ce compartiment S3 est créé automatiquement pour garantir que tous les objets chargés dans le magasin d'artefacts sont chiffrés et que les connexions au compartiment sont sécurisées. Si vous créez votre propre compartiment S3, pensez à ajouter la stratégie suivante ou ses éléments au compartiment, à titre de bonne pratique. Dans cette stratégie, l'ARN du compartiment S3 est `codepipeline-us-east-2-1234567890`. Remplacez cet ARN par l'ARN de votre compartiment S3 :    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Id": "SSEAndSSLPolicy",
    "Statement": [
        {
            "Sid": "DenyUnEncryptedObjectUploads",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
            "Condition": {
                "StringNotEquals": {
                    "s3:x-amz-server-side-encryption": "aws:kms"
                }
            }
        },
        {
            "Sid": "DenyInsecureConnections",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
            "Condition": {
                "Bool": {
                    "aws:SecureTransport": false
                }
            }
        }
    ]
}
```

# Résolution des problèmes AWS CodePipeline d'identité et d'accès
<a name="security_iam_troubleshoot"></a>

Utilisez les informations suivantes pour vous aider à diagnostiquer et à résoudre les problèmes courants que vous pouvez rencontrer lorsque vous travaillez avec CodePipeline IAM.

**Topics**
+ [Je ne suis pas autorisé à effectuer une action dans CodePipeline](#security_iam_troubleshoot-no-permissions)
+ [Je ne suis pas autorisé à effectuer iam : PassRole](#security_iam_troubleshoot-passrole)
+ [Je suis administrateur et je souhaite autoriser d'autres personnes à accéder CodePipeline](#security_iam_troubleshoot-admin-delegate)
+ [Je souhaite autoriser des personnes extérieures à mon AWS compte à accéder à mes CodePipeline ressources](#security_iam_troubleshoot-cross-account-access)

## Je ne suis pas autorisé à effectuer une action dans CodePipeline
<a name="security_iam_troubleshoot-no-permissions"></a>

S'il vous AWS Management Console indique que vous n'êtes pas autorisé à effectuer une action, vous devez contacter votre administrateur pour obtenir de l'aide. Votre administrateur est la personne qui vous a fourni votre nom d'utilisateur et votre mot de passe.

L'exemple d'erreur suivant se produit lorsque l'utilisateur `mateojackson` IAM essaie d'utiliser la console pour afficher les détails d'un pipeline, mais ne dispose pas des `codepipeline:GetPipeline` autorisations nécessaires.

```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: codepipeline:GetPipeline on resource: my-pipeline
```

Dans ce cas, Mateo demande à son administrateur de mettre à jour ses politiques pour lui permettre d’accéder à la ressource `my-pipeline` à l’aide de l’action `codepipeline:GetPipeline`.

## Je ne suis pas autorisé à effectuer iam : PassRole
<a name="security_iam_troubleshoot-passrole"></a>

Si vous recevez un message d'erreur indiquant que vous n'êtes pas autorisé à exécuter l'action `iam:PassRole`, vous devez contacter votre administrateur pour obtenir de l'aide. Votre administrateur est la personne qui vous a fourni votre nom d'utilisateur et votre mot de passe. Demandez à cette personne de mettre à jour vos politiques pour vous permettre de transmettre un rôle à CodePipeline.

Certains vous Services AWS permettent de transmettre un rôle existant à ce service, au lieu de créer un nouveau rôle de service ou un rôle lié à un service. Pour ce faire, vous devez disposer des autorisations nécessaires pour transmettre le rôle au service.

L’exemple d’erreur suivant se produit lorsqu’un utilisateur IAM nommé `marymajor` essaie d’utiliser la console pour exécuter une action dans CodePipeline. Toutefois, l'action nécessite que le service ait des autorisations accordées par une fonction du service. Mary ne dispose pas des autorisations nécessaires pour transférer le rôle au service.

```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```

Dans ce cas, Mary demande à son administrateur de mettre à jour ses politiques pour lui permettre d'exécuter l'action `iam:PassRole`.

## Je suis administrateur et je souhaite autoriser d'autres personnes à accéder CodePipeline
<a name="security_iam_troubleshoot-admin-delegate"></a>

Pour autoriser d'autres personnes à y accéder CodePipeline, vous devez accorder l'autorisation aux personnes ou aux applications qui ont besoin d'y accéder. Si vous utilisez AWS IAM Identity Center pour gérer des personnes et des applications, vous attribuez des ensembles d'autorisations aux utilisateurs ou aux groupes afin de définir leur niveau d'accès. Les ensembles d'autorisations créent et attribuent automatiquement des politiques IAM aux rôles IAM associés à la personne ou à l'application. Pour plus d'informations, consultez la section [Ensembles d'autorisations](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) dans le *guide de AWS IAM Identity Center l'utilisateur*.

Si vous n'utilisez pas IAM Identity Center, vous devez créer des entités IAM (utilisateurs ou rôles) pour les personnes ou les applications qui ont besoin d'un accès. Vous devez ensuite associer une politique à l'entité qui leur accorde les autorisations appropriées dans CodePipeline. Une fois les autorisations accordées, fournissez les informations d'identification à l'utilisateur ou au développeur de l'application. Ils utiliseront ces informations d'identification pour y accéder AWS. Pour en savoir plus sur la création d'utilisateurs, de groupes, de politiques et d'autorisations [IAM, consultez la section Identités](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html), [politiques et autorisations IAM dans le guide de l'utilisateur *IAM*](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html).

## Je souhaite autoriser des personnes extérieures à mon AWS compte à accéder à mes CodePipeline ressources
<a name="security_iam_troubleshoot-cross-account-access"></a>

Vous pouvez créer un rôle que les utilisateurs provenant d’autres comptes ou les personnes extérieures à votre organisation pourront utiliser pour accéder à vos ressources. Vous pouvez spécifier qui est autorisé à assumer le rôle. Pour les services qui prennent en charge les politiques basées sur les ressources ou les listes de contrôle d'accès (ACLs), vous pouvez utiliser ces politiques pour autoriser les utilisateurs à accéder à vos ressources.

Pour plus d’informations, consultez les éléments suivants :
+ Pour savoir si ces fonctionnalités sont prises CodePipeline en charge, consultez[Comment AWS CodePipeline fonctionne avec IAM](security_iam_service-with-iam.md).
+ Pour savoir comment fournir l'accès à vos ressources sur celles Comptes AWS que vous possédez, consultez la section [Fournir l'accès à un utilisateur IAM dans un autre utilisateur Compte AWS que vous possédez](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) dans le Guide de l'*utilisateur IAM*.
+ Pour savoir comment fournir l'accès à vos ressources à des tiers Comptes AWS, consultez la section [Fournir un accès à des ressources Comptes AWS détenues par des tiers](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) dans le *guide de l'utilisateur IAM*.
+ Pour savoir comment fournir un accès par le biais de la fédération d’identité, consultez [Fournir un accès à des utilisateurs authentifiés en externe (fédération d’identité)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) dans le *Guide de l’utilisateur IAM*.
+ Pour en savoir plus sur la différence entre l’utilisation des rôles et des politiques basées sur les ressources pour l’accès intercompte, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.

# référence des autorisations
<a name="permissions-reference"></a>

Utilisez le tableau suivant comme référence lorsque vous configurez le contrôle d'accès et que vous rédigez des politiques d'autorisation que vous pouvez associer à une identité IAM (politiques basées sur l'identité). Ce tableau répertorie chaque opération d'API et les actions correspondantes pour lesquelles vous pouvez accorder des autorisations. Pour les opérations qui prennent en charge *les autorisations au niveau des ressources*, le tableau répertorie les AWS ressources pour lesquelles vous pouvez accorder les autorisations. Vous spécifiez les actions dans le champ `Action` de la politique.

Les *autorisations au niveau des ressources* vous permettent de spécifier les ressources sur lesquelles les utilisateurs sont autorisés à effectuer des actions. AWS CodePipeline fournit une prise en charge partielle des autorisations au niveau des ressources. Cela signifie que pour certains appels d' AWS CodePipeline API, vous pouvez contrôler le moment où les utilisateurs sont autorisés à utiliser ces actions en fonction des conditions qui doivent être remplies ou des ressources que les utilisateurs sont autorisés à utiliser. Par exemple, vous pouvez accorder aux utilisateurs l'autorisation d'afficher des informations d'exécution de pipeline, mais uniquement pour un ou plusieurs pipelines spécifiques.

**Note**  
La colonne **Ressources** répertorie la ressource requise pour les appels d'API qui prennent en charge les autorisations de niveau ressource. Pour les appels d'API qui ne prennent pas en charge les autorisations au niveau des ressources, vous pouvez accorder aux utilisateurs l'autorisation de l'utiliser, mais vous devez spécifier un caractère générique (\$1) pour l'élément ressource de votre déclaration de stratégie.




**Opérations d'API et autorisations requises pour les actions**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codepipeline/latest/userguide/permissions-reference.html)

# Gérer le rôle CodePipeline de service
<a name="how-to-custom-role"></a>

Le rôle de service est configuré avec une ou plusieurs politiques qui contrôlent l'accès aux AWS ressources utilisées par le pipeline. Vous souhaiterez peut-être associer d'autres politiques à ce rôle, modifier la politique attachée au rôle ou configurer des politiques pour d'autres rôles de service dans AWS. Vous pouvez également attacher une stratégie à un rôle lorsque vous configurez l'accès entre comptes à votre pipeline.

**Important**  
Le fait de modifier une déclaration de stratégie ou d'associer une autre stratégie au rôle peut nuire au fonctionnement de vos pipelines. Assurez-vous de bien tenir compte de tout ce qu'implique une modification du rôle de service pour . Veillez à tester vos pipelines après avoir modifié le rôle de service.

**Note**  
Dans la console, les rôles de service créés avant septembre 2018 sont créés avec le nom `oneClick_AWS-CodePipeline-Service_ID-Number`.  
Les rôles de service créés après septembre 2018 utilisent le format de nom de rôle de service `AWSCodePipelineServiceRole-Region-Pipeline_Name`. Par exemple, pour un pipeline nommé `MyFirstPipeline` dans`eu-west-2`, la console nomme le rôle et la politique`AWSCodePipelineServiceRole-eu-west-2-MyFirstPipeline`.

## CodePipeline politique relative aux rôles de service
<a name="how-to-custom-role-policy"></a>

La déclaration de politique relative aux rôles de CodePipeline service contient les autorisations minimales pour la gestion des pipelines. Vous pouvez modifier l'énoncé du rôle de service pour supprimer ou ajouter l'accès aux ressources que vous n'utilisez pas. Consultez la référence d'action appropriée pour connaître les autorisations minimales requises CodePipeline utilisées pour chaque action.

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

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowS3BucketAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetBucketVersioning",
        "s3:GetBucketAcl",
        "s3:GetBucketLocation"
      ],
      "Resource": [
        "arn:aws:s3:::[[pipeArtifactBucketNames]]"
      ],
      "Condition": {
        "StringEquals": {
          "aws:ResourceAccount": "{{accountId}}"
        }
      }
    },
    {
      "Sid": "AllowS3ObjectAccess",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:PutObjectAcl",
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:PutObjectTagging",
        "s3:GetObjectTagging",
        "s3:GetObjectVersionTagging"
      ],
      "Resource": [
        "arn:aws:s3:::[[pipeArtifactBucketNames]]/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:ResourceAccount": "{{accountId}}"
        }
      }
    }
  ]
}
```

------

**Note**  
Dans la politique, les autorisations suivantes sont requises lorsque les objets S3 de votre compartiment source contiennent des balises :   

```
s3:PutObjectTagging
s3:GetObjectTagging
s3:GetObjectVersionTagging
```

## Supprimer les autorisations associées au rôle CodePipeline de service
<a name="remove-permissions-from-policy"></a>

Vous pouvez modifier la déclaration du rôle de service pour supprimer l'accès aux ressources que vous n'utilisez pas. Par exemple, si aucun de vos pipelines n'inclut Elastic Beanstalk, vous pouvez modifier la déclaration de politique afin de supprimer la section qui autorise l'accès aux ressources Elastic Beanstalk.

De même, si aucun de vos pipelines ne l'inclut CodeDeploy, vous pouvez modifier la déclaration de politique pour supprimer la section qui accorde l'accès aux CodeDeploy ressources :

```
    {
    "Action": [
        "codedeploy:CreateDeployment",
        "codedeploy:GetApplicationRevision",
        "codedeploy:GetDeployment",
        "codedeploy:GetDeploymentConfig",
        "codedeploy:RegisterApplicationRevision"
    ],
    "Resource": "*",
    "Effect": "Allow"
},
```

## Ajouter des autorisations au rôle CodePipeline de service
<a name="how-to-update-role-new-services"></a>

Vous devez mettre à jour votre déclaration de politique de rôle de service avec des autorisations pour une déclaration de politique de rôle de service qui n'est Service AWS pas déjà incluse dans la déclaration de politique de rôle de service par défaut avant de pouvoir l'utiliser dans vos pipelines.

Cela est particulièrement important si le rôle de service que vous utilisez pour vos pipelines a été créé avant que le support ne soit ajouté à un Service AWS.

Le tableau suivant indique à quel moment le support a été ajouté pour les autres Services AWS. 


****  

| Service AWS | CodePipeline date de support | 
| --- | --- | 
| CodePipeline le support d'action invoque a été ajouté. Consultez [Politique des rôles de service et autorisations pour l' CodePipeline action d'appel](action-reference-PipelineInvoke.md#action-reference-PipelineInvoke-permissions-action). | 14 mars 2025 | 
|  EC2support d'action ajouté. Consultez [Autorisations de politique de rôle de service pour l'action de déploiement EC2](action-reference-EC2Deploy.md#action-reference-EC2Deploy-permissions-action). | 21 février 2025 | 
|  EKSsupport d'action ajouté. Consultez [Autorisations relatives à la politique des rôles de](action-reference-EKS.md#action-reference-EKS-service-role). | 20 février 2025 | 
|  La prise en charge des ECRBuildAndPublish actions Amazon Elastic Container Registry a été ajoutée. Consultez [Autorisations relatives aux rôles de service : `ECRBuildAndPublish` action](action-reference-ECRBuildAndPublish.md#edit-role-ECRBuildAndPublish). | 22 novembre 2024 | 
| La prise en charge des InspectorScan actions Amazon Inspector a été ajoutée. Consultez [Autorisations relatives aux rôles de service : `InspectorScan` action](action-reference-InspectorScan.md#edit-role-InspectorScan). | 22 novembre 2024 | 
| Ajout du support d'action des commandes. Consultez [Autorisations relatives aux rôles de service : action des commandes](action-reference-Commands.md#edit-role-Commands). | 3 octobre 2024 | 
| CloudFormation support d'action ajouté. Consultez [Autorisations relatives aux rôles de service : `CloudFormationStackSet` action](action-reference-StackSets.md#edit-role-cfn-stackset) et [Autorisations relatives aux rôles de service : `CloudFormationStackInstances` action](action-reference-StackSets.md#edit-role-cfn-stackinstances). | 30 décembre 2020 | 
| CodeCommit support d'action complet au format d'artefact de sortie par clone ajouté. Consultez [Autorisations relatives aux rôles de service : CodeCommit action](action-reference-CodeCommit.md#edit-role-codecommit). | 11 novembre 2020 | 
| AWS CodeBuild Ajout d'un support d'action pour les builds par lots. Consultez [Autorisations relatives aux rôles de service : CodeCommit action](action-reference-CodeCommit.md#edit-role-codecommit). | 30 juillet 2020 | 
| AWS AppConfig support d'action ajouté. Consultez [Autorisations relatives aux rôles de service : `AppConfig` action](action-reference-AppConfig.md#edit-role-appconfig). | 22 juin 2020 | 
| AWS Step Functions support d'action ajouté. Consultez [Autorisations relatives aux rôles de service : `StepFunctions` action](action-reference-StepFunctions.md#edit-role-stepfunctions). | 27 mai 2020 | 
| AWS CodeStar Ajout de la prise en charge des actions de connexion. Consultez [Autorisations relatives aux rôles de service : CodeConnections action](action-reference-CodestarConnectionSource.md#edit-role-connections). | 18 décembre 2019 | 
| Ajout de la prise en charge des actions de déploiement dans S3. Consultez [Autorisations relatives aux rôles de service : action de déploiement S3](action-reference-S3Deploy.md#edit-role-s3deploy). | 16 janvier 2019 | 
| Le support CodeDeployToECS d'action a été ajouté. Consultez [Autorisations relatives aux rôles de service : `CodeDeployToECS` action](action-reference-ECSbluegreen.md#edit-role-codedeploy-ecs). | 27 novembre 2018 | 
| Le support d'action Amazon ECR a été ajouté. Consultez [Autorisations relatives aux rôles de service : action Amazon ECR](action-reference-ECR.md#edit-role-ecr). | 27 novembre 2018 | 
| La prise en charge des actions du Service Catalog a été ajoutée. Consultez [Autorisations relatives aux rôles de service : action Service Catalog](action-reference-ServiceCatalog.md#edit-role-servicecatalog). | 16 octobre 2018 | 
| AWS Device Farm support d'action ajouté. Consultez [Autorisations relatives aux rôles de service : AWS Device Farm action](action-reference-DeviceFarm.md#edit-role-devicefarm). | 19 juillet 2018 | 
| Le support d'action Amazon ECS a été ajouté. Consultez [Autorisations relatives aux rôles de service : action standard d'Amazon ECS](action-reference-ECS.md#edit-role-ecs). | 12 décembre 2017/ Mise à jour concernant l'acceptation de l'autorisation de marquage le 21 juillet 2017 | 
| CodeCommit support d'action ajouté. Consultez [Autorisations relatives aux rôles de service : CodeCommit action](action-reference-CodeCommit.md#edit-role-codecommit). | 18 avril 2016 | 
| AWS OpsWorks support d'action ajouté. Consultez [Autorisations relatives aux rôles de service : AWS OpsWorks action](action-reference-OpsWorks.md#edit-role-opsworks). | 2 juin 2016 | 
| CloudFormation support d'action ajouté. Consultez [Autorisations relatives aux rôles de service : CloudFormation action](action-reference-CloudFormation.md#edit-role-cloudformation). | 3 novembre 2016 | 
| AWS CodeBuild support d'action ajouté. Consultez [Autorisations relatives aux rôles de service : CodeBuild action](action-reference-CodeBuild.md#edit-role-codebuild). | 1er décembre 2016 | 
| Le support d'action Elastic Beanstalk a été ajouté. Consultez [Autorisations relatives aux rôles de service : action de `ElasticBeanstalk` déploiement](action-reference-Beanstalk.md#edit-role-beanstalk). | Lancement initial du service | 
| CodeDeploy support d'action ajouté. Consultez [Autorisations relatives aux rôles de service : AWS CodeDeploy action](action-reference-CodeDeploy.md#edit-role-codedeploy). | Lancement initial du service | 
| Ajout de la prise en charge des actions source S3. Consultez [Autorisations relatives aux rôles de service : action source S3](action-reference-S3.md#edit-role-s3source). | Lancement initial du service | 

Procédez comme suit pour ajouter des autorisations pour un service pris en charge :

 

1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.

1. Dans le volet de navigation de la console IAM, sélectionnez **Rôles**, puis choisissez votre `AWS-CodePipeline-Service` rôle dans la liste des rôles.

1. Dans l'onglet **Autorisations**, dans **Politiques intégrées, dans la ligne** correspondant à votre politique de rôle de service, choisissez **Modifier la politique**.

1. Ajoutez les autorisations requises dans la zone du **document de politique**. 
**Note**  
Lorsque vous créez des politiques IAM, suivez les conseils de sécurité standard qui consistent à accorder le moindre privilège, c'est-à-dire à n'accorder que les autorisations nécessaires à l'exécution d'une tâche. Certains appels d'API prennent en charge les autorisations basées sur les ressources et autorisent la limitation d'accès. Par exemple, dans ce cas, pour limiter les autorisations lors de l'appel de `DescribeTasks` et de `ListTasks`, vous pouvez remplacer le caractère générique (\$1) par un ARN de ressource ou par un ARN de ressource contenant un caractère générique (\$1). Pour plus d'informations sur la création d'une politique accordant un accès avec le moindre privilège, consultez. [https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)

1. Choisissez **Examiner une stratégie** afin de vérifier que la stratégie ne contient aucune erreur. Lorsque la politique est exempte d'erreurs, choisissez **Appliquer** la politique.

# Connexion et surveillance CodePipeline
<a name="incident-response"></a>

Vous pouvez utiliser les fonctionnalités de connexion AWS pour déterminer les actions effectuées par les utilisateurs sur votre compte et les ressources utilisées. Les fichiers journaux affichent :
+ La date et l'heure des actions
+ L'adresse IP source d'une action
+ Les actions qui ont échoué en raison d'autorisations inadaptées

Les fonctionnalités de journalisation sont disponibles dans les catégories suivantes Services AWS :
+ AWS CloudTrail peut être utilisé pour enregistrer les appels AWS d'API et les événements connexes effectués par ou pour le compte d'un Compte AWS. Pour de plus amples informations, veuillez consulter [Journalisation des appels d' CodePipeline API avec AWS CloudTrail](monitoring-cloudtrail-logs.md).
+ Amazon CloudWatch Events peut être utilisé pour surveiller vos AWS Cloud ressources et les applications que vous utilisez AWS. Vous pouvez créer des alertes dans Amazon CloudWatch Events en fonction des métriques que vous définissez. Pour de plus amples informations, veuillez consulter [Surveillance des CodePipeline événements](detect-state-changes-cloudwatch-events.md).

# Validation de conformité pour AWS CodePipeline
<a name="compliance-validation"></a>

Pour savoir si un [programme Services AWS de conformité Service AWS s'inscrit dans le champ d'application de programmes de conformité](https://aws.amazon.com/compliance/services-in-scope/) spécifiques, consultez Services AWS la section de conformité et sélectionnez le programme de conformité qui vous intéresse. Pour des informations générales, voir Programmes de [AWS conformité Programmes AWS](https://aws.amazon.com/compliance/programs/) de .

Vous pouvez télécharger des rapports d'audit tiers à l'aide d'un artefact. Pour plus d'informations, voir [Téléchargement de rapports dans AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html) .

Votre responsabilité en matière de conformité lors de l'utilisation Services AWS est déterminée par la sensibilité de vos données, les objectifs de conformité de votre entreprise et les lois et réglementations applicables. Pour plus d'informations sur votre responsabilité en matière de conformité lors de l'utilisation Services AWS, consultez [AWS la documentation de sécurité](https://docs.aws.amazon.com/security/).

# Résilience dans AWS CodePipeline
<a name="disaster-recovery-resiliency"></a>

L'infrastructure AWS mondiale est construite autour des AWS régions et des zones de disponibilité. AWS Les régions fournissent plusieurs zones de disponibilité physiquement séparées et isolées, connectées par un réseau à faible latence, à haut débit et hautement redondant. Avec les zones de disponibilité, vous pouvez concevoir et exploiter des applications et des bases de données qui basculent automatiquement d’une zone à l’autre sans interruption. Les zones de disponibilité sont davantage disponibles, tolérantes aux pannes et ont une plus grande capacité de mise à l’échelle que les infrastructures traditionnelles à un ou plusieurs centres de données. 

Pour plus d'informations sur AWS les régions et les zones de disponibilité, consultez la section [Infrastructure AWS mondiale](https://aws.amazon.com/about-aws/global-infrastructure/).

# Sécurité de l'infrastructure dans AWS CodePipeline
<a name="infrastructure-security"></a>

En tant que service géré, AWS CodePipeline il est protégé par la sécurité du réseau AWS mondial. Pour plus d'informations sur les services AWS de sécurité et sur la manière dont AWS l'infrastructure est protégée, consultez la section [Sécurité du AWS cloud](https://aws.amazon.com/security/). Pour concevoir votre AWS environnement en utilisant les meilleures pratiques en matière de sécurité de l'infrastructure, consultez la section [Protection de l'infrastructure](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) dans le cadre * AWS bien architecturé du pilier de sécurité*.

Vous utilisez des appels d'API AWS publiés pour accéder CodePipeline via le réseau. Les clients doivent prendre en charge les éléments suivants :
+ Protocole TLS (Transport Layer Security). Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Ses suites de chiffrement PFS (Perfect Forward Secrecy) comme DHE (Ephemeral Diffie-Hellman) ou ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). La plupart des systèmes modernes tels que Java 7 et les versions ultérieures prennent en charge ces modes.

# Bonnes pratiques de sécurité
<a name="security-best-practices"></a>



**Topics**

CodePipeline fournit un certain nombre de fonctionnalités de sécurité à prendre en compte lors de l'élaboration et de la mise en œuvre de vos propres politiques de sécurité. Les bonnes pratiques suivantes doivent être considérées comme des instructions générales et ne représentent pas une solution de sécurité complète. Étant donné que ces bonnes pratiques peuvent ne pas être appropriées ou suffisantes pour votre environnement, considérez-les comme des remarques utiles plutôt que comme des recommandations.

Vous utilisez des processus de chiffrement et d'authentification pour les référentiels source qui se connectent à vos pipelines. Voici les CodePipeline meilleures pratiques en matière de sécurité :
+ Si vous créez une configuration de pipeline ou d'action qui doit inclure des secrets, tels que des jetons ou des mots de passe, n'entrez pas de secrets directement dans la configuration de l'action, ni les valeurs par défaut des variables définies au niveau du pipeline ou de la CloudFormation configuration, car les informations s'afficheront dans les journaux. Utilisez Secrets Manager pour configurer et stocker les secrets, puis utilisez le secret référencé dans le pipeline et la configuration des actions, comme décrit dans[AWS Secrets Manager À utiliser pour suivre les mots de passe de base de données ou les clés d'API tierces](parameter-store-encryption.md).
+ Si vous créez un pipeline qui utilise un compartiment source S3, configurez le chiffrement côté serveur pour les artefacts stockés dans Amazon S3 en les CodePipeline gérant AWS KMS keys, comme décrit dans. [Configurer le chiffrement côté serveur pour les artefacts stockés dans Amazon S3 pour CodePipeline](S3-artifact-encryption.md)
+ Si vous utilisez le fournisseur d'action Jenkins, lorsque vous utilisez un fournisseur de génération Jenkins pour l'action de génération ou de test de votre pipeline, installez Jenkins sur une instance EC2 et configurez un profil d'instance EC2 distinct. Assurez-vous que le profil d'instance accorde à Jenkins uniquement les AWS autorisations nécessaires pour effectuer des tâches relatives à votre projet, telles que la récupération de fichiers depuis Amazon S3. Pour apprendre à créer le rôle pour votre profil d'instance Jenkins, consultez les étapes de [Créez un rôle IAM à utiliser pour l'intégration de Jenkins](tutorials-four-stage-pipeline.md#tutorials-four-stage-pipeline-prerequisites-jenkins-iam-role).