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.

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 partir duquel vous administrez 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 tous ceux Compte AWS dans lesquels 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.

Présentation des autorisations autogérées

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 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 transmettent aucun rôle d'administration lors de la création ou de la mise à jour d'un StackSet.

Administrator account

Dans le compte administrateur, créez un rôle IAM nommé AWSCloudFormationStackSetAdministrationRole.

Vous pouvez le faire en créant une pile à partir du CloudFormation modèle disponible dans https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetAdministrationRole.yml.

Exemple de politique d’autorisations

Le rôle d’administration créé par le modèle précédent inclut la politique d’autorisation suivante.

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

Exemple de politique d’approbation 1

Le modèle précédent inclut également la politique d’approbation suivante qui accorde au service l’autorisation d’utiliser le rôle d’administration et les autorisations associées à ce rôle.

{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudformation.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Exemple de politique d’approbation 2

Pour déployer des instances de pile dans un compte cible situé dans une région désactivée par défaut, vous devez également inclure le principal régional pour cette région. Chaque région désactivée par défaut aura son propre principal de service régional.

L’exemple de politique d’approbation suivante accorde au service l’autorisation d’utiliser le rôle d’administration dans la région Asie-Pacifique (Hong Kong) (ap-east-1), une région désactivée par défaut.

{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
            "cloudformation.amazonaws.com",
            "cloudformation.ap-east-1.amazonaws.com"
         ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Pour de plus amples informations, veuillez consulter Préparation à l’exécution d’opérations StackSet dans les Régions AWS qui sont désactivées par défaut. Pour obtenir une liste des codes de région, consultez Points de terminaison régionaux dans le Guide Références générales AWS.

Target accounts

Dans chaque compte cible, créez un rôle de service nommé AWSCloudFormationStackSetExecutionRolequi approuve le compte administrateur. Ce rôle doit avoir ce nom exact. Vous pouvez le faire en créant une pile à partir du CloudFormation modèle disponible dans https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetExecutionRole.yml. Lorsque vous utilisez ce modèle, vous êtes invité à fournir l’ID de compte administrateur avec lequel votre compte cible doit avoir une relation d’approbation.

Important

Sachez que ce modèle accorde l'accès administrateur. Après avoir utilisé le modèle pour créer un rôle d'exécution de compte cible, vous devez étendre les autorisations de la déclaration de politique aux types de ressources que vous créez en utilisant StackSets.

Le rôle de service du compte cible nécessite des autorisations pour effectuer toutes les opérations spécifiées dans votre CloudFormation modèle. Par exemple, si votre modèle crée un compartiment S3, vous avez besoin d'autorisations pour créer des objets pour S3. Votre compte de destination doit toujours disposer des autorisations CloudFormation complètes, notamment des autorisations de création, de mise à jour, de suppression et de description des piles.

Exemple de politique d’autorisations 1

Le rôle créé par ce modèle active la politique suivante sur votre compte de destination.

{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

Exemple de politique d’autorisations 2

L'exemple suivant montre une déclaration de politique avec les autorisations minimales StackSets pour fonctionner. Pour créer des piles dans des comptes cibles qui utilisent des ressources provenant de services autres que CloudFormation, vous devez ajouter ces actions de service et ces ressources à la déclaration de AWSCloudFormationStackSetExecutionRolepolitique de chaque compte cible.

{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
         "cloudformation:*"
      ],
      "Resource": "*"
    }
  ]
}

Exemple de politique d’approbation

La relation d'approbation suivante est créée par le modèle. L'identifiant du compte administrateur est affiché sous la formeadmin_account_id.

