Accorder des autorisations autogérées

Cette rubrique fournit des instructions sur la façon de créer les rôles de IAM service requis StackSets pour le 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 à partir duquel vous administrez l'ensemble de piles et le compte sur lequel vous déployez des instances de piles. À 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 IAM rôle.

Pour utiliser les autorisations gérées par le service, consultez Activez un accès sécurisé pour les ensembles de piles avec Organizations plutôt.

Vue d'ensemble des autorisations autogérées

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

Les étapes de base sont les suivantes :

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

   Les ensembles de piles sont créés dans ce compte d'administrateur. Le compte de destination est le compte dans lequel vous créez les piles individuelles qui appartiennent à un ensemble de piles.

2. Déterminez la façon dont vous souhaitez structurer les autorisations pour les ensembles de piles.

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

   • Les utilisateurs et groupes qui peuvent effectuer des opérations d'ensemble de piles et les comptes de destination dans lesquels ils peuvent les effectuer.

   • Les ressources que les utilisateurs et les groupes peuvent inclure dans leurs ensembles de piles.

   • Les opérations d'ensemble de piles que des utilisateurs et groupes spécifiques peuvent effectuer.

3. Créez les rôles IAM de service nécessaires dans vos comptes administrateur et cible afin de 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 des opérations de stack set sur tous les comptes cibles. Il vous guide tout au long de la création des rôles de IAM service 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 transfèrent aucun rôle d'administration lors de la création ou de la mise à jour d'ensembles de piles.

Administrator account

Dans le compte administrateur, créez un IAM rôle 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 Exécution d'opérations de stack set impliquant des régions 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.

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 cible a toujours besoin d' CloudFormationautorisations complètes, notamment des autorisations pour créer, mettre à jour, supprimer et décrire 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 forme admin_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é par admin_account_id dans l'exemple précédent.

Configuration d'options d'autorisations avancées pour les opérations d'ensembles de piles

Si vous avez besoin d'un contrôle plus précis sur les ensembles de piles que les utilisateurs et les groupes créent par le biais d'un seul compte administrateur, vous pouvez utiliser IAM des rôles pour spécifier :

• Les utilisateurs et groupes qui peuvent effectuer des opérations d'ensemble de piles et les comptes de destination dans lesquels ils peuvent les effectuer.

• Les ressources que les utilisateurs et les groupes peuvent inclure dans leurs ensembles de piles.

• Les opérations d'ensemble de piles que des utilisateurs et groupes spécifiques peuvent effectuer.

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

Utilisez des rôles d'administration personnalisés pour contrôler quels utilisateurs et groupes peuvent effectuer des opérations de stack set sur quels comptes cibles. Vous pouvez souhaiter contrôler quel utilisateurs du compte d'administrateur peuvent effectuer des opérations d'ensemble de piles et dans quels comptes de destination ils peuvent le faire. 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 pouvez ensuite autoriser des utilisateurs et des groupes spécifiques à utiliser le rôle d'administration personnalisé approprié lorsqu'ils effectuent des opérations d'ensembles de piles dans un compte de destination 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'opérations de stack set.

En général, voici comment cela fonctionne une fois que vous disposez des autorisations nécessaires : lors de la création d'un stack set, l'utilisateur doit spécifier un rôle d'administration personnalisé. L'utilisateur doit être autorisé à 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 stack set. CloudFormation crée le stack set et y associe le rôle d'administration personnalisé. Lors de la mise à jour d'un ensemble de piles, 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é précédemment avec cet ensemble de piles. CloudFormation utilise ce rôle pour mettre à jour la pile, sous réserve des exigences ci-dessus.

Administrator account

Exemple de politique d'autorisation

Pour chaque ensemble de piles, 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, il est automatiquement StackSets utilisé lors de la création d'un ensemble de piles. 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 ensemble de piles.

Créez un rôle IAM de service 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 définir une politique de confiance pour le rôle de service afin de définir les IAM principaux habilités à 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 Exécution d'opérations de stack set impliquant des régions 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'IAMautorisation pour vos IAM utilisateurs qui leur permette de transmettre le rôle d'administration personnalisé lorsqu'ils effectuent des opérations de stack set. 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, il est automatiquement StackSets utilisé lors de la création d'un ensemble de piles. 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 ensemble de piles.

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 ensembles de piles spécifiques

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 ensembles de piles. Par exemple, vous pouvez configurer un groupe qui ne peut inclure que les ressources liées à Amazon S3 dans les ensembles de piles qu'il crée, tandis qu'une autre équipe peut uniquement inclure 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 dans les ensembles de piles. 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 des ensembles de piles à l'aide des ressources définies. Vous pouvez ensuite autoriser des utilisateurs et des groupes spécifiques à utiliser le rôle d'administration personnalisé approprié lorsqu'ils effectuent des opérations d'ensembles de piles.

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 ayant l'autorisation d'utiliser le rôle A peuvent créer des ensembles de piles contenant les ressources de pile spécifiquement répertoriées dans le rôle d'exécution personnalisé X, mais pas celles répertoriées dans les rôles Y ou Z ou les ressources non incluses dans un rôle d'exécution.

Lors de la mise à jour d'un ensemble de piles, 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é précédemment avec cet ensemble de piles. 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 cet ensemble de piles.

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é à l'ensemble de piles, à condition que l'utilisateur soit autorisé à effectuer des opérations sur cet ensemble de piles.

Administrator account

Créez un rôle d'administration personnalisé dans votre compte administrateur, comme indiqué dansContrôlez quels utilisateurs peuvent effectuer des opérations de stack set 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 de destination dans lesquels vous voulez créer vos ensembles de piles, créez un rôle d'exécution personnalisé qui accorde des autorisations d'accès aux services et ressources que les utilisateurs et les groupes devront pouvoir inclure dans les ensembles de piles.

Exemple de politique d'autorisation

L'exemple suivant fournit les autorisations minimales pour les ensembles de piles, 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"
    } 
  ] 
} 

Configuration d'autorisations pour des opérations d'ensembles de piles spécifiques

En outre, vous pouvez configurer des autorisations pour définir les utilisateurs et les groupes qui peuvent effectuer des opérations d'ensembles de piles spécifiques, telles que la création, la mise à jour ou la suppression d'ensembles de piles ou d'instances de pile. Pour plus d'informations, reportez-vous à la section Actions, ressources et clés de CloudFormation condition du Guide de l'IAMutilisateur.

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 prémunir contre le problème de confusion des adjoints consiste à utiliser la clé de contexte de la condition aws:SourceArn globale avec l'intégralité ARN de la ressource. Si vous ne connaissez pas l'intégralité ARN de la ressource ou si vous spécifiez plusieurs ressources, utilisez la clé de condition contextuelle aws:SourceArn globale avec des caractères génériques (*) pour les parties inconnues duARN. Par exemple, arn:aws:cloudformation::123456789012:*. Dans la mesure du possible, utilisez aws:SourceArn, car il est plus spécifique. À utiliser aws:SourceAccount uniquement lorsque vous ne pouvez pas déterminer le ARN modèle ARN ou le modèle correct.

Lorsque StackSets assume le rôle d'administration dans votre compte d'administrateur, StackSets renseigne votre identifiant 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",
          ]
        }
      }
    }
  ]
}