Authentification et contrôle d'accès pour AWS CodeCommit

L'accès à AWS CodeCommit requiert des informations d'identifications. Ces informations d'identification doivent être autorisées à accéder aux AWS ressources, telles que CodeCommit les référentiels, et à votre utilisateur IAM, que vous utilisez pour gérer vos informations d'identification Git ou la clé publique SSH que vous utilisez pour établir des connexions Git. Les sections suivantes fournissent des informations détaillées sur la manière dont vous pouvez utiliser AWS Identity and Access Management(IAM) et CodeCommit pour sécuriser l'accès à vos ressources :

• Authentification

• Contrôle d'accès

Authentification

Étant donné que CodeCommit les référentiels sont basés sur Git et prennent en charge les fonctionnalités de base de Git, y compris les informations d'identification Git, nous vous recommandons d'utiliser un utilisateur IAM lorsque vous travaillez avec. CodeCommit Vous pouvez y accéder CodeCommit avec d'autres types d'identité, mais les autres types d'identité sont soumis à des restrictions, comme décrit ci-dessous.

Type d'identité :

• Utilisateur IAM : un utilisateur IAM est une identité au sein de votre compte Amazon Web Services dotée d'autorisations personnalisées spécifiques. Par exemple, un utilisateur IAM peut être autorisé à créer et à gérer les informations d'identification Git pour accéder aux CodeCommit référentiels. Il s'agit du type d'utilisateur recommandé pour travailler avec CodeCommit. Vous pouvez utiliser un nom d'utilisateur et un mot de passe IAM pour vous connecter aux pages web AWS sécurisées telles que la AWS Management Console, les forums de discussion AWS ou le centre AWS Support.

  Vous pouvez générer des informations d'identification Git ou associer des clés publiques SSH à votre utilisateur IAM, ou vous pouvez les installer et les configurer. git-remote-codecommit Il s'agit des méthodes les plus simples pour configurer Git pour qu'il fonctionne avec vos CodeCommit référentiels. Avec les informations d'identification Git, vous générez un nom d'utilisateur et un mot de passe statiques dans IAM. Ensuite, vous utilisez ces informations pour les connexions HTTPS avec Git et n'importe quel outil tiers prenant en charge l'authentification par nom d'utilisateur et mot de passe Git. Avec les connexions SSH, vous créez des fichiers de clés publiques et privées sur votre machine locale que Git CodeCommit utilise pour l'authentification SSH. Vous associez la clé publique à votre utilisateur IAM et vous stockez la clé privée sur votre machine locale. git-remote-codecommitétend Git lui-même et ne nécessite pas de configurer les informations d'identification Git pour l'utilisateur.

  En outre, vous pouvez générer des clés d'accès pour chaque utilisateur. Utilisez ces clés lorsque vous accédez aux services AWS par programmation soit via l'un des kits SDK AWS, soit à l'aide de l'AWS Command Line Interface (AWS CLI). Les kits SDK et les outils de l'interface de ligne de commande utilisent les clés d'accès pour chiffrer la signature des demandes. Si vous n'utilisez pas les outils AWS, vous devez signer les demandes vous-même. CodeCommit prend en charge Signature Version 4, un protocole permettant d'authentifier les demandes d'API entrantes. Pour plus d'informations sur l'authentification des demandes, consultez Processus de signature Signature Version 4 dans le document Références générales AWS.

• Utilisateur root du compte Amazon Web Services : lorsque vous vous inscrivezAWS, vous fournissez une adresse e-mail et un mot de passe associés à votre compte Amazon Web Services. Il s'agit de vos informations d'identification racine et elles fournissent un accès complet à l'ensemble de vos ressources AWS. Certaines CodeCommit fonctionnalités ne sont pas disponibles pour les utilisateurs de comptes root. En outre, la seule façon d'utiliser Git avec votre compte racine est d'installer et de configurer git-remote-codecommit (recommandé) ou de configurer l'assistant d'informations d'identification AWS, qui est inclus avec l'AWS CLI. Vous ne pouvez pas utiliser les informations d'identification Git ni les paires de clés publiques/privées SSH avec votre compte utilisateur racine. Pour ces raisons, nous vous déconseillons d'utiliser l'utilisateur de votre compte root lorsque vous interagissez avec CodeCommit.

  Important

  Pour des raisons de sécurité, nous vous conseillons d'utiliser les informations d'identification racine uniquement pour créer un utilisateur administrateur, qui est un utilisateur IAM disposant des autorisations complètes sur votre compte AWS. Vous pouvez ensuite utiliser cet utilisateur administrateur pour créer d'autres utilisateurs IAM et des rôles dotés d'autorisations limitées. Pour plus d'informations, consultez Bonnes pratiques IAM et Création d'un utilisateurs administrateur et d'un groupe dans le Guide de l'utilisateur IAM.