{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:root"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Vous pouvez configurer la relation d'approbation du rôle d'exécution d'un compte cible existant pour approuver un rôle spécifique dans le compte administrateur. Si vous supprimez le rôle dans le compte administrateur et que vous en créez un nouveau pour le remplacer, vous devez configurer les relations de confiance de votre compte cible avec le nouveau rôle du compte administrateur, représenté admin_account_id dans l'exemple précédent.

Configurer des options d'autorisation 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 par le biais d'un seul compte administrateur, 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 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 créez 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 AWSCloudFormationStackSetAdministrationRoleservice 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é lors de l'exécution d' StackSet 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 StackSet des opérations.

En général, voici comment cela fonctionne une fois que vous avez les autorisations nécessaires en place : 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 avoir 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 y 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.

Administrator account

Exemple de politique d’autorisations

Pour chacun StackSet, créez un rôle d'administration personnalisé avec les autorisations nécessaires pour assumer le rôle d'exécution du compte cible.

Le nom du rôle d’exécution du compte cible doit être le même dans tous les comptes cibles. Si le nom du rôle est AWSCloudFormationStackSetExecutionRole, l' StackSets utilise automatiquement lors de la création d'un StackSet. Si vous spécifiez un nom de rôle personnalisé, les utilisateurs doivent fournir le nom du rôle d'exécution lors de la création d'un StackSet.

Créez un rôle de service IAM avec un nom personnalisé et la politique d’autorisations suivante. Dans les exemples ci-dessous, custom_execution_role fait référence au rôle d'exécution dans les comptes cibles.

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

Pour spécifier plusieurs comptes dans une seule instruction, séparez-les par des virgules.

"Resource": [
  "arn:aws:iam::target_account_id_1:role/custom_execution_role", 
  "arn:aws:iam::target_account_id_2:role/custom_execution_role"
]

Vous pouvez spécifier tous les comptes cibles en utilisant un caractère générique (*) à la place d’un ID de compte.

"Resource": [
  "arn:aws:iam::*:role/custom_execution_role"
]

Exemple de politique d’approbation 1

Vous devez fournir une politique d’approbation pour le rôle de service afin de définir quels principaux IAM peuvent assumer le rôle.

{ 
  "Version":"2012-10-17",		 	 	  
  "Statement": [ 
    { 
      "Effect": "Allow", 
      "Principal": { 
        "Service": "cloudformation.amazonaws.com" 
      }, 
      "Action": "sts:AssumeRole" 
    } 
  ] 
}

Exemple de politique d’approbation 2

Pour déployer des instances de pile dans un compte cible situé dans une région désactivée par défaut, vous devez également inclure le principal régional pour cette région. Chaque région désactivée par défaut aura son propre principal de service régional.

L’exemple de politique d’approbation suivante accorde au service l’autorisation d’utiliser le rôle d’administration dans la région Asie-Pacifique (Hong Kong) (ap-east-1), une région désactivée par défaut.

{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
            "cloudformation.amazonaws.com",
            "cloudformation.ap-east-1.amazonaws.com"
         ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Pour de plus amples informations, veuillez consulter Préparation à l’exécution d’opérations StackSet dans les Régions AWS qui sont désactivées par défaut. Pour obtenir la liste des codes de région, consultez Points de terminaison régionaux dans le Guide de référence générale AWS.

Exemple de politique de transfert de rôle

Vous avez également besoin d'une politique d'autorisations IAM pour vos utilisateurs IAM qui permet à l'utilisateur de transmettre le rôle d'administration personnalisé lors de l'exécution StackSet d'opérations. Pour plus d'informations, consultez la section Octroi d'autorisations à un utilisateur pour transférer un rôle à un service AWS.

Dans l'exemple ci-dessous, customized_admin_role fait référence au rôle d'administration que l'utilisateur doit transmettre.

{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:GetRole",
        "iam:PassRole"
      ],
      "Resource": "arn:aws:iam::*:role/customized_admin_role"
    }
  ]
}

Target accounts

Dans chaque compte cible, créez un rôle de service qui fait confiance au rôle d’administration personnalisé que vous voulez utiliser avec ce compte.

Le rôle de compte cible nécessite des autorisations pour effectuer toutes les opérations spécifiées dans votre CloudFormation modèle. Par exemple, si votre modèle crée un compartiment S3, vous devez disposer des autorisations permettant de créer des objets dans S3. Votre compte cible a toujours besoin d' CloudFormation autorisations complètes, notamment des autorisations pour créer, mettre à jour, supprimer et décrire des piles.

Le nom du rôle du compte cible doit être le même dans tous les comptes cibles. Si le nom du rôle est AWSCloudFormationStackSetExecutionRole, l' StackSets utilise automatiquement lors de la création d'un StackSet. Si vous spécifiez un nom de rôle personnalisé, les utilisateurs doivent fournir le nom du rôle d'exécution lors de la création d'un StackSet.

Exemple de politique d’autorisations

