View a markdown version of this page

Personnalisez les comptes avec Account Factory Customization (AFC) - AWS Control Tower

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.

Personnalisez les comptes avec Account Factory Customization (AFC)

Note

La fourniture, la mise à jour et la personnalisation d'un compte unique doivent cibler une unité organisationnelle (UO) sur laquelle AWSControlTowerBaseline cette option est activée. Si cette option n'est pas AWSControlTowerBaseline activée pour une unité d'organisation, vous pouvez activer l'inscription automatique du compte ou utiliser ResetEnabledBaseline des ResetEnabledControl API sur EnabledBaselines et EnabledControls sur cette unité d'organisation pour inscrire des comptes. Pour plus de détails sur AWSControlTowerBaseline, voir :Types de référence qui s'appliquent au niveau de l'unité d'organisation.

AWS Control Tower vous permet de personnaliser les ressources nouvelles et existantes Comptes AWS lorsque vous provisionnez leurs ressources depuis la console AWS Control Tower. Une fois que vous avez configuré la personnalisation de Account Factory, AWS Control Tower automatise ce processus pour le provisionnement futur, de sorte que vous n'avez pas à gérer de pipelines. Les comptes personnalisés peuvent être utilisés immédiatement après le provisionnement des ressources.

Fournissez des plans à de nouveaux comptes

Vos comptes personnalisés sont provisionnés dans l'usine de comptes AWS Control Tower, via des CloudFormation modèles ou via Terraform. Vous allez définir un modèle qui servira de plan de compte personnalisé. Votre plan décrit les ressources et les configurations spécifiques dont vous avez besoin lorsqu'un compte est provisionné. Pre-defined des plans, élaborés et gérés par des AWS partenaires, sont également disponibles. Pour plus d'informations sur les plans gérés par les partenaires, consultez la bibliothèque AWS Service Catalog Getting Started.

Appliquer les plans aux comptes existants

Vous pouvez également appliquer des plans personnalisés à des comptes existants en suivant les étapes de mise à jour du compte dans la console AWS Control Tower. Pour en savoir plus, consultez Mettre à jour le compte dans la console.

Définition : Votre compte hub

Les plans de votre compte sont stockés dans un compte qui Compte AWS, pour nos besoins, est appelé compte hub. Les plans sont stockés sous la forme d'un produit du catalogue de services. Nous appelons ce produit un plan directeur, afin de le distinguer de tous les autres produits du catalogue de services. Pour en savoir plus sur la création de produits du catalogue de services, consultez la section Création de produits dans le Guide de l'AWS Service Catalog administrateur.

Note

AWS Control Tower contient des contrôles proactifs qui surveillent CloudFormation les ressources dans AWS Control Tower. Vous pouvez éventuellement activer ces commandes dans votre zone d'atterrissage. Lorsque vous appliquez des contrôles proactifs, ils vérifient que les ressources que vous êtes sur le point de déployer sur vos comptes sont conformes aux politiques et procédures de votre organisation. Pour plus d'informations sur les contrôles proactifs, voir Contrôles proactifs.

Pour plus d'informations sur l'utilisation d'AFC, consultez Automatiser la personnalisation des comptes à l'aide de Account Factory Customization dans AWS Control Tower.

Conditions préalables

Avant de commencer à créer des comptes personnalisés avec AWS Control Tower Account Factory, vous devez disposer d'un environnement de zone d'accueil AWS Control Tower déployé et vous devez disposer d'une unité organisationnelle (OU) enregistrée auprès d'AWS Control Tower, où les comptes que vous venez de créer seront placés.

