Accorder des autorisations autogérées - AWS CloudFormation
Vue d'ensemble des autorisations autogéréesDonnez à tous les utilisateurs du compte administrateur les autorisations nécessaires pour gérer les piles dans tous les comptes ciblesConfigurer des options d'autorisation avancées pour les StackSet opérationsPrévention de l’adjoint confus

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 les autorisations gérées par le service, consultez Activez l'accès sécurisé plutôt.

Vue d'ensemble 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 :

  1. Déterminez quel Compte AWS est le compte administrateur.

    StackSets sont créés dans ce compte administrateur. Un compte cible est le compte dans lequel vous créez des piles individuelles appartenant à un StackSet.

  2. Déterminez comment vous souhaitez structurer les autorisations pour StackSet.

    La configuration d'autorisations la plus simple (et la plus permissive) consiste à donner à tous les utilisateurs et groupes du compte administrateur la possibilité de créer et de mettre à jour tous les droits StackSets gérés via ce compte. Si vous avez besoin d'un contrôle plus fin, vous pouvez configurer des autorisations pour spécifier :

    • Quels utilisateurs et groupes peuvent effectuer StackSet des opérations sur quels comptes cibles.

    • Quelles ressources les utilisateurs et les groupes peuvent inclure dans leurs StackSets.

    • Les StackSet opérations que des utilisateurs et des groupes spécifiques peuvent effectuer.

  3. Créez les rôles de service IAM nécessaires dans vos comptes d'administrateur et de destination pour définir les autorisations souhaitées.

    Plus précisément, les deux rôles requis sont les suivants :

    • AWSCloudFormationStackSetAdministrationRole— Ce rôle est déployé sur le compte administrateur.

    • AWSCloudFormationStackSetExecutionRole— Ce rôle est déployé sur tous les comptes sur lesquels vous créez des instances de stack.

Donnez à tous les utilisateurs du compte administrateur les autorisations nécessaires pour 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. Il vous guide tout au long de la création des rôles de service IAM requis dans vos comptes administrateur et cible. Tous les utilisateurs du compte administrateur peuvent ensuite créer, mettre à jour ou supprimer des piles sur tous les comptes cibles.

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.

Tout utilisateur du compte administrateur peut ensuite créer n'importe quel StackSet compte cible après avoir établi une relation de confiance.
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'autorisation

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 de confiance 1

Le modèle précédent inclut également la politique de confiance 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 de confiance 2

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

L'exemple de politique de confiance suivant accorde au service l'autorisation d'utiliser le rôle d'administration dans la région Asie-Pacifique (Hong Kongap-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éparez-vous à effectuer StackSet Régions AWS des opérations désactivées par défaut. Pour obtenir la liste des codes de région, consultez la section Points de terminaison régionaux dans le Références générales AWS Guide.

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'identifiant du compte administrateur avec lequel votre compte cible doit entretenir une relation de confiance.

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 définies dans 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'autorisation 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'autorisation 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 de confiance

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::admin_account_id: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 :

  • Quels utilisateurs et groupes peuvent effectuer StackSet des opérations sur quels comptes cibles.

  • Quelles ressources les utilisateurs et les groupes peuvent inclure dans leurs StackSets.

  • Les StackSet opérations que des utilisateurs et des groupes spécifiques peuvent effectuer.

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.

Une relation de confiance entre un rôle d'administration personnalisé et des comptes cibles qui permet aux utilisateurs de créer un StackSet.

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'autorisation

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 pour chaque compte cible. 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'autorisation 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::target_account_id:role/custom_execution_role"
      ],
      "Effect": "Allow"
    }
  ]
}

Pour spécifier plusieurs comptes dans un seul relevé, 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 (*) au lieu d'un identifiant de compte.

"Resource": [
  "arn:aws:iam::*:role/custom_execution_role"
]
Exemple de politique de confiance 1

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

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

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

L'exemple de politique de confiance suivant accorde au service l'autorisation d'utiliser le rôle d'administration dans la région Asie-Pacifique (Hong Kongap-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éparez-vous à effectuer StackSet Régions AWS des opérations désactivées par défaut. Pour obtenir la liste des codes de région, consultez la section Points de terminaison régionaux dans le Guide de référence AWS général.

Exemple de politique de transfert de rôles

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 approuve le rôle d'administration personnalisé que vous souhaitez 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 de rôle du compte cible doit être le même pour chaque compte cible. 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'autorisation

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 de confiance

Vous devez fournir la politique de confiance suivante lorsque vous créez le rôle afin de définir la relation de confiance.

{
  "Version": "2012-10-17", 
  "Statement": [ 
    { 
      "Effect": "Allow", 
      "Principal": { 
      "AWS": "arn:aws:iam::admin_account_id: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 de confiance entre le rôle d'administration personnalisé pour chaque groupe et un rôle d'exécution personnalisé pour chaque ensemble 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.

Une relation de confiance entre un rôle d'administrateur personnalisé et un rôle d'exécution personnalisé dans les comptes cibles, permettant aux utilisateurs de créer un StackSet.

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é dansContrôlez quels utilisateurs peuvent effectuer StackSet des opérations sur des comptes cibles spécifiques. Incluez une relation de confiance entre le rôle d'administration personnalisé et les rôles d'exécution personnalisés que vous souhaitez qu'il utilise.

Exemple de politique d'autorisation

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 le vôtre 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'autorisation

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 de confiance

Vous devez fournir la politique de confiance suivante lorsque vous créez le rôle afin de définir la relation de confiance.

{
  "Version": "2012-10-17", 
  "Statement": [ 
    { 
      "Effect": "Allow", 
      "Principal": { 
      "AWS": "arn:aws:iam::admin_account_id: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. En AWS, l'usurpation d'identité interservices peut entraîner la confusion des 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 AWS 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"
        },
        "StringLike": {
          "aws:SourceArn": "arn:aws:cloudformation:*:111122223333:stackset/*"
        }
      }
    }
  ]
}
Exemple StackSets ARNs

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

{
  "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",
          ]
        }
      }
    }
  ]
}