L'exemple suivant montre une déclaration de politique avec les autorisations minimales StackSets pour fonctionner. Pour créer des piles dans des comptes cibles qui utilisent des ressources provenant de services autres que CloudFormation, vous devez ajouter ces actions de service et ces ressources à la politique d'autorisation.

{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudformation:*"
      ],
      "Resource": "*"
    }
  ]
}

Exemple de politique d’approbation

Vous devez fournir la politique d’approbation suivante lorsque vous créez le rôle pour définir la relation d’approbation.

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

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 leur pile StackSets. Par exemple, vous souhaiterez peut-être configurer un groupe qui ne peut inclure que des ressources liées à Amazon S3 dans ce 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 qui 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 StackSets des 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 les ressources non incluses dans un 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 en utilisant le rôle d'administration personnalisé spécifié, à condition que l'utilisateur soit 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 en utilisant le rôle d'exécution personnalisé précédemment associé au StackSet, à condition que l'utilisateur soit autorisé à effectuer des opérations sur ce rôle StackSet.

Administrator account

Créez un rôle d’administration personnalisé dans votre compte administrateur, comme indiqué dans Contrôlez quels utilisateurs peuvent effectuer StackSet des opérations sur des comptes cibles spécifiques. Incluez une relation d’approbation entre le rôle d’administration personnalisé et les rôles d’exécution personnalisés que vous voulez utiliser.

Exemple de politique d’autorisations

L'exemple suivant est une politique d'autorisation à la fois pour AWSCloudFormationStackSetExecutionRolecelle définie pour le compte cible, en plus d'un rôle d'exécution personnalisé.

{
  "Version":"2012-10-17",		 	 	 
   "Statement": [
    {
      "Sid": "Stmt1487980684000",
      "Effect": "Allow",
      "Action": [
        "sts:AssumeRole" 
      ],
      "Resource": [ 
        "arn:aws:iam::*:role/AWSCloudFormationStackSetExecutionRole",
        "arn:aws:iam::*:role/custom_execution_role" 
      ]
    } 
  ]
}

Target accounts

Dans les comptes cibles dans lesquels vous souhaitez créer votre StackSets, créez un rôle d'exécution personnalisé qui accorde des autorisations aux services et aux ressources que vous souhaitez que les utilisateurs et les groupes puissent inclure dans StackSets.

Exemple de politique d’autorisations

L'exemple suivant fournit les autorisations minimales pour StackSets, ainsi que l'autorisation de créer des tables Amazon DynamoDB.

{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudformation:*"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "dynamoDb:createTable"
      ],
      "Resource": "*"
    }
  ]
}

Exemple de politique d’approbation

Vous devez fournir la politique d’approbation suivante lorsque vous créez le rôle pour définir la relation d’approbation.

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

Configurer 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 le cumul 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. EnAWS, l'usurpation d'identité interservices peut entraîner un problème de confusion chez les adjoints. L’usurpation d’identité entre services 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 auprès des principaux fournisseurs de services qui ont obtenu l'accès aux ressources de votre compte.

Nous recommandons d'utiliser les clés de contexte de condition aws:SourceAccountglobale aws:SourceArnet les clés contextuelles dans les politiques de 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.

Lorsque StackSets assume le rôle d'administration dans votre compte d'administrateur, StackSets renseigne votre ID de compte administrateur et le nom de ressource StackSets Amazon (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 de contexte de condition aws:SourceAccount globale aws:SourceArn et globale StackSets pour éviter le problème de confusion des adjoints.

Administrator account

Exemple Clés globales pour aws:SourceAccount et aws:SourceArn

Lors de l'utilisation StackSets, définissez les clés globales aws:SourceAccount et aws:SourceArn définissez votre politique de AWSCloudFormationStackSetAdministrationRoleconfiance pour éviter tout problème de confusion avec les adjoints.

{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudformation.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "111122223333"
        },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:cloudformation:*:111122223333:stackset/*"
        }
      }
    }
  ]
}

Exemple StackSets ARNs

Spécifiez votre associé StackSets ARNs pour un contrôle plus précis.

JSON

JSON

{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudformation.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "111122223333",
                    "aws:SourceArn": [
                        "arn:aws:cloudformation:STACKSETS-REGION:111122223333:stackset/STACK-SET-ID-1",
                        "arn:aws:cloudformation:STACKSETS-REGION:111122223333:stackset/STACK-SET-ID-2"
                    ]
                }
            }
        }
    ]
}