Accorder des autorisations autogérées

Cette rubrique fournit des instructions sur la façon de créer les rôles de service IAM nécessaires StackSets au déploiement sur plusieurs comptes et Régions AWS avec des autorisations autogérées. Ces rôles sont nécessaires pour établir une relation de confiance entre le compte StackSet depuis lequel vous gérez et le compte sur lequel vous déployez des instances de stack. À l'aide de ce modèle d'autorisations, vous StackSets pouvez effectuer un déploiement sur n'importe quel appareil Compte AWS dans lequel vous êtes autorisé à créer un rôle IAM.

Pour utiliser des autorisations gérées par le service, consultez Activer l’accès approuvé à la place.

Self-managed vue d'ensemble des autorisations

Avant de créer un StackSet avec des autorisations autogérées, vous devez avoir créé des rôles de service IAM dans chaque compte.

Les étapes de base sont les suivantes :

Autorisation accordée à tous les utilisateurs du compte administrateur de gérer les piles dans tous les comptes cibles

Cette section explique comment configurer des autorisations pour permettre à tous les utilisateurs et à tous les groupes du compte administrateur d'effectuer StackSet des opérations sur tous les comptes cibles. Elle vous guide dans la création des rôles de service IAM requis dans vos comptes administrateur et cible. Toute personne disposant d’un compte administrateur peut alors créer, mettre à jour ou supprimer n’importe quelle pile dans n’importe quel compte cible.

En structurant les autorisations de cette manière, les utilisateurs ne se voient pas attribuer un rôle d'administrateur lors de la création ou de la mise à jour d'un StackSet fichier.

{
    "Effect": "Allow",
    "Action": "iam:PassRole",
    "Resource": "arn:aws:iam::account-id:role/AWSCloudFormationStackSetAdministrationRole"
}

Configurer des options d'autorisations avancées pour les StackSet opérations

Si vous avez besoin d'un contrôle plus précis sur StackSets ce que les utilisateurs et les groupes créent via un compte administrateur unique, vous pouvez utiliser les rôles IAM pour spécifier :

Contrôlez quels utilisateurs peuvent effectuer StackSet des opérations sur des comptes cibles spécifiques

Utilisez des rôles d'administration personnalisés pour contrôler quels utilisateurs et quels groupes peuvent effectuer StackSet des opérations sur quels comptes cibles. Vous souhaiterez peut-être contrôler quels utilisateurs du compte administrateur peuvent effectuer des StackSet opérations sur quels comptes cibles. Pour ce faire, vous devez créer une relation de confiance entre chaque compte cible et un rôle d'administration personnalisé spécifique, plutôt que de créer le rôle de AWSCloudFormationStackSetAdministrationRole service dans le compte administrateur lui-même. Vous activez ensuite des utilisateurs et des groupes spécifiques pour qu'ils utilisent le rôle d'administration personnalisé lorsque vous effectuez StackSet des opérations sur un compte cible spécifique.

Par exemple, vous pouvez créer un rôle A et un rôle B dans votre compte d'administrateur. Vous pouvez ensuite accorder au rôle A l'autorisation d'accéder au compte de destination 1 via le compte 8. Vous pouvez enfin accorder au rôle B l'autorisation d'accéder au compte de destination 9 via le compte 16.

La configuration des autorisations nécessaires implique de définir un rôle d'administration personnalisé, de créer un rôle de service pour le compte cible et d'accorder aux utilisateurs l'autorisation de transmettre le rôle d'administration personnalisé lors de l'exécution d' StackSet opérations.

En général, voici comment cela fonctionne une fois que vous disposez des autorisations nécessaires : lors de la création d'un StackSet, l'utilisateur doit spécifier un rôle d'administration personnalisé. L'utilisateur doit disposer de l'autorisation nécessaire pour transmettre le rôle à CloudFormation. En outre, le rôle d'administration personnalisé doit entretenir une relation de confiance avec les comptes cibles spécifiés pour le StackSet. CloudFormation crée le rôle d'administration personnalisé StackSet et lui associe le rôle d'administration personnalisé. Lors de la mise à jour d'un StackSet, l'utilisateur doit spécifier explicitement un rôle d'administration personnalisé, même s'il s'agit du même rôle d'administration personnalisé que celui utilisé StackSet précédemment. CloudFormationutilise ce rôle pour mettre à jour la pile, sous réserve des exigences ci-dessus.

Contrôlez les ressources que les utilisateurs peuvent inclure dans des StackSets

