Vollständig automatisierte Bereitstellung von AWS-Konten auf Unternehmensebene über Self-Service mit Jira Service Desk

Die folgenden Voraussetzungen sind notwendig , um den Inhalten dieses Beitrags zu folgen:

• Ein bestehendes AWS-Konto
• Jira Service Desk Software
• Aktivierte E-Mail-API in Jira

Die folgende Architektur zeigt die gesamte Lösung des Kontoverkaufsautomaten. In diesem Beitrag konzentrieren wir uns auf die Jira Service Desk-Integration, die grün hervorgehoben ist.

Wir haben uns gegen die Verwendung eines Plugins entschieden, um die Abhängigkeiten/Einschränkungen zu reduzieren, insbesondere mit dem Fokus auf Jira Cloud. Glücklicherweise bietet Jira alles, was wir brauchen, um unsere eigene Lösung zu entwickeln.

Anfragetyp

Mit Anfragetypen kann man eingehende Anfragen definieren und organisieren. Erstellt einen neuen Anfragetyp für die Anforderung neuer AWS-Konten. Um den Kunden die Suche zu erleichtern, erstellt zusätzlich eine Gruppe "Account Vending Machine", in der diese Anfragetypen organisiert werden.

Der Request Type basiert auf dem Issue Type "New Feature" und wird vom OTTO-Jira-Administrationsteam bereitgestellt. Der verwendete Workflow ist die Standardkonfiguration "open"=>"in progress"=>"in validation"=>"closed"-Konfiguration.
Beachtet dabei, dass ihr den Zugriff auf den Jira-Anfragetyp auf eine begrenzte Anzahl von Ressourcen beschränken sollten, die eine Geschäftsrolle in eurem Unternehmen haben, um die Beantragung neuer AWS-Konten zu ermöglichen.

Besonders in großen Umgebungen ist es für Jira-Administratoren ein zusätzlicher Aufwand, für jeden Anwendungsfall neue Felder zu erstellen. Wir haben dies umgangen, indem wir bestehende Felder wiederverwendet und einen "Anzeigenamen" gesetzt haben.

Nach der Einrichtung sieht die Ansicht des Kunden im Supportportal wie folgt aus:

Sobald die erforderlichen Felder ausgefüllt sind und die Schaltfläche "Erstellen" gewählt wird, wird ein neuer Antrag gestellt.

Beachtet das Feld "IT-Shop Genehmiger", das später sehr wichtig ist. Das Feld basiert auf dem "Person Picker" von Jira, mit dem ihr Personen aus dem Jira-Verzeichnis abrufen könnt, das in unserem Fall mit dem Active Directory des Unternehmens synchronisiert ist.

In Bezug auf den Prozess haben wir uns gegen eine vollständige Automatisierung entschieden, so dass wir die Qualität der eingegebenen Felder kurz überprüfen können, bevor wir die Jira-Automatisierung in Gang setzen.

MitJira-Automatisierungsregeln könnt ihr Aktionen auf der Grundlage bestimmter Auslöser und Bedingungen durchführen. In unserem Fall möchten wir die Anfrage genehmigen und die ausgefüllten Felder aus der neuen AWS-Kontoanfrage senden, um die Kontoerstellung in AWS auszulösen.

Diese Automatisierungsregel wendet die folgende Aktion an, nachdem ein Kunde eine neue AWS-Kontoanforderung erstellt hat:

1. Wenn ein GAS-Teammitglied die Anfrage genehmigt, indem es ihr den Status "in Bearbeitung" gibt.
2. Jira Automation wird ausgelöst und sendet die Anfrage als Nutzlast an einen Webhook: den API-Gateway-Endpunkt in AWS.

Jira Automation verwendet eine Kombination aus "WHEN", "IF" und "THEN", um Aufgaben zu automatisieren.

API-Gateway

Die nächste Anforderung an die Architektur ist die API, die unsere Nutzdaten empfängt, zum Beispiel "etwas", das wir als Webhook-URL verwenden können.

Die naheliegende Lösung war die Verwendung von API Gateway.

Es kümmert sich um die Authentifizierung, indem es das im Header gelieferte API-Token auswertet und bei Erfolg die Lambda-Integration verwendet, um die von Jira empfangene Nutzlast zu übergeben. Seht hier, wie man ein API-Gateway mit Lambda-Integration einrichtet.

Aufgrund der Informationen, die für den Konto-Automaten benötigt werden, kommt ihr um benutzerdefinierte Felder in Jira nicht herum. Diese Felder sind nicht so benannt, wie ihr es in der Jira-Konfiguration seht. Stattdessen verwenden sie das Format "customfield_xyz" innerhalb der Nutzdaten.

Um die Felder zu identifizieren, die ihr für die Verarbeitung benötigt, empfehlen wir, ein Ticket mit leicht erkennbaren Werten zu füllen und dann einen Payload-Dumper wie diesen (oder euren Lambda) zu verwenden, um die Payload auf die benötigten Feldschlüssel zu überprüfen.

Alternativ könnt ihr auch die Funktion "Inspect Element" eures Browsers verwenden, während ihr das JSD-Ticket geöffnet haben.

In unserem Fall, wie im Screenshot des Tickets gezeigt, verwenden wir einige Felder, z. B. "E-Mail-Adresse", um die Kontakt-E-Mail des Kontos abzufragen. Dieses Feld ist in unserer OTTO-spezifischen Jira-Umgebung als "customfield_12949" gekennzeichnet.