Préparation à la personnalisation
  • Désignez un compte hub : vous pouvez créer un nouveau compte qui servira de compte hub, ou vous pouvez utiliser un compte existant Compte AWS. Nous vous recommandons vivement de ne pas utiliser le compte de gestion AWS Control Tower comme compte Blueprint Hub.

  • Ajoutez le rôle nécessaire : si vous envisagez de vous inscrire Comptes AWS à AWS Control Tower et de les personnaliser, vous devez d'abord ajouter le AWSControlTowerExecution rôle à ces comptes, comme vous le feriez pour tout autre compte que vous inscrivez à AWS Control Tower.

  • Configurer les plans des partenaires (facultatif) : si vous prévoyez d'utiliser des plans partenaires soumis à des conditions d'abonnement à la place de marché, vous devez les configurer depuis votre compte de gestion AWS Control Tower avant de déployer les plans partenaires en tant que plans de personnalisation d'usine de comptes.

Note

Un plan peut être déployé par compte AWS Control Tower.

Considérations relatives à la personnalisation de Account Factory (AFC)

  • L'AFC prend en charge la personnalisation à l'aide d'un AWS Service Catalog seul produit de base.

  • Les produits AWS Service Catalog Blueprint doivent être créés dans le compte du hub et dans la même région que la région d'origine de la zone d'accueil d'AWS Control Tower.

  • Le rôle AWSControlTowerBlueprintAccess IAM doit être créé avec le nom, les autorisations et la politique de confiance appropriés.

  • AWS Control Tower prend en charge deux options de déploiement pour les plans : déployer uniquement dans la région d'origine ou déployer dans toutes les régions régies par AWS Control Tower. La sélection des régions n'est pas disponible.

  • Lorsque vous mettez à jour un plan dans un compte membre, l'identifiant du compte Blueprint Hub et le produit du AWS Service Catalog plan ne peuvent pas être modifiés.

  • AWS Control Tower ne prend pas en charge la suppression d'un plan existant et l'ajout d'un nouveau plan en une seule opération de mise à jour du plan. Vous pouvez supprimer un plan, puis en ajouter un nouveau lors d'opérations distinctes.

  • AWS Control Tower change de comportement, selon que vous créez ou inscrivez des comptes personnalisés ou des comptes non personnalisés. Si vous ne créez pas ou n'inscrivez pas de comptes personnalisés avec des plans, AWS Control Tower crée un produit provisionné par Account Factory (via Service Catalog) dans le compte de gestion AWS Control Tower. Si vous spécifiez la personnalisation lors de la création ou de l'inscription de comptes avec des plans, AWS Control Tower ne crée pas de produit provisionné par Account Factory dans le compte de gestion AWS Control Tower.

En cas d'erreur de plan

Erreur lors de l'application d'un plan

Si une erreur se produit pendant le processus d'application d'un plan à un compte, qu'il s'agisse d'un nouveau compte ou d'un compte existant que vous inscrivez à AWS Control Tower, la procédure de restauration est la même. Le compte existera, mais il n'est pas personnalisé et il n'est pas inscrit à AWS Control Tower. Pour continuer, suivez les étapes pour inscrire le compte dans AWS Control Tower et ajoutez le plan au moment de l'inscription.

Erreur lors de la création du AWSControlTowerBlueprintAccess rôle et solutions

Lorsque vous créez le AWSControlTowerBlueprintAccess rôle à partir d'un compte AWS Control Tower, vous devez être connecté en tant que principal à l'aide du AWSControlTowerExecution rôle. Si vous êtes connecté comme n'importe quel autre utilisateur, l'CreateRoleopération est empêchée par un SCP, comme indiqué dans l'artefact suivant :

{ "Condition": { "ArnNotLike": { "aws:PrincipalArn": [ "arn:aws:iam::*:role/AWSControlTowerExecution", "arn:aws:iam::*:role/stacksets-exec-*" ] } }, "Action": [ "iam:AttachRolePolicy", "iam:CreateRole", "iam:DeleteRole", "iam:DeleteRolePermissionsBoundary", "iam:DeleteRolePolicy", "iam:DetachRolePolicy", "iam:PutRolePermissionsBoundary", "iam:PutRolePolicy", "iam:UpdateAssumeRolePolicy", "iam:UpdateRole", "iam:UpdateRoleDescription" ], "Resource": [ "arn:aws:iam::*:role/aws-controltower-*", "arn:aws:iam::*:role/*AWSControlTower*", "arn:aws:iam::*:role/stacksets-exec-*" ], "Effect": "Deny", "Sid": "GRIAMROLEPOLICY" }