Utilisez des rôles d'exécution personnalisés pour contrôler les ressources de pile que les utilisateurs et les groupes peuvent inclure dans leurs StackSets. Par exemple, vous souhaiterez peut-être configurer un groupe qui ne peut inclure que des S3-related ressources Amazon dans les ressources qu'il crée, tandis StackSets qu'une autre équipe ne peut inclure que des ressources DynamoDB. Pour ce faire, vous créez une relation d’approbation entre le rôle d’administrateur personnalisé pour chaque groupe et un rôle d’exécution personnalisé pour chaque jeu de ressources. Le rôle d'exécution personnalisé définit les ressources de pile dans lesquelles les ressources peuvent être incluses StackSets. Le rôle d'administration personnalisé réside dans le compte administrateur, tandis que le rôle d'exécution personnalisé réside dans chaque compte cible dans lequel vous souhaitez créer à StackSets l'aide des ressources définies. Vous activez ensuite des utilisateurs et des groupes spécifiques pour qu'ils utilisent le rôle d'administration personnalisé lors de l'exécution d' StackSets opérations.

Par exemple, vous pouvez créer des rôles d’administration personnalisés A, B et C dans le compte administrateur. Les utilisateurs et les groupes autorisés à utiliser le rôle A peuvent créer StackSets des ressources contenant les ressources de pile spécifiquement répertoriées dans le rôle d'exécution personnalisé X, mais pas celles des rôles Y ou Z, ou des ressources qui ne sont incluses dans aucun rôle d'exécution.

Lors de la mise à jour d'un StackSet, l'utilisateur doit spécifier explicitement un rôle d'administration personnalisé, même s'il s'agit du même rôle d'administration personnalisé que celui utilisé StackSet précédemment. CloudFormation effectue la mise à jour à l'aide du rôle d'administration personnalisé spécifié, tant que l'utilisateur est autorisé à effectuer des opérations sur ce rôle StackSet.

De même, l'utilisateur peut également spécifier un rôle d'exécution personnalisé. S'ils spécifient un rôle d'exécution personnalisé, CloudFormation utilise ce rôle pour mettre à jour la pile, sous réserve des exigences ci-dessus. Si l'utilisateur ne spécifie pas de rôle d'exécution personnalisé, CloudFormation effectue la mise à jour à l'aide du rôle d'exécution personnalisé précédemment associé au StackSet, tant que l'utilisateur est autorisé à effectuer des opérations sur ce rôle StackSet.

Configuration des autorisations pour des StackSet opérations spécifiques

En outre, vous pouvez définir des autorisations pour lesquelles les utilisateurs et les groupes peuvent effectuer des StackSet opérations spécifiques, telles que la création, la mise à jour, la suppression StackSets ou l'empilement d'instances. Pour plus d'informations, consultez la rubrique Actions, ressources et clés de condition pour CloudFormation dans la section Référence de l'autorisation de service.

Configurez des clés globales pour atténuer les problèmes de député confus

Le problème de député confus est un problème de sécurité dans lequel une entité qui n’est pas autorisée à effectuer une action peut contraindre une entité plus privilégiée à le faire. En AWS, l'usurpation d'identité interservices peut entraîner la confusion du problème des adjoints. Cross-service l'usurpation d'identité peut se produire lorsqu'un service (le service appelant) appelle un autre service (le service appelé). Le service appelant peut être manipulé pour utiliser ses autorisations afin d'agir sur les ressources d'un autre client de sorte qu'il n'y aurait pas accès autrement. Pour éviter cela, AWS fournit des outils qui vous aident à protéger vos données pour tous les services dont les responsables de service ont eu accès aux ressources de votre compte.

Nous vous recommandons d'utiliser les clés aws:SourceAccount contextuelles aws:SourceArn et les clés de contexte de condition globale dans les politiques relatives aux ressources afin de limiter les autorisations qui CloudFormation StackSets accordent un autre service à la ressource. Si vous utilisez les deux clés de contexte de condition globale, la valeur aws:SourceAccount et le compte de la valeur aws:SourceArn doit utiliser le même ID de compte lorsqu’il est utilisé dans la même déclaration de stratégie.

Le moyen le plus efficace de se protéger contre le problème de député confus consiste à utiliser la clé de contexte de condition globale aws:SourceArn avec l’ARN complet de la ressource. Si vous ne connaissez pas l’ARN complet de la ressource ou si vous spécifiez plusieurs ressources, utilisez la clé de contexte de condition globale aws:SourceArn avec des caractères génériques (*) pour les parties inconnues de l’ARN. Par exemple, arn:aws:cloudformation::123456789012:*. Dans la mesure du possible, utilisez aws:SourceArn, car il est plus spécifique. Utilisez aws:SourceAccount uniquement lorsque vous ne pouvez pas déterminer l'ARN ou le modèle d'ARN correct.

When StackSets assume le rôle d'administration dans votre compte administrateur, StackSets renseigne votre identifiant de compte administrateur et StackSets Amazon Resource Name (ARN). Vous pouvez donc définir des conditions pour les clés globales aws:SourceAccount et aws:SourceArn dans les relations de confiance afin d'éviter les problèmes de député confus. L'exemple suivant montre comment vous pouvez utiliser les touches contextuelles aws:SourceArn et les clés de contexte de la condition aws:SourceAccount globale StackSets pour éviter le problème de confusion entre les sous-ministres.