Dies ist der dritte Teil meines IaC-Überblicks basierend auf einem persönlichen Experiment: dem Aufbau eines Cyber-Ranges unter Verwendung des IaC-Paradigmas. Hier sind die erste und zweite Teile.

Vor einigen Wochen traf ich Spacelift und hatte die Möglichkeit, ihr Produkt zu testen. Spacelift wird beschrieben als:

Collaborative Infrastructure for modern software teams

In der Praxis bietet Spacelift eine Web-Oberfläche und ein Framework zur Pflege, Prüfung und Organisation von Infrastrukturen unter Verwendung des IaC-Paradigmas (Infrastructure as Code).

Ich beschloss, meine Playbooks so anzupassen, dass sie innerhalb von Spacelift verwaltet werden können. Auch wenn mir Spacelift sehr gefällt, plane ich immer eine Ausstiegsstrategie. In der Praxis kann ich meine Playbooks außerhalb von Spacelift ausführen, und das ist für mich nützlich zum Entwickeln, Testen und Debuggen. Ich betrachte dies als “weiche” Bindung, und das ist mir sehr wichtig.

Dieser Beitrag fasst zusammen, wie ich Spacelift für mein einfaches Szenario verwendet habe. Beachten Sie, dass Spacelift leistungsfähiger ist und tatsächlich viele komplexe Szenarien abdecken kann.

Stacks: Instanzen von GitHub ausführen

Von der offiziellen Dokumentationsseite:

Stack is one of the core concepts in Spacelift. […] You can think about a stack as a combination of source code, the current state of the managed infrastructure (eg. Terraform state file), and configuration in the form of environment variables and mounted files.

In meinem Szenario benötige ich zwei Stacks: einen für Terraform und einen weiteren für Ansible. Ich habe drei Ansätze gesehen, um Stacks zu erstellen und zu pflegen:

• vollständig manuell: Alle Stacks werden von Menschen erstellt;
• vollständig automatisiert: Alle Stacks werden von Terraform erstellt;
• Hybrid: Der Hauptstack erstellt sekundäre Aufgaben.

Im vollständig automatisierten Ansatz werden alle Stacks und Beziehungen zwischen ihnen von Terraform erstellt. Alles rund um Spacelift kann mit dem IaC-Paradigma verwaltet werden, daher könnte dies der beste Weg für viele DevOps-Ingenieure sein. Manchmal werden auch die “Builder”-Stacks innerhalb von Spacelift verwaltet: In diesem Fall muss der Stack, der Spacelift-Projekte manipulieren kann, administrativ sein.

In meinem Szenario habe ich einen hybriden Ansatz verwendet: Der Hauptstack erstellt abhängige Stacks und die Beziehung zwischen ihnen, erstellt aber auch die AWS-Infrastruktur. Kurz gesagt, mein Terraform-Stack:

• wird manuell aus einem GitHub-Repository erstellt;
• wird bei jedem GitHub-Commit ausgelöst;
• nach der Planungsphase ist eine manuelle Bestätigung erforderlich;
• ist dafür verantwortlich, den Ansible-Stack und zugehörige Richtlinien und Umgebungen zu erstellen;
• ist dafür verantwortlich, die AWS-Infrastruktur zu erstellen;
• ist dafür verantwortlich, den Ansible-Stack auszulösen.

Lassen Sie uns sehen, wie der Terraform-Stack erstellt wird:

• Anbieter: GitHub
• Repository: dainok/iac
• Branch: master
• Projektstamm: lab-all-in-one-vulnerable-website
• Backend: Terraform
• Administrativ: true
• Name: lab-all-in-one-vulnerable-website

Sobald er erstellt wurde, kann der Stack ausgelöst werden:

Umgebung und Kontext

Spacelift-Stacks können mit Umgebungsvariablen (innerhalb des Stacks selbst) oder Kontext (einer Art gemeinsamer Umgebung) konfiguriert werden. Mein Ansatz besteht darin, Kontext zu definieren, der Daten enthält, die zwischen den Stacks gemeinsam genutzt werden können:

Kontext kann sowohl Umgebungsvariablen als auch Dateien enthalten. In meinem Szenario verwende ich:

• einen Kontext, der das Spacelift-API-Token definiert;
• einen Kontext, der das AWS-API-Token definiert;
• einen vom Terraform-Stack erstellten Kontext, der einige Daten zwischen dem Terraform- und dem Ansible-Stack teilt.

Um genauer zu sein, wird der letzte Kontext verwendet, um den SSH-Privatschlüssel mit dem Ansible-Stack zu teilen und einige Ansible-Umgebungsvariablen festzulegen.

Richtlinien: Verknüpfung von Terraform und Ansible

Spacelift verwendet ein Open-Source-Projekt namens Open Policy Agent und seine Regellanguage, Rego, um benutzerdefinierte Codefragmente auszuführen, die wir Richtlinien nennen, an verschiedenen Entscheidungspunkten.

Richtlinien können verwendet werden, um das Verhalten des Stacks zu ändern. Zum Beispiel können zusätzliche Sicherheitsüberprüfungen implementiert werden, oder es ist erforderlich, dass ein bestimmter Benutzer den Plan genehmigt. In meinem Fall habe ich verwendet:

• eine Push-Richtlinie, um die automatische Auslösung des Ansible-Stacks nach einem Commit zu vermeiden;
• eine Trigger-Richtlinie, um den Ansible-Stack nach dem Terraform-Stack auszuführen.

Am Ende habe ich zwei verschiedene Stacks, einen automatisch erstellt:

Der Ansible-Stack wird automatisch ausgelöst:

Manuelle Aktionen

Mein Szenario erfordert, dass ich mein Labor nach jeder Twitch-Sitzung zerstöre. Im Terraform-Stack kann ich einzelne Aufgaben aus führen:

Alles gut?

Die Implementierung von Ansible befindet sich noch im Beta-Stadium; abgesehen davon konnte ich meine Ziele erreichen. Ich habe einige Probleme festgestellt, aber das Spacelift-Team hat mir geholfen, sie alle zu beheben oder gute Workarounds zu finden. Keine Software ist perfekt, aber für mich ist am wichtigsten, wie der Anbieter mich unterstützt, wenn ich auf Fehler oder Probleme stoße.

Schlussfolgerungen

Ich fand Spacelift ein interessantes Framework, um IaC innerhalb von Unternehmen zu verwalten. Es enthält viele Sicherheitsüberprüfungen und Integrationen und unterstützt private Worker (kein Bedarf an einem öffentlichen Bastion-Host). Ingenieure können zusammenarbeiten, um jeden Durchlauf/Schritt/… zu verfolgen und zu kommentieren. Ich würde ihm auf jeden Fall genauer nachsehen.

Aber denken Sie daran, IaC ist zu 80% Planung und Standardisierung :)

Referenzen

• Spacelift Docs