Komponenten von Enterprise Blueprint Factory

Die Enterprise Blueprint Factory besteht aus den folgenden Komponenten:

• Produkt-Repository — Ein Repository, in dem Sie die Blueprints speichern.

• Konfigurations-Repository — Ein Repository, in dem Sie die Konfigurationsdatei speichern, die Ihre AWS Service Catalog Portfolios und Produkte definiert.

• Konfigurationsdatei — Die Konfigurationsdatei, die definiert, welche Blueprints verfügbar sind, wer sie verwenden kann und wie sie verwendet werden können.

• Konfigurationspipeline — Eine DevOps CI/CD-Pipeline, die das Service Catalog-Portfolio und die Portfolioanteile einrichtet und für jedes Produkt eine Release-Pipeline erstellt.

• Release-Pipeline — Eine DevOps CI/CD-Pipeline, die Blueprints als Service Catalog-Produkte veröffentlicht. 

Das Cloud-Infrastrukturteam verwaltet in der Regel die gesamte Enterprise Blueprint Factory, da es jeden Blueprint genehmigen muss. Das DevOps Codeteam ist jedoch in der Regel für die Konfigurationspipeline und die Release-Pipeline verantwortlich. Um neue Blueprints zu veröffentlichen, interagieren Entwickler nur mit dem Produkt-Repository, dem Konfigurations-Repository und der Konfigurationsdatei.

Produkt-Repository

Das Produkt-Repository ist ein zentraler Ort, an dem Sie die von Ihrer Organisation genehmigten Pläne speichern.  Ein Blueprint-Administrationsteam und ein Sicherheitsteam überprüfen die Pull-Anfragen an dieses Repository, um sicherzustellen, dass jeder Blueprint die Organisations- und Sicherheitsanforderungen erfüllt. In diesem Handbuch verwenden wir GitHub für das Repository, aber Sie könnten auch eine Alternative verwenden.

Konfigurations-Repository

Das Konfigurations-Repository (Config Repo) ist der Ort, an dem Ihre Organisation die Konfigurationsdatei für Ihre Service Catalog-Portfolios und -Produkte speichert, die über die Enterprise Blueprint Factory veröffentlicht wurden. In diesem Handbuch verwenden wir das GitHub für das Repository, aber Sie könnten auch eine Alternative verwenden.

Konfigurationsdatei

Die Enterprise Blueprint Factory-Konfigurationsdatei (Konfigurationsdatei) ist im Konfigurations-Repository gespeichert, das dem Blueprint-Administratorteam gehört. Der Name dieser Datei ist bp_config.yml. Wenn ein Entwickler diese Datei aktualisiert, überprüft das Blueprint-Administratorteam die Änderungen. Durch das Zusammenführen der Änderungen in den Hauptzweig wird die Konfigurationspipeline initiiert. Die Konfigurationsdatei orchestriert die Veröffentlichung, gemeinsame Nutzung und Verteilung aller Blueprints, die über die Enterprise Blueprint Factory verwaltet werden.

Die Konfigurationsdatei ist eine YAML-Datei, die aus zwei Hauptobjekten besteht: und. portfolios products Im Folgenden finden Sie ein Beispiel für eine Beispielkonfigurationsdatei:

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

Im portfolios Objekt definieren Sie Ihre Ziel-Portfolios für Service Catalog. Für jedes Portfolio geben Sie die folgenden Attribute an:

• portfolio_nameist der Name des Portfolios. Dieses Attribut ist erforderlich.

• ownerist der Name des Teams, dem das Portfolio gehört. Dieses Attribut ist optional.

• provider_nameist der Name des Teams oder der Organisation, die das Portfolio verwaltet. Der Standardwert ist AWS. Dieses Attribut ist erforderlich.

• descriptionist eine kurze Beschreibung des Portfolios. Dieses Attribut ist optional.

• portfolio_access_rolessind die AWS Identity and Access Management (IAM-) Identitäten (Benutzer, Rollen oder Gruppen), die auf das Portfolio und die zugehörigen Produkte zugreifen dürfen. Dieses Attribut ist optional.

• share_to_ouist die Organisationseinheit (OU) AWS Organizations , mit der das Portfolio geteilt wird. Endbenutzer können die Produkte dieses Portfolios einsetzen AWS-Konten , in denen sie Mitglieder der Ziel-OU sind. Dieses Attribut ist optional.

• stack_tagssind die Tags, die auf das Portfolio angewendet wurden. Dieses Attribut ist optional.

Im products Objekt definieren Sie jeden Blueprint, den Sie als Produkt im Service Catalog veröffentlichen möchten. Für jedes Produkt geben Sie die folgenden Attribute an:

• nameist der Name des Produkts im Service Catalog. Dieses Attribut ist erforderlich.

• descriptionist eine kurze Beschreibung des Produkts. Dieses Attribut ist erforderlich.

• product_config_fileist der Name der Blueprint-Produktkonfigurationsdatei, die im Produkt-Repository gespeichert ist. Dieses Attribut ist erforderlich.

• ownerist der Name des Teams, dem das Produkt gehört. Dieses Attribut ist erforderlich.

• stack_tagssind die Tags, die auf das Produkt aufgebracht wurden. Dieses Attribut ist optional.

• portfolio_associationssind die Zielportfolios, die das Produkt enthalten. Dieses Attribut ist optional.

  Anmerkung

  Wir empfehlen, Produkte nur zu Portfolios hinzuzufügen, die über die Enterprise Blueprint Factory verwaltet werden. Wenn Sie Produkte zu Portfolios hinzufügen möchten, die nicht über die Enterprise Blueprint Factory verwaltet werden, muss die IAM-Richtlinie des Benutzers dies zulassen. AssociateProductWithPortfolio Aus Sicherheitsgründen empfehlen wir jedoch, diese Aktion nur für die Enterprise Blueprint Factory-Konfigurationspipeline zuzulassen.

• launch_constraint_roleist die Startrolle, die Service Catalog übernimmt, wenn ein Endbenutzer das Produkt startet. Dieses Attribut ist erforderlich.

Konfigurationspipeline

Die Konfigurationspipeline (Config-Pipeline) automatisiert die Konfiguration des Service Catalog-Portfolios und der Portfolioanteile. Sie erstellt auch die Release-Pipeline für jedes Produkt. Diese Pipeline ist eine AWS CodePipelineRessource. Ein Update der Konfigurationsdatei ruft die Konfigurationspipeline auf.

Wenn Sie die Konfigurationspipeline zum ersten Mal aufrufen, erstellt sie zwei zusätzliche Portfolios, die nicht in Ihrer Konfigurationsdatei definiert sind:

• Blueprint-portfolio— Jedes Produkt, das Sie über die Enterprise Blueprint Factory bereitstellen, wird diesem Portfolio hinzugefügt. Dieses Portfolio steht den IAM-Prinzipalen und Organisationseinheiten zur Verfügung, die Sie in der Konfigurationsdatei angeben.

• Bootstrapping-Admin-Portfolio— Das Bootstrapping-Admin-Product Produkt ist diesem Portfolio zugeordnet. Dieses Produkt ist eine CloudFormation Vorlage für die Release-Pipeline. Erlauben Sie nur dem Blueprint-Administratorteam den Zugriff auf dieses Portfolio, sodass es die Verwaltungsprodukte verwalten kann.

Phasen der Konfigurationspipeline

Die folgende Abbildung zeigt die Phasen in der Konfigurationspipeline und die Ressourcen, mit denen die Pipeline interagiert. Jede Phase in der Pipeline ist ein AWS CodeBuildProjekt.

Im Folgenden sind die Phasen der Konfigurationspipeline aufgeführt:

1. Portfolios bereitstellen — Die Konfigurationspipeline stellt alle Portfolios bereit, die der Konfigurationsdatei hinzugefügt wurden, oder löscht alle Portfolios, die aus der Konfigurationsdatei entfernt wurden. Wenn es keine Änderungen an den Portfolios gibt, überspringt die Pipeline diese Phase.

2. Portfolios teilen — Die Konfigurationspipeline teilt die Portfolios mit den Zielorganisationseinheiten (OUs). Wenn es keine Änderungen an den Portfolioanteilen gibt, überspringt die Pipeline diese Phase.

3. Bereitstellen Blueprint-Admin-Bootstrapping-Product — Die Konfigurationspipeline ruft den bp-pipeline Blueprint aus dem ServiceCatalog-CodeRepo Repository ab und stellt ihn in Service Catalog als bereit. Bootstrapping-Admin-Product Dieses Produkt ist die CloudFormation Vorlage, die verwendet wird, um eine Release-Pipeline zu erstellen. Die Bereitstellung dieser Vorlage als Service Catalog-Produkt trägt zur Aufrechterhaltung der Versionskontrolle bei. Wenn es keine Änderungen am bp-pipeline Blueprint gibt, überspringt die Pipeline diese Phase.

4. Release-Pipelines erstellen — Basierend auf den Produktattributen in der Konfigurationsdatei bereitet die Konfigurationspipeline die Stack-Parameter vor und startet einen CloudFormation Stack, der eine Release-Pipeline für das Produkt erstellt. Weitere Informationen finden Sie unter Release-Pipeline in diesem Handbuch.

5. Produkte bereitstellen — Die Release-Pipeline stellt den Blueprint als Service Catalog-Produkt bereit und ordnet ihn dem Zielportfolio zu. Endbenutzer können das Produkt jetzt bereitstellen AWS-Konten , wenn sie Mitglieder der Ziel-OU sind.

Pipeline veröffentlichen

Die Release-Pipeline automatisiert die Veröffentlichung von Blueprints als Service Catalog-Produkte. Diese Pipeline ist eine AWS CodePipelineRessource. Wenn Ihre Organisation einen neuen Blueprint veröffentlichen möchte, lädt ein Entwickler die IaC-Vorlage und die zugehörige Produktkonfigurationsdatei in das Produkt-Repository hoch. Das Hinzufügen der Produktdetails zur Konfigurationsdatei löst die Konfigurationspipeline aus. Die Konfigurationspipeline erstellt eine Release-Pipeline für diesen Blueprint. Alle nachfolgenden Aktualisierungen des Blueprints veranlassen diese Release-Pipeline, das Produkt im Service Catalog mit einer neuen Version zu aktualisieren.

Die Release-Pipeline umfasst proaktive Kontrollen, mit denen die Sicherheits- und Konformitätsprüfungen für Ihre Blueprints automatisiert werden. Proaktive Kontrollen sollen verhindern, dass Ressourcen entstehen, die nicht den Vorschriften entsprechen. Diese Kontrollen können die Anzahl der Sicherheitsereignisse reduzieren, die durch andere Arten von Sicherheitskontrollen, wie z. B. reaktive und detektive Kontrollen, behandelt werden. Da proaktive Kontrollen sicherstellen, dass die bereitgestellten Ressourcen den Vorschriften entsprechen, bevor sie eingesetzt werden, gibt es kein Erkennungsereignis, das eine Reaktion oder Behebung erfordert.

Wenn Sie die Konfigurationspipeline zum ersten Mal aufrufen, wird ein Service Catalog-Produkt mit einem Namen Bootstrapping-Admin-Product erstellt. Dieses Produkt ist die CloudFormation Vorlage für die Release-Pipeline. Wie in der folgenden Abbildung dargestellt, verwendet die Konfigurationspipeline das Bootstrapping-Admin-Product Produkt, um eine spezielle Release-Pipeline für jeden neuen Blueprint zu erstellen. Es besteht eine one-to-one Beziehung zwischen Blueprints und Release-Pipelines.

Phasen der Release-Pipeline

Die folgende Abbildung zeigt die Standardphasen in der Release-Pipeline und die Ressourcen, mit denen die Pipeline interagiert. Jede Phase in der Pipeline ist ein CodeBuild Projekt.

Im Folgenden sind die Phasen der Release-Pipeline aufgeführt:

1. Dateiausrichtung — In dieser Phase wird überprüft, ob es sich bei dem Blueprint um eine CloudFormation Vorlage oder ein Konstrukt handelt AWS Cloud Development Kit (AWS CDK) . Wenn es sich bei dem Blueprint um ein AWS CDK Konstrukt handelt, wird das AWS CDK Konstrukt in dieser Phase zu einer Vorlage synthetisiert. CloudFormation Dieser Prozess automatisiert und standardisiert Bereitstellungen durch. CloudFormation Wenn Fehler gefunden werden, schlägt die Pipeline fehl.

2. Syntaxprüfung — Syntaxfehler sind eine häufige Ursache für CloudFormation Bereitstellungsfehler. In dieser Phase sucht AWS CloudFormation Linter (cfn-lint) nach Syntaxfehlern, indem es die Vorlage mit der Ressourcenspezifikation vergleicht.AWS CloudFormation Es führt auch andere Prüfungen durch, z. B. die Überprüfung auf gültige Werte für Ressourceneigenschaften und die Einhaltung von Best Practices. Wenn Fehler gefunden werden, schlägt die Pipeline fehl und cfn-lint gibt Vorschläge zurück.

3. Kontrollprüfung — In dieser Phase sucht cfn_nag anhand von Mustern nach potenziellen Sicherheitsproblemen. Es sucht beispielsweise nach zu freizügigen Sicherheitsgruppen und AWS Identity and Access Management (IAM-) Richtlinien, fehlender Verschlüsselung und Passwortliteralen. Wenn Fehler gefunden werden, schlägt die Pipeline fehl und cfn_nag gibt Vorschläge zurück.

4. Versionsprüfung — Die Release-Pipeline führt die Versionskontrolle auf der Grundlage der Versionsstrategie durch, die in der Produktkonfigurationsdatei definiert ist. Wenn die Produktversion als unveränderlich definiert ist, inaktiviert Service Catalog die vorherige Produktversion.

5. Produkt veröffentlichen — Die Release-Pipeline veröffentlicht das Produkt im Service Catalog.

Anmerkung

Die Release-Pipeline ist anpassbar. Sie können beispielsweise alle Phasen entfernen, die für Ihren Anwendungsfall nicht relevant sind. Sie können auch weitere Phasen hinzufügen, wenn Sie weitere Kontrollprüfungen, zusätzliche Validierungen oder einen manuellen Genehmigungsschritt hinzufügen möchten. Dieses Handbuch enthält keine Anweisungen zum Ändern der Release-Pipeline. Weitere Informationen finden Sie in der CodeBuildDokumentation CodePipelineund.