Composants d'Enterprise Blueprint Factory

L'Enterprise Blueprint Factory comprend les composants suivants :

• Référentiel de produits : référentiel dans lequel vous stockez les plans.

• Référentiel de configuration : référentiel dans lequel vous stockez le fichier de configuration qui définit vos AWS Service Catalog portefeuilles et vos produits.

• Fichier de configuration : fichier de configuration qui définit les plans disponibles, les personnes autorisées à les utiliser et la manière dont ils peuvent les utiliser.

• Pipeline de configuration : pipeline DevOps CI/CD qui définit le portefeuille Service Catalog et les parts de portefeuille et crée un pipeline de lancement pour chaque produit.

• Pipeline de publication : pipeline DevOps CI/CD qui publie des plans sous forme de produits Service Catalog. 

L'équipe de l'infrastructure cloud gère généralement l'ensemble de l'usine de plans d'entreprise, car elle doit approuver chaque plan. Cependant, l'équipe chargée DevOps du code est généralement responsable du pipeline de configuration et du pipeline de publication. Pour publier de nouveaux plans, les développeurs interagissent uniquement avec le référentiel du produit, le référentiel de configuration et le fichier de configuration.

Référentiel de produits

Le référentiel de produits est un emplacement centralisé dans lequel vous stockez les plans approuvés par votre organisation.  Une équipe administrative et une équipe de sécurité examinent les pull requests adressées à ce référentiel pour s'assurer que chaque plan répond aux exigences organisationnelles et de sécurité. Dans ce guide, nous utilisons GitHub pour le référentiel, mais vous pouvez utiliser une alternative.

Référentiel de configuration

Le référentiel de configuration (dépôt de configuration) est l'emplacement où votre organisation stocke le fichier de configuration pour vos portefeuilles et produits Service Catalog publiés via Enterprise Blueprint Factory. Dans ce guide, nous utilisons GitHub pour le référentiel, mais vous pouvez utiliser une alternative.

Fichier de configuration

Le fichier de configuration Enterprise Blueprint Factory (fichier de configuration) est stocké dans le référentiel de configuration, qui appartient à l'équipe administrative du Blueprint. Le nom de ce fichier est bp_config.yml. Lorsqu'un développeur met à jour ce fichier, l'équipe administrative du plan examine les modifications. La fusion des modifications dans la branche principale lance le pipeline de configuration. Le fichier de configuration orchestre la publication, le partage et la distribution de tous les plans gérés via Enterprise Blueprint Factory.

Le fichier de configuration est un fichier YAML composé de deux objets principaux : portfolios etproducts. Voici un exemple de fichier de configuration :

portfolios:  
  - portfolio_name: blueprint-portfolio
    owner: Blueprint-team
    provider_name: AWS
    description: "Blueprint portfolio"
    portfolio_access_role:
       - arn:aws:iam::123456789012:role/examplerole
       - arn:aws:iam::123456789012:user/exampleuser
    share_to_ou:
     - org_id: "o-exampleOrgID"
    stack_tags:
      DataClassification: Confidential
      Organization: AWS
products:
  - name: BP-S3-Product
    description: "Blueprint for BP-S3 product"
    product_config_file: 'BP-S3/product_config.json'
    owner: Blueprint-team
    stack_tags:
      DataClassification: Confidential
      Organization: AWS
    portfolio_associations:
      - blueprint-portfolio
    launch_constraint_role: arn:aws:iam::123456789012:role/examplelaunchrole

Dans l'portfoliosobjet, vous définissez vos portefeuilles Service Catalog cibles. Pour chaque portefeuille, vous fournissez les attributs suivants :

• portfolio_nameest le nom du portefeuille. Cet attribut est obligatoire.

• ownerest le nom de l'équipe propriétaire du portefeuille. Cet attribut est facultatif.

• provider_nameest le nom de l'équipe ou de l'organisation qui gère le portefeuille. La valeur par défaut est AWS. Cet attribut est obligatoire.

• descriptionest une brève description du portefeuille. Cet attribut est facultatif.

• portfolio_access_rolessont les identités AWS Identity and Access Management (IAM) (utilisateurs, rôles ou groupes) autorisées à accéder au portefeuille et aux produits associés. Cet attribut est facultatif.

• share_to_ouest l'unité organisationnelle (UO) avec AWS Organizations laquelle le portefeuille est partagé. Les utilisateurs finaux peuvent déployer les produits de ce portefeuille dans ceux Comptes AWS qui sont membres de l'unité d'organisation cible. Cet attribut est facultatif.

• stack_tagssont les tags appliqués au portefeuille. Cet attribut est facultatif.

Dans l'productsobjet, vous définissez chaque plan que vous souhaitez publier en tant que produit dans Service Catalog. Pour chaque produit, vous fournissez les attributs suivants :

• nameest le nom du produit dans Service Catalog. Cet attribut est obligatoire.

• descriptionest une brève description du produit. Cet attribut est obligatoire.

• product_config_fileest le nom du fichier de configuration du produit Blueprint stocké dans le référentiel de produits. Cet attribut est obligatoire.

• ownerest le nom de l'équipe propriétaire du produit. Cet attribut est obligatoire.

• stack_tagssont les étiquettes apposées sur le produit. Cet attribut est facultatif.

• portfolio_associationssont les portefeuilles cibles qui contiennent le produit. Cet attribut est facultatif.

  Note

  Nous vous recommandons d'ajouter des produits uniquement aux portefeuilles gérés par le biais de l'Enterprise Blueprint Factory. Si vous souhaitez ajouter des produits à des portefeuilles qui ne sont pas gérés via Enterprise Blueprint Factory, la politique IAM de l'utilisateur doit autoriser cette action. AssociateProductWithPortfolio Toutefois, pour des raisons de sécurité, nous vous recommandons d'autoriser cette action uniquement pour le pipeline de configuration d'Enterprise Blueprint Factory.

• launch_constraint_roleest le rôle de lancement assumé par Service Catalog lorsqu'un utilisateur final lance le produit. Cet attribut est obligatoire.

Pipeline de configuration

Le pipeline de configuration (pipeline de configuration) automatise la configuration du portefeuille Service Catalog et des parts de portefeuille. Il crée également le pipeline de lancement pour chaque produit. Ce pipeline est une AWS CodePipelineressource. Une mise à jour du fichier de configuration appelle le pipeline de configuration.

La première fois que vous appelez le pipeline de configuration, il crée deux portefeuilles supplémentaires qui ne sont pas définis dans votre fichier de configuration :

• Blueprint-portfolio— Chaque produit que vous déployez via l'Enterprise Blueprint Factory est ajouté à ce portefeuille. Ce portefeuille est accessible aux principaux IAM et aux unités organisationnelles que vous spécifiez dans le fichier de configuration.

• Bootstrapping-Admin-Portfolio— Le Bootstrapping-Admin-Product produit est associé à ce portefeuille. Ce produit est un CloudFormation modèle pour le pipeline de publication. Autorisez uniquement l'équipe administrative du Blueprint à accéder à ce portefeuille afin qu'elle puisse gérer les produits administratifs.

Étapes du pipeline de configuration

L'image suivante montre les étapes du pipeline de configuration et les ressources avec lesquelles le pipeline interagit. Chaque étape du pipeline est un AWS CodeBuildprojet.

Les étapes du pipeline de configuration sont les suivantes :

1. Déployer des portefeuilles : le pipeline de configuration déploie tous les portefeuilles ajoutés au fichier de configuration ou supprime tous les portefeuilles supprimés du fichier de configuration. Si aucune modification n'est apportée aux portefeuilles, le pipeline ignore cette étape.

2. Portefeuilles de partage : le pipeline de configuration partage les portefeuilles avec les unités organisationnelles cibles (OUs). Si aucune modification n'est apportée aux actions du portefeuille, le pipeline ignore cette étape.

3. Déployer Blueprint-Admin-Bootstrapping-Product — Le pipeline de configuration récupère le bp-pipeline plan depuis le ServiceCatalog-CodeRepo dépôt et le déploie dans Service Catalog en tant que. Bootstrapping-Admin-Product Ce produit est le CloudFormation modèle utilisé pour créer un pipeline de publication. Le déploiement de ce modèle en tant que produit Service Catalog permet de maintenir le contrôle des versions. Si aucune modification n'est apportée au bp-pipeline plan, le pipeline ignore cette étape.

4. Créer des pipelines de publication : en fonction des attributs du produit contenus dans le fichier de configuration, le pipeline de configuration prépare les paramètres de la pile et lance une CloudFormation pile qui crée un pipeline de publication pour le produit. Pour plus d'informations, consultez la section Liaison du pipeline dans ce guide.

5. Déployer des produits : le pipeline de publication déploie le plan en tant que produit Service Catalog et l'associe au portefeuille cible. Les utilisateurs finaux peuvent désormais déployer le produit dans ceux Comptes AWS qui sont membres de l'unité d'organisation cible.

Pipeline de lancement

Le pipeline de publication automatise la publication des plans sous forme de produits Service Catalog. Ce pipeline est une AWS CodePipelineressource. Lorsque votre organisation souhaite publier un nouveau plan, un développeur télécharge le modèle iAC et son fichier de configuration du produit dans le référentiel du produit. L'ajout des détails du produit au fichier de configuration déclenche le pipeline de configuration. Le pipeline de configuration crée un pipeline de publication pour ce plan. Toute mise à jour ultérieure du plan déclenche ce pipeline de publication pour mettre à jour le produit dans Service Catalog avec une nouvelle version.

Le pipeline de publication inclut des contrôles proactifs qui automatisent les contrôles de sécurité et de conformité de vos plans. Les contrôles proactifs sont conçus pour empêcher la création de ressources non conformes. Ces contrôles peuvent réduire le nombre d'événements de sécurité gérés par d'autres types de contrôles de sécurité, tels que les contrôles réactifs et les contrôles de détection. Dans la mesure où les contrôles proactifs garantissent la conformité des ressources déployées avant leur déploiement, aucun événement de détection ne nécessite une réponse ou une correction.

La première fois que vous appelez le pipeline de configuration, celui-ci crée un produit Service Catalog nomméBootstrapping-Admin-Product. Ce produit est le CloudFormation modèle du pipeline de publication. Comme le montre la figure suivante, le pipeline de configuration utilise le Bootstrapping-Admin-Product produit pour créer un pipeline de publication dédié pour chaque nouveau plan. Il existe une one-to-one relation entre les plans et les pipelines de publication.

Étapes du pipeline de lancement

L'image suivante montre les étapes par défaut du pipeline de publication et les ressources avec lesquelles le pipeline interagit. Chaque étape du pipeline est un CodeBuild projet.

Les étapes du pipeline de publication sont les suivantes :

1. Alignement des fichiers — Cette étape vérifie que le plan est un CloudFormation modèle ou une AWS Cloud Development Kit (AWS CDK) construction. Si le plan est une AWS CDK construction, cette étape synthétise la AWS CDK construction dans un CloudFormation modèle. Ce processus automatise et normalise les déploiements via. CloudFormation Si des erreurs sont détectées, le pipeline échoue.

2. Vérification de syntaxe — Les erreurs de syntaxe sont une cause fréquente d'erreurs de CloudFormation déploiement. À ce stade, AWS CloudFormation Linter (cfn-lint) vérifie les erreurs de syntaxe en comparant le modèle à la spécification de la ressource.AWS CloudFormation Il effectue également d'autres contrôles, tels que la vérification de la validité des valeurs des propriétés des ressources et le respect des meilleures pratiques. Si des erreurs sont détectées, le pipeline échoue et cfn-lint renvoie des suggestions.

3. Contrôle : à ce stade, cfn_nag vérifie les éventuels problèmes de sécurité en recherchant des modèles. Par exemple, il vérifie la présence de groupes de sécurité et de politiques AWS Identity and Access Management (IAM) trop permissifs, de chiffrement manquant et de littéraux de mot de passe. Si des erreurs sont détectées, le pipeline échoue et cfn_nag renvoie des suggestions.

4. Vérification de version — Le pipeline de publication effectue le contrôle de version en fonction de la stratégie de version définie dans le fichier de configuration du produit. Si la version du produit est définie comme immuable, Service Catalog désactive la version précédente du produit.

5. Publier le produit : le pipeline de publication publie le produit dans Service Catalog.

Note

Le pipeline de publication est personnalisable. Par exemple, vous pouvez supprimer toutes les étapes qui ne sont pas applicables à votre cas d'utilisation. Vous pouvez également ajouter d'autres étapes si vous souhaitez ajouter d'autres contrôles, des validations supplémentaires ou une étape d'approbation manuelle. Ce guide ne contient pas d'instructions pour modifier le pipeline de publication. Pour plus d'informations, consultez la CodeBuilddocumentation CodePipelineet.