• IAM Identity Center et utilisateurs d'IAM Identity Center : AWS IAM Identity Center élargit les capacités de AWS Identity and Access Management afin de fournir un espace central regroupant l'administration des utilisateurs et leur accès aux applications Comptes AWS cloud. Bien que recommandé comme bonne pratique pour la plupart des utilisateursAWS, IAM Identity Center ne fournit actuellement aucun mécanisme pour les informations d'identification Git ou les paires de clés SSH. Ces utilisateurs peuvent installer et configurer git-remote-codecommit pour cloner des CodeCommit référentiels en local, mais tous les environnements de développement intégrés (IDE) ne prennent pas en charge le clonage, le transfert ou l'extraction. git-remote-codecommit

  Demandez aux utilisateurs humains, et notamment aux utilisateurs qui nécessitent un accès administrateur, d’appliquer la bonne pratique consistant à utiliser une fédération avec fournisseur d’identité pour accéder à Services AWS en utilisant des informations d’identification temporaires.

  Une identité fédérée est un utilisateur de l’annuaire des utilisateurs de votre entreprise, un fournisseur d’identité Web, l’AWS Directory Service, l’annuaire Identity Centerou tout utilisateur qui accède à Services AWS en utilisant des informations d’identification fournies via une source d’identité. Quand des identités fédérées accèdent à Comptes AWS, elles endossent des rôles, ces derniers fournissant des informations d’identification temporaires.

  Pour une gestion des accès centralisée, nous vous recommandons d’utiliser AWS IAM Identity Center. Vous pouvez créer des utilisateurs et des groupes dans IAM Identity Center, ou vous connecter et vous synchroniser avec un ensemble d’utilisateurs et de groupes dans votre propre source d’identité pour une utilisation sur l’ensemble de vos applications et de vos Comptes AWS. Pour obtenir des informations sur IAM Identity Center, consultez Qu’est-ce que IAM Identity Center ? dans le Guide de l’utilisateur AWS IAM Identity Center.