Sobald alle erforderlichen Felder identifiziert sind, verwendet Lambda, um die Nutzlast zu verarbeiten. Je nach der von euch verwendeten Programmiersprache können ihr sie entweder direkt in Python ansprechen oder das JSON in ein Datenobjekt umwandeln.

Sobald dies geschehen ist, empfehlen wir, Lambda für die Vorverarbeitung der Werte zu verwenden, z. B. um sicherzustellen, dass keine führenden oder nachfolgenden Leerzeichen vorhanden sind, oder um Groß- in Kleinbuchstaben zu konvertieren.

Schließlich verwendet Lambda AWS SDK, um einen neuen Codebuild-Projektlauf auszulösen, wobei die aus der Nutzlast abgerufenen Variablen als Umgebungsvariablen verwendet werden.

Das Kontoautomaten-Backend besteht aus AWS Systems Manager-Parametern, einem AWS CodeBuild, ein paar Lambdas und einem Amazon SES. Anstatt eine Lambda-Funktion für die Hauptlogik wie den Kontoautomaten zu verwenden, haben wir uns für CodeBuild entschieden, da wir bei der Verwendung von Lambdas einige Fallstricke hatten.

Hier sind einige Probleme, die wir während der Entwicklung gelöst haben:

• Wenn ihr bei der Erstellung eines neuen AWS-Kontos mithilfe der AWS Organizations API ein zweites AWS-Konto erstellen möchtet, könnt ihr nur einen Vorgang gleichzeitig ausführen. Es wurde eine Wartefunktion implementiert, um die AWS-Kontoerstellungsanforderungen zu serialisieren.
• Um StackSet-Instances bereitzustellen, könnt ihr jeweils nur einen Vorgang ausführen und müsst warten, bis ein Vorgang abgeschlossen ist, bevor ihr einen weiteren Vorgang startet. Eine Wartefunktion wurde implementiert, um die StackSet-Erstellungsanforderungen zu serialisieren.
• Jira verwendet eine spezielle Notation, die Jira Text Formatting Notation, um formatierte Kommentare zu haben.

Da das Backend stark von eurer Einrichtung abhängt, halten wir dies in einer Blackbox fest. Wir sind jedoch einige Wege gegangen, von denen auch ihr lernen könnt:

• StackSet-Bereitstellung: Wir verwenden den AWS Parameter Store, um die Standard-Stacksets für die Bereitstellung zu konfigurieren. Wir haben weitere Stacksets, die optional sind - Teams können sie auch über JSD bestellen.
• Identitätsmanagement-Integration: Der OTTO-Ansatz sieht vor, AWS-IAM-Benutzer nur dann zu verwenden, wenn sie funktional/nicht menschlich sind. Jeder menschliche Benutzer muss seinen ADFS-Benutzer zur Authentifizierung und Autorisierung verwenden, was über IAM Identity-Provider + SAML-Response-Generator auf der ADFS-Seite realisiert wird.
  Da die Einrichtung ziemlich spezifisch ist, was die Wahl einer IDP-Management-Suite durch Ihr Unternehmen betrifft, werden wir hier nicht ins Detail gehen.
• In unserem Fall hat ein Konto "Freigabeberechtigte", wie in der Maske während des Bestellvorgangs angefordert.
• Wenn jemand Zugriff auf das Konto haben möchte, muss er eine bestimmte Rolle über unser IDP-Management-Portal bestellen, und die Genehmiger müssen die Anfrage annehmen oder ablehnen.

Um den Status der Kontoerstellung an Jira Service Desk zu senden, verwenden wir eine E-Mail , die über die Amazon SES Email API an die Jira-Instanz gesendet wird. Wir haben die gesamte Domäne unseres Mailservers verifiziert, um in der Lage zu sein, Mails von verschiedenen Teammitgliedern als Account Vending Machine zu versenden. Auf diese Weise weiß der Anfragende, wer den Account Vending Machine aufgerufen hat. Außerdem verwenden wir DKIM, um eine E-Mail mit einem privaten Schlüssel zu signieren, um zu überprüfen, dass Teile der E-Mail während der Übertragung nicht verändert wurden. Das eingesetzte Amazon SES ist ein zweites Tool-Konto, und wir können diese SES-Konfiguration für alle unsere Governance-Tools verwenden.

Wir haben uns für die E-Mail-API von Jira entschieden, weil wir bereits Erfahrung mit dieser API haben und einige unserer anderen Dienste diese API bereits nutzen, um Informationen an Jira-Tickets zurückzusenden. In Zukunft werden wir mit allen unseren Diensten auf die Jira-API umsteigen.

Der E-Mail-Text wird im Kontoverkaufsautomaten mit relevanten Informationen zu Kontometadaten, Links zum Zugriff auf das AWS-Konto- und Abrechnungs-Dashboard, Onboarding-Dokumentation für die Produktteams und implementierte Sicherheitsrichtlinien erstellt. Die E-Mail aktualisiert das entsprechende Jira-Thema Account Request, so dass das Produktteam schnell mit der Arbeit beginnen kann, während das zentrale Plattformteam einen Konfigurationsverlauf hat und Änderungen nachverfolgt.

Der Beauftragte des Tickets wird als Absenderadresse der E-Mail verwendet, was zu einer persönlicheren Ansicht führt, da Jira seine Identität für den Kommentar verwendet. Wichtig ist, dass beim Senden der E-Mail an Jira die Ticket-ID als Betreff verwendet wird, damit der Kommentar dem Ticket zugeordnet werden kann.

Den Teams wird die folgende Ansicht in der Jira Service Desk AWS-Kontoanforderung angezeigt: