AWS CodeCommit n'est plus disponible pour les nouveaux clients. Les clients existants de AWS CodeCommit peuvent continuer à utiliser le service normalement. En savoir plus »
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.
Exemples de politiques gérées par le client
Vous pouvez créer vos propres politiques IAM personnalisées pour autoriser les CodeCommit actions et les ressources. Vous pouvez attacher ces politiques personnalisées aux utilisateurs ou groupes IAM qui nécessitent ces autorisations. Vous pouvez également créer vos propres politiques IAM personnalisées pour l'intégration entre les services CodeCommit et d'autres AWS services.
Exemples de politiques d'identité gérées par le client
Les exemples de politiques IAM suivants accordent des autorisations pour diverses CodeCommit actions. Utilisez-les pour limiter CodeCommit l'accès à vos utilisateurs et rôles IAM. Ces politiques contrôlent la capacité à effectuer des actions avec la CodeCommit console AWS SDKs, l'API ou le AWS CLI.
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 : Autoriser un utilisateur à effectuer des CodeCommit opérations en une seule fois Région AWS
La politique d'autorisation suivante utilise un caractère générique ("codecommit:*"
) pour permettre aux utilisateurs d'effectuer toutes les CodeCommit actions dans la région us-east-2 et non depuis une autre région. Régions AWS
Exemple 2 : autoriser un utilisateur à utiliser Git pour un seul dépôt
Dans CodeCommit, les autorisations de la politique GitPull
IAM s'appliquent à toutes les commandes du client Git à partir desquelles les données sont extraites CodeCommit git fetchgit clone, y compris, etc. De même, les autorisations de la politique GitPush
IAM s'appliquent à toutes les commandes du client Git auxquelles les données sont envoyées CodeCommit. Par exemple, si l'autorisation de politique GitPush
IAM est définie surAllow
, un utilisateur peut demander la suppression d'une branche à l'aide du protocole Git. Ce push n'est pas affecté par les autorisations appliquées à l'DeleteBranch
opération pour cet utilisateur IAM. L'DeleteBranch
autorisation s'applique aux actions effectuées avec la console, le AWS CLI SDKs, et l'API, mais pas avec le protocole Git.
L'exemple suivant permet à l'utilisateur spécifié d'extraire du CodeCommit référentiel nommé et de le transférer vers celui-ci MyDemoRepo
:
Exemple 3 : autoriser un utilisateur se connectant à partir d'une plage d'adresses IP spécifiée à accéder à un référentiel
Vous pouvez créer une stratégie qui permet uniquement aux utilisateurs de se connecter à un référentiel CodeCommit si leur adresse IP se trouve dans une plage d'adresses IP spécifique. Il existe deux approches également valables. Vous pouvez créer une Deny
politique qui interdit les CodeCommit opérations si l'adresse IP de l'utilisateur ne se trouve pas dans un bloc spécifique, ou vous pouvez créer une Allow
politique qui autorise les CodeCommit opérations si l'adresse IP de l'utilisateur se trouve dans un bloc spécifique.
Vous pouvez créer une stratégie Deny
qui refuse l'accès à tous les utilisateurs qui ne font pas partie d'une plage d'adresses IP spécifique. Par exemple, vous pouvez attacher la stratégie gérée AWSCodeCommitPowerUser et une stratégie gérée par le client à tous les utilisateurs qui ont besoin d'accéder à votre référentiel. L'exemple de politique suivant refuse toutes les CodeCommit autorisations aux utilisateurs dont les adresses IP ne se trouvent pas dans le bloc d'adresses IP 203.0.113.0/16 spécifié :
L'exemple de politique suivant permet à l'utilisateur spécifié d'accéder à un CodeCommit référentiel nommé MyDemoRepo avec les autorisations équivalentes à celles de la politique AWSCode CommitPowerUser gérée uniquement si son adresse IP se trouve dans le bloc d'adresses spécifié 203.0.113.0/16 :
Exemple 4 : refuser ou autoriser des actions sur les branches
Vous pouvez créer une stratégie qui refuse aux utilisateurs les autorisations pour les actions que vous spécifiez sur une ou plusieurs branches. Sinon, vous pouvez créer une stratégie qui autorise des actions sur une ou plusieurs branches qui n'auraient pas été possibles dans d'autres branches d'un référentiel. Vous pouvez utiliser ces stratégies avec les stratégies gérées appropriées (prédéfinies). Pour de plus amples informations, veuillez consulter Limitez les pushs et les fusions vers les succursales AWS CodeCommit.
Par exemple, vous pouvez créer une Deny
politique qui empêche les utilisateurs d'apporter des modifications à une branche nommée main, y compris de supprimer cette branche, dans un référentiel nomméMyDemoRepo
. Vous pouvez utiliser cette stratégie avec la stratégie gérée AWSCodeCommitPowerUser. Les utilisateurs auxquels ces deux politiques sont appliquées pourraient créer et supprimer des branches, créer des pull requests et effectuer toutes les autres actions autorisées AWSCodeCommitPowerUser, mais ils ne seraient pas en mesure d'apporter des modifications à la branche nommée main, d'ajouter ou de modifier un fichier dans la branche principale de la CodeCommit console, ni de fusionner des branches ou une pull request dans la branche principale. Comme Deny
est appliqué à GitPush
, vous devez inclure une instruction Null
dans la stratégie, afin d'autoriser l'analyse de validité des appels GitPush
initiaux lorsque les utilisateurs effectuent des transmissions à partir de leurs référentiels locaux.
Astuce
Si vous souhaitez créer une politique qui s'applique à toutes les branches nommées main dans tous les référentiels de votre compte Amazon Web ServicesResource
, spécifiez un astérisque (*
) au lieu d'un ARN de référentiel.
L'exemple de politique suivant permet à un utilisateur d'apporter des modifications à une branche nommée main dans tous les référentiels d'un compte Amazon Web Services. Il ne permet pas de modifier d'autres branches. Vous pouvez utiliser cette politique avec la politique AWSCode CommitReadOnly gérée pour autoriser les transferts automatisés vers le référentiel de la branche principale. Comme Effect a la valeur Allow
, cet exemple de stratégie ne fonctionne pas avec les stratégies gérées comme AWSCodeCommitPowerUser.
Exemple 5 : refuser ou autoriser des actions sur des référentiels contenant des balises
Vous pouvez créer une politique qui autorise ou refuse les actions sur les référentiels en fonction des AWS balises associées à ces référentiels, puis appliquer ces politiques aux groupes IAM que vous configurez pour gérer les utilisateurs IAM. Par exemple, vous pouvez créer une politique qui refuse toute CodeCommit action sur les référentiels dotés de la clé de AWS balise Status et de la valeur clé Secret, puis appliquer cette politique au groupe IAM que vous avez créé pour les développeurs généraux ()Developers
. Vous devez ensuite vous assurer que les développeurs travaillant sur ces référentiels balisés ne sont pas membres de ce Developers
groupe général, mais appartiennent plutôt à un autre groupe IAM auquel la politique restrictive n'est pas appliquée () SecretDevelopers.
L'exemple suivant refuse toutes les CodeCommit actions sur les référentiels marqués avec la clé Status et la valeur clé Secret :
Vous pouvez affiner davantage cette stratégie en spécifiant des référentiels spécifiques, plutôt que tous les référentiels, en tant que ressources. Vous pouvez également créer des politiques qui autorisent CodeCommit des actions sur tous les référentiels qui ne sont pas marqués par des balises spécifiques. Par exemple, la politique suivante autorise l'équivalent d'AWSCodeCommitPowerUserautorisations pour les CodeCommit actions, sauf qu'elle autorise uniquement les CodeCommit actions sur les référentiels non balisés avec les balises spécifiées :
Note
Cet exemple de stratégie inclut uniquement les actions pour CodeCommit. Il n'inclut pas les actions relatives AWS aux autres services inclus dans la politique AWSCodeCommitPowerUsergérée. Pour plus d'informations, consultez. AWS politique gérée : AWSCode CommitPowerUser.