• Rôle IAM — Tout comme un utilisateur IAM, un rôle IAM est une identité IAM que vous pouvez créer dans votre compte pour accorder des autorisations spécifiques.

  Un rôle IAM est une entité au sein de votre Compte AWS qui dispose d’autorisations spécifiques. Le concept ressemble à celui d’utilisateur IAM, mais le rôle IAM n’est pas associé à une personne en particulier. Vous pouvez temporairement endosser un rôle IAM dans la AWS Management Console en changeant de rôle. Vous pouvez obtenir un rôle en appelant une opération d’API AWS CLI ou AWS à l’aide d’une URL personnalisée. Pour plus d’informations sur les méthodes d’utilisation des rôles, consultez Utilisation de rôles IAM dans le Guide de l’utilisateur IAM.

  Les rôles IAM avec des informations d’identification temporaires sont utiles dans les cas suivants :

  • Accès utilisateur fédéré – Pour attribuer des autorisations à une identité fédérée, vous créez un rôle et définissez des autorisations pour le rôle. Quand une identité externe s’authentifie, l’identité est associée au rôle et reçoit les autorisations qui sont définies par celui-ci. Pour obtenir des informations sur les rôles pour la fédération, consultez Création d’un rôle pour un fournisseur d’identité tiers (fédération) dans le Guide de l’utilisateur IAM. Si vous utilisez IAM Identity Center, vous configurez un jeu d’autorisations. IAM Identity Center met en corrélation le jeu d’autorisations avec un rôle dans IAM afin de contrôler à quoi vos identités peuvent accéder après leur authentification. Pour plus d’informations sur les jeux d’autorisations, consultez Jeux d’autorisations dans le Guide de l’utilisateur AWS IAM Identity Center.

  • Autorisations d’utilisateur IAM temporaires : un rôle ou un utilisateur IAM peut endosser un rôle IAM pour profiter temporairement d’autorisations différentes pour une tâche spécifique.

  • Accès intercompte : vous pouvez utiliser un rôle IAM pour permettre à un utilisateur (principal de confiance) d’un compte différent d’accéder aux ressources de votre compte. Les rôles constituent le principal moyen d’accorder l’accès intercompte. Toutefois, certains Services AWS vous permettent d’attacher une politique directement à une ressource (au lieu d’utiliser un rôle en tant que proxy). Pour en savoir plus sur la différence entre les rôles et les politiques basées sur les ressources pour l’accès intercompte, consultez Différence entre les rôles IAM et les politiques basées sur les ressources dans le Guide de l’utilisateur IAM.

  • Accès interservices : certains Services AWS utilisent des fonctionnalités dans d’autres Services AWS. Par exemple, lorsque vous effectuez un appel dans un service, il est courant que ce service exécute des applications dans Amazon EC2 ou stocke des objets dans Amazon S3. Un service peut le faire en utilisant les autorisations d’appel du principal, une fonction de service ou un rôle lié au service.

    • Sessions de transmission d’accès (FAS) : lorsque vous vous servez d’un utilisateur ou d’un rôle IAM pour accomplir des actions dans AWS, vous êtes considéré comme un principal. Lorsque vous utilisez certains services, vous pouvez effectuer une action qui initie une autre action dans un autre service. FAS utilise les autorisations du principal appelant un Service AWS, associées au Service AWS demandeur pour adresser des demandes aux services situés en aval. Les demandes FAS ne sont formulées que lorsqu'un service reçoit une demande qui, pour aboutir, a besoin d'interagir avec d'autres ressources ou Services AWS. Dans ce cas, vous devez disposer d’autorisations nécessaires pour effectuer les deux actions. Pour plus de détails sur la politique relative à la transmission de demandes FAS, consultez la section Sessions de transmission d’accès.

    • Fonction du service : il s’agit d’un rôle IAM attribué à un service afin de réaliser des actions en votre nom. Un administrateur IAM peut créer, modifier et supprimer une fonction du service à partir d’IAM. Pour plus d’informations, consultez Création d’un rôle pour la délégation d’autorisations à un Service AWS dans le Guide de l’utilisateur IAM.

    • Rôle lié au service – Un rôle lié au service est un type de fonction du service lié à un Service AWS. Le service peut endosser le rôle afin d’effectuer une action en votre nom. Les rôles liés à un service s’affichent dans votre Compte AWS et sont détenus par le service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations concernant les rôles liés à un service.

  • Applications s’exécutant sur Amazon EC2 : vous pouvez utiliser un rôle IAM pour gérer des informations d’identification temporaires pour les applications s’exécutant sur une instance EC2 et effectuant des demandes d’API AWS CLI ou AWS. Cette solution est préférable au stockage des clés d’accès au sein de l’instance EC2. Pour attribuer un rôle AWS à une instance EC2 et le rendre disponible à toutes les applications associées, vous pouvez créer un profil d’instance attaché à l’instance. Un profil d’instance contient le rôle et permet aux programmes qui s’exécutent sur l’instance EC2 d’obtenir des informations d’identification temporaires. Pour plus d’informations, consultez Utilisation d’un rôle IAM pour accorder des autorisations à des applications s’exécutant sur des instances Amazon EC2 dans le Guide de l’utilisateur IAM.

  Pour savoir dans quel cas utiliser des rôles ou des utilisateurs IAM, consultez Quand créer un rôle IAM (au lieu d’un utilisateur) dans le Guide de l’utilisateur IAM.

  Note

  Vous ne pouvez pas utiliser les informations d'identification Git ni les paires de clés publiques/privées SSH avec les utilisateur fédérés. En outre, les préférences utilisateur ne sont pas disponibles pour les utilisateurs fédérés. Pour plus d'informations sur la configuration des connexions à l'aide de l'accès fédéré, consultez Étapes de configuration pour les connexions HTTPS àAWS CodeCommitavecgit-remote-codecommit.

Contrôle d'accès

Vous pouvez disposer d'informations d'identification valides pour authentifier vos demandes, mais vous ne pouvez pas créer de CodeCommit ressources ou y accéder sans autorisation. Par exemple, vous devez disposer des autorisations requises pour afficher les référentiels, transmettre le code, créer et gérer les informations d'identification Git, etc.

Les sections suivantes décrivent comment gérer les autorisations pour CodeCommit. Nous vous recommandons de lire d'abord la présentation.

• Vue d'ensemble de la gestion des autorisations d'accès à vos CodeCommit ressources

• Utilisation de politiques basées sur l'identité (politiques IAM) pour CodeCommit

• Référence des autorisations CodeCommit

Vue d'ensemble de la gestion des autorisations d'accès à vos CodeCommit ressources

Chaque AWS ressource est détenue par un compte Amazon Web Services. Les autorisations pour créer ou accéder à un ressource sont gérées par des stratégies d'autorisations. Un compte administrateur peut attacher des politiques d'autorisations à des identités IAM (c'est-à-dire des utilisateurs, des groupes et des rôles). Certains services, comme AWS Lambda, prennent également en charge l'attachement de stratégies d'autorisation aux ressources.

Note

Un administrateur de compte (ou utilisateur administrateur) est un utilisateur doté des privilèges d'administrateur. Pour plus d'informations, consultez Bonnes pratiques IAM dans le Guide de l'utilisateur IAM.

Lorsque vous accordez des autorisations, vous décidez qui les reçoit, à quelles ressources ces autorisations s'appliquent et les actions spécifiques que vous souhaitez autoriser sur ces ressources.

CodeCommit ressources et opérations

Dans CodeCommit, la ressource principale est un référentiel. Chaque ressource possède un Amazon Resource Name (ARN) associé unique. Dans une politique, vous utilisez un Amazon Resource Name (ARN) pour identifier la ressource à laquelle la politique s'applique. Pour plus d'informations générales sur les ARN, consultez Amazon Resource Name (ARN)AWS et Espaces de noms dans le manuel Référence générale d'Amazon Web Services. CodeCommit ne prend actuellement pas en charge les autres types de ressources, appelés sous-ressources.

Le tableau suivant décrit comment spécifier les CodeCommit ressources.

Type de ressource	Format ARN
Référentiel.	arn:aws:codecommit:region:account-id:repository-name
Tous les CodeCommit référentiels	arn:aws:codecommit:*
Tous les CodeCommit référentiels détenus par le compte spécifié dans le Région AWS	arn:aws:codecommit:region:account-id:*

Note

La plupart des services AWS interprètent de la même manière les signes deux points (:) et barre oblique (/) dans les ARN. Cependant, CodeCommit cela nécessite une correspondance exacte dans les modèles de ressources et les règles. Lors de la création de modèles d'événements, veillez à utiliser les caractères ARN corrects afin qu'ils correspondent à la syntaxe ARN de la ressource.

Par exemple, vous pouvez indiquer un référentiel spécifique (MyDemoRepo) dans votre instruction à l'aide de son ARN comme suit :

"Resource": "arn:aws:codecommit:us-west-2:111111111111:MyDemoRepo"

Pour spécifier tous les référentiels appartenant à un compte spécifique, utilisez le caractère générique (*) comme suit :

"Resource": "arn:aws:codecommit:us-west-2:111111111111:*"

Pour spécifier toutes les ressources, ou si une action d'API spécifique ne prend pas en charge les ARN, utilisez le caractère générique * dans l'élément Resource, comme suit :

"Resource": "*"

Vous pouvez également utiliser le caractère générique (*) pour spécifier toutes les ressources qui correspondent à une partie du nom du référentiel. Par exemple, l'ARN suivant indique tout CodeCommit référentiel qui commence par le nom MyDemo et qui est enregistré sur le compte Amazon Web Services 111111111111 dans le us-east-2 Région AWS :

arn:aws:codecommit:us-east-2:111111111111:MyDemo*

Pour obtenir la liste des opérations disponibles qui fonctionnent avec les CodeCommit ressources, consultezRéférence des autorisations CodeCommit.

Présentation de la propriété des ressources

Le compte Amazon Web Services possède les ressources créées dans le compte, quel que soit leur créateur. Plus précisément, le propriétaire de la ressource est le compte Amazon Web Services de l'entité principale (c'est-à-dire le compte root, un utilisateur IAM ou un rôle IAM) qui authentifie la demande de création de ressource. Les exemples suivants illustrent comment cela fonctionne :

• Si vous créez un utilisateur IAM dans votre compte Amazon Web Services et que vous accordez des autorisations pour créer CodeCommit des ressources à cet utilisateur, celui-ci peut créer des CodeCommit ressources. Toutefois, votre compte Amazon Web Services, auquel appartient l'utilisateur, est propriétaire des CodeCommit ressources.

• Si vous utilisez les informations d'identification du compte root de votre compte Amazon Web Services pour créer une règle, votre compte Amazon Web Services est le propriétaire de la CodeCommit ressource.