Les solutions de contournement suivantes sont disponibles :

  • (Très recommandé) Assumez le AWSControlTowerExecution rôle et AWSControlTowerBlueprintAccess créez-le. Si vous optez pour cette solution, veillez à vous déconnecter du AWSControlTowerExecution rôle immédiatement après, afin d'éviter toute modification involontaire des ressources.

  • Connectez-vous à un compte qui n'est pas inscrit à AWS Control Tower et qui n'est donc pas soumis à ce SCP.

  • Modifiez temporairement ce SCP pour autoriser l'opération.

  • (Fortement déconseillé) Utilisez votre compte de gestion AWS Control Tower comme compte hub, il n'est donc pas soumis au SCP.

Personnalisation de votre document de politique pour les plans de l'AFC en fonction de CloudFormation

Lorsque vous activez un plan via Account Factory, AWS Control Tower vous demande d' CloudFormation en créer un StackSet en votre nom. CloudFormation nécessite l'accès à votre compte géré pour créer des CloudFormation piles dans le StackSet. Bien qu'il dispose CloudFormation déjà de privilèges d'administrateur sur le compte géré par le biais de ce AWSControlTowerExecution rôle, ce rôle ne peut pas être assumé par CloudFormation.

Dans le cadre de l'activation d'un plan, AWS Control Tower crée un rôle dans le compte du membre, qui CloudFormation peut assumer l'exécution StackSet des tâches de gestion. Le moyen le plus simple d'activer votre plan personnalisé via Account Factory est d'utiliser une politique d'autorisation complète, car ces politiques sont compatibles avec tous les modèles de plan.

Cependant, les meilleures pratiques suggèrent que vous devez restreindre les autorisations pour CloudFormation le compte cible. Vous pouvez fournir une politique personnalisée, qu'AWS Control Tower applique au rôle qu'elle crée CloudFormation pour être utilisé. Par exemple, si votre plan crée un paramètre SSM appelé something important, vous pouvez fournir la politique suivante :

JSON
{ "Version":"2012-10-17", "Statement": [ { "Sid": "AllowCloudFormationActionsOnStacks", "Effect": "Allow", "Action": "cloudformation:*", "Resource": "arn:aws:cloudformation:*:*:stack/*" }, { "Sid": "AllowSsmParameterActions", "Effect": "Allow", "Action": [ "ssm:PutParameter", "ssm:DeleteParameter", "ssm:GetParameter", "ssm:GetParameters" ], "Resource": "arn:*:ssm:*:*:parameter/something-important" } ] }

L'AllowCloudFormationActionsOnStacksinstruction est obligatoire pour toutes les politiques personnalisées de l'AFC ; CloudFormation utilise ce rôle pour créer des instances de pile, elle nécessite donc une autorisation pour effectuer des CloudFormation actions sur les piles. La AllowSsmParameterActions section est spécifique au modèle en cours d'activation.

Résoudre les problèmes d'autorisation

Lorsque vous activez un plan avec une politique restreinte, vous pouvez constater que les autorisations sont insuffisantes pour activer le plan. Pour résoudre ces problèmes, révisez votre document de politique et mettez à jour les préférences du plan directeur du compte membre afin d'utiliser la politique corrigée. Pour vérifier que la politique est suffisante pour activer le Blueprint, assurez-vous que les CloudFormation autorisations sont accordées et que vous pouvez créer une pile directement à l'aide de ce rôle.

Autorisations supplémentaires requises pour créer un produit du catalogue de Terraform-based services

Lorsque vous créez un produit AWS Service Catalog externe avec un fichier de configuration Terraform pour AFC, AWS Service Catalog certaines autorisations doivent être ajoutées à votre politique IAM personnalisée AFC, en plus des autorisations requises pour créer les ressources définies dans votre modèle. Si vous choisissez la politique d'administration complète par défaut, vous n'avez pas besoin d'ajouter ces autorisations supplémentaires.

JSON
{ "Version":"2012-10-17", "Statement": [ { "Action": [ "resource-groups:CreateGroup", "resource-groups:ListGroupResources", "resource-groups:DeleteGroup", "resource-groups:Tag" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "tag:GetResources", "tag:GetTagKeys", "tag:GetTagValues", "tag:TagResources", "tag:UntagResources" ], "Resource": "*", "Effect": "Allow" }, { "Action": "s3:GetObject", "Effect": "Allow", "Resource": "*", "Condition": { "StringEquals": { "s3:ExistingObjectTag/servicecatalog:provisioning": "true" } } } ] }

Pour plus d'informations sur la création de produits Terraform à l'aide du type de produit externe dans AWS Service Catalog, voir Étape 5 : Création de rôles de lancement dans le Guide de l'administrateur du catalogue de services.

Transition vers AWS Service Catalog Type de produit externe

AWS Service Catalog a modifié la prise en charge des produits Terraform Open Source et a provisionné les produits vers un nouveau type de produit, appelé External. Pour en savoir plus sur cette transition, consultez Mettre à jour les produits Terraform Open Source existants et les produits provisionnés vers le type de produit externe dans le guide de l'AWS Service Catalog administrateur.

Cette modification affecte les comptes existants que vous avez créés ou inscrits grâce à la personnalisation d'usine des comptes AWS Control Tower. Pour transférer ces comptes vers le type de produit externe, vous devez apporter des modifications à la fois à AWS Control Tower AWS Service Catalog et à AWS Control Tower.

Pour passer au type de produit externe
  1. Mettez à niveau votre moteur de référence Terraform existant AWS Service Catalog pour inclure la prise en charge des types de produits externes et Terraform Open Source. Pour obtenir des instructions sur la mise à jour de votre moteur de référence Terraform, consultez le AWS Service Catalog GitHub référentiel.

  2. Dans AWS Service Catalog, dupliquez tous les produits Terraform Open Source existants (plans), les doublons utilisant le nouveau type de produit externe. Ne mettez pas fin aux plans Terraform Open Source existants.

  3. Dans AWS Control Tower, mettez à jour chaque compte à l'aide d'un plan open source Terraform pour utiliser le nouveau plan externe.

    1. Pour mettre à jour un plan, vous devez d'abord supprimer complètement le plan Terraform Open Source. Pour plus de détails, consultez Supprimer un plan d'un compte.

    2. Ajoutez le nouveau plan externe au même compte. Pour plus de détails, consultez la rubrique Ajouter un plan à un compte AWS Control Tower.

  4. Une fois que tous les comptes utilisant des plans Terraform Open Source ont été mis à jour vers des plans externes, revenez à AWS Service Catalog et résiliez tous les produits qui utilisent Terraform Open Source comme type de produit.

  5. À l'avenir, tous les comptes créés ou inscrits à l'aide de la personnalisation d'usine des comptes AWS Control Tower devront faire référence à des plans utilisant le type de produit CloudFormation ou un type de produit externe.

    Pour les plans créés à l'aide du type de produit externe, AWS Control Tower ne prend en charge que les personnalisations de compte qui utilisent les modèles Terraform et le moteur de référence Terraform. Pour en savoir plus, consultez la rubrique Configurer pour la personnalisation.

Note

AWS Control Tower ne prend pas en charge Terraform Open Source en tant que type de produit lors de la création de nouveaux comptes. Pour en savoir plus sur ces modifications, consultez Mettre à jour les produits Terraform Open Source existants et les produits provisionnés vers le type de produit externe dans le guide de l'AWS Service Catalog administrateur. AWS Service Catalog aidera les clients tout au long de cette transition de type de produit, selon les besoins. Contactez le représentant de votre compte pour demander de l'aide.