• Si vous créez un rôle IAM dans votre compte Amazon Web Services avec l'autorisation de créer des CodeCommit ressources, toute personne habilitée à assumer ce rôle peut créer des CodeCommit ressources. Votre compte Amazon Web Services, auquel appartient le rôle, possède les CodeCommit ressources.

Gestion de l'accès aux ressources

Pour gérer l'accès aux ressources AWS, vous pouvez utiliser des stratégies d'autorisation. Une permissions policy (politique d'autorisation) décrit qui a accès à quoi. La section suivante explique les options disponibles pour créer des stratégies d'autorisation.

Note

Cette section décrit l'utilisation d'IAM dans le contexte de CodeCommit. Elle ne fournit pas d'informations détaillées sur le service IAM. Pour plus d'informations sur l'IAM, voir Qu'est-ce que l'IAM ? dans le guide de l'utilisateur IAM. Pour plus d'informations sur la syntaxe et les descriptions des stratégies IAM, consultez Référence de stratégie IAM dans le Guide de l'utilisateur IAM.

Les politiques d'autorisation associées à une identité IAM sont appelées politiques basées sur l'identité (politiques IAM). Les stratégies d'autorisation qui sont associées à une ressource sont des stratégies basées sur la ressource. Actuellement, ne CodeCommit prend en charge que les politiques basées sur l'identité (politiques IAM).

Rubriques

• Politiques basées sur une identité (politiques IAM)
• Politiques basées sur les ressources

Politiques basées sur une identité (politiques IAM)

Pour gérer l'accès aux AWS ressources, vous devez associer des politiques d'autorisation aux identités IAM. Dans CodeCommit, vous utilisez des politiques basées sur l'identité pour contrôler l'accès aux référentiels. 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 CodeCommit ressources dans la CodeCommit console, associez une politique d'autorisation basée sur l'identité à un utilisateur ou à un groupe auquel l'utilisateur appartient.

• Associer une politique d'autorisation à un rôle (pour accorder des autorisations entre comptes) : la délégation, par exemple lorsque vous souhaitez accorder un accès entre comptes, implique la mise en place d'une relation de confiance entre le compte propriétaire de la ressource (le compte de confiance) et le compte contenant les utilisateurs devant accéder à la ressource (le compte de confiance). Une stratégie d'autorisation accorde à l'utilisateur d'un rôle les autorisations nécessaires pour exécuter les tâches prévues sur la ressource. Une stratégie d'approbation détermine les comptes approuvés autorisés à accorder à leurs utilisateurs les autorisations nécessaires pour assumer le rôle. Pour plus d'informations, consultez la section Termes et concepts de l'IAM.

  Pour accorder des autorisations entre comptes, associez une politique d'autorisation basée sur l'identité à un rôle IAM. Par exemple, l'administrateur du compte A peut créer un rôle pour accorder des autorisations entre comptes à un autre compte Amazon Web Services (par exemple, le compte B) ou à un AWS service 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.

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

  3. L'administrateur du compte B peut alors déléguer les autorisations pour affecter ce rôle à tous les utilisateurs figurant dans le compte B. Les utilisateurs du compte B sont ainsi autorisés à créer des ressources ou à y accéder dans le compte A. Si vous souhaitez accorder à un service AWS l'autorisation d'assumer ce rôle, le principal dans la stratégie d'approbation peut également être un principal du service AWS. Pour plus d'informations, consultez la section Délégation dans les termes et concepts de l'IAM.

  Pour en savoir plus sur l'utilisation d'IAM pour déléguer des autorisations, consultez Gestion des accès dans le Guide de l'utilisateur IAM.

L'exemple suivant de stratégie permet à un utilisateur de créer une branche dans un référentiel nommé MyDemoRepo :

{
  "Version": "2012-10-17",
  "Statement" : [
    {
      "Effect" : "Allow",
      "Action" : [
        "codecommit:CreateBranch"
      ],
      "Resource" : "arn:aws:codecommit:us-east-2:111111111111:MyDemoRepo"
    }
  ]
}

Pour restreindre les appels et les ressources auxquels les utilisateurs de votre compte ont accès, créez des politiques IAM spécifiques, puis associez ces politiques aux utilisateurs IAM. Pour plus d'informations sur la façon de créer des rôles IAM et pour découvrir des exemples de déclarations de politique IAM pour CodeCommit, voir. Exemples de politiques d'identité gérées par le client

Politiques basées sur les ressources

Certains services, tels qu'Amazon S3, prennent également en charge les politiques d'autorisation basées sur les ressources. Par exemple, vous pouvez associer une politique basée sur les ressources à un compartiment S3 afin de gérer les autorisations d'accès à ce compartiment. CodeCommit ne prend pas en charge les politiques basées sur les ressources, mais vous pouvez utiliser des balises pour identifier les ressources, que vous pouvez ensuite utiliser dans les politiques IAM. Pour obtenir un exemple d'une stratégie basée sur les balises, consultez Politiques basées sur une identité (politiques IAM).

Délimitation des ressources dans CodeCommit

Dans CodeCommit, vous pouvez définir les politiques basées sur l'identité et les autorisations d'accès aux ressources, comme décrit dans. CodeCommit ressources et opérations Cependant, vous ne pouvez pas spécifier l'autorisation ListRepositories pour une ressource. Au lieu de cela, vous devez la définir pour toutes les ressources (en utilisant le caractère générique *). Sinon, l'action échoue.

Toutes les autres CodeCommit autorisations peuvent être étendues aux ressources.

Spécification des éléments d'une politique : ressources, actions, effets et mandataires

Vous pouvez créer des politiques pour autoriser ou refuser aux utilisateurs l'accès aux ressources, ou autoriser ou refuser aux utilisateurs d'effectuer des actions spécifiques sur ces ressources. CodeCommit définit un ensemble d'opérations d'API publiques qui définissent la manière dont les utilisateurs travaillent avec le service, que ce soit par le biais de la CodeCommit console, des SDKAWS CLI, de ou en appelant directement ces API. Pour accorder des autorisations pour ces opérations d'API CodeCommit , définissez un ensemble d'actions que vous pouvez spécifier dans une politique.

Certaines opérations d'API nécessitent des autorisations pour plusieurs actions. Pour plus d'informations sur les ressources et les opérations de l'API, consultez CodeCommit ressources et opérations et Référence des autorisations CodeCommit.

Voici les éléments de base d'une stratégie :

• Ressource : pour identifier la ressource à laquelle la politique s'applique, vous utilisez un Amazon Resource Name (ARN). Pour plus d'informations, consultez CodeCommit ressources et opérations.

• Action : pour identifier les opérations sur les ressources que vous souhaitez autoriser ou refuser, vous utilisez des mots clés d'action. Par exemple, en fonction de ce qui est spécifiéEffect, l'codecommit:GetBranchautorisation autorise ou refuse à l'utilisateur d'effectuer l'GetBranchopération, qui permet d'obtenir des informations sur une branche d'un CodeCommit référentiel.

• Effet : vous spécifiez l'effet, qu'il s'agisse d'autoriser ou de refuser, qui se produit lorsque l'utilisateur demande l'action spécifique. Si vous n'accordez pas explicitement l'accès pour (autoriser) une ressource, l'accès est implicitement refusé. Vous pouvez aussi explicitement refuser l'accès à une ressource afin de vous assurer qu'un utilisateur n'y a pas accès, même si une stratégie différente accorde cet accès.

• Principal — Dans les politiques basées sur l'identité (politiques IAM), le seul type de politique CodeCommit compatible, l'utilisateur auquel la politique est attachée est le principal implicite.

Pour en savoir plus sur la syntaxe des politiques IAM, consultez la référence des politiques IAM dans le guide de l'utilisateur IAM.

Pour un tableau présentant toutes les actions d' CodeCommit API et les ressources auxquelles elles s'appliquent, consultezRéférence des autorisations CodeCommit.

Spécification de conditions dans une politique

Lorsque vous accordez des autorisations, vous utilisez le langage de politique d'accès d'IAM pour spécifier les conditions dans lesquelles une politique doit prendre effet. Par exemple, il est possible d'appliquer une politique après seulement une date spécifique. Pour plus d'informations sur la spécification de conditions dans un langage de politique, consultez la section Grammaire des conditions et des politiques dans le guide de l'utilisateur IAM.

Pour exprimer des conditions, vous utilisez des clés de condition prédéfinies. Il n'existe pas de clés de condition spécifiques à CodeCommit. Il existe, toutefois, des clés de condition à l'échelle d'AWS que vous pouvez utiliser selon vos besoins. Pour obtenir la liste complète des clés à l'échelle d’AWS, consultez Clés disponibles pour les conditions dans le Guide de l'utilisateur IAM.