AWS Systems Manager: EC2-Instanzen patchen, Wartungsaufgaben automatisieren

    AWS Systems ManagerDer AWS Systems Manager ist eine umfang­reiche und mäch­tige Tool-Suite für das opera­tive Manage­ment von EC2-Instan­zen. Zu den Auf­gaben, die sich damit bewäl­tigen lassen, gehören das Patch-Management für Gast­betriebs­systeme, das Update von Anwen­dungen oder das Starten von Scripts in VMs.

    Das Menü im Dashboard von Systems Manager unterteilt sich in die Bereiche Resource Groups, Insights und Actions. Resource Groups dienen im Wesentlichen dem Zusammen­fassen von Ressourcen, um auf diese gemeinsame Aktionen anzuwenden. Insights ist für das Erstellen und Organisieren von Dashboards und somit für die visuelle Darstellung gedacht. Der Abschnitt Actions gliedert sich in die Module Run Command, Automation, Patch Manager, State Manger und Maintenance Windows.

    SSM Agent und IAM-Rolle

    Der Systems Manager kann nur solche EC2-Instanzen verwalten, in denen ein SSM-Agent installiert ist. Das wiederum setzt voraus, dass in der Instanz ein von Systems Manager unterstütztes Betriebs­system läuft (siehe dafür die entsprechende Übersicht von AWS).

    Was dabei zählt, ist die Installier­barkeit des SSM-Agenten (Systems Manager Agent) für Windows- oder Linux-Instanzen. Am besten ist es daher, man verwendet ein AMI, in dem der SSM-Agent bereits integriert ist, wie bei Windows Server 2016 oder Amazon Linux in einer aktuellen Version. Die manuelle Installation, etwa für Amazon Linux, ist aber auch nicht schwierig. Dazu legt man zunächst ein temporäres Verzeichnis an

    mkdir /tmp/ssm

    wechselt dorthin

    cd /tmp/ssm

    und führt dann folgendes Kommando aus:

    sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm

    Ob die Installation erfolgreich war, findet man unter Amazon Linux mit

    sudo status amazon-ssm-agent

    und unter Amazon Linux 2 mit

    sudo systemctl status amazon-ssm-agent

    heraus.

    Außerdem braucht der Systems Manager passende Berechtigungen auf der EC2-Instanz. Hat das  verwendete IAM-Benutzerkonto, die Benutzergruppe oder das bereits zugewiesene Instanz-Profil Administrator­berechtigungen, dann kann man das Thema vorerst ignorieren.

    Tatsächlich hat der Systems Manager per Default keinerlei Berechtigungen zur Ausführung von Aktionen auf den verwalteten Instanzen. Daher kommt man normaler­weise um das Erstellen einer IAM-Instance-Profilrolle nicht herum, die man an die zu veraltenden Instanzen zuweisen muss. Zu diesem Zweck stellt AWS eine verwaltete Rolle (SystemsManager-Role) sowie eine Reihe verwalteter Policies zur Verfügung.

    AWS stellt für den Systems Manager eine verwaltete Rolle bereit. 

    Ist der SSM-Agent in der zu verwaltenden Instanz aktiv und wird diese mit passenden Berechtigungen für SSM ausgeführt, dann sollte diese im Systems Manager unter Managed Instances im Abschnitt Shared Resources auftauchen, andernfalls passt etwas mit den Berechtigungen oder dem Agenten nicht.

    Instanzen, in denen der Agent des Systems Manager aktiv ist, tauchen automatisch unter Managed Instances auf.

    Actions

    Im Abschnitt Actions im Dashboard von Systems Manager verbergen sich alle jene Funktions­gruppen, die vorbereitete Remote-Aktionen auf Instanzen durchführen, wie Run Command, Automation, Patch Manager, State Manger und Maintenance Windows. Hier eine grobe Zusammen­fassung.

    Patch Manager

    Mit dem Patch Manager können Nutzer das Patchen sämtlicher von SSM verwalteter Instanzen automatisieren. Dazu prüft das Tool die Instanzen auf fehlende Updates und kann diese mit Hilfe von Amazon EC2-Instance-Tags einzeln oder auf Ressource Groups innerhalb des definieren Wartungs­fensters anwenden.

    Für sicherheits­relevante Patches verwendet Amazon Baselines, die Regeln für die automatische Genehmigung von Patches enthalten können. Dadurch werden diese etwa nach einer festgelegten Anzahl von Tagen nach ihrer Veröffent­lichung eingespielt. Der Patch Manager verwaltet dazu Listen von genehmigten und zurück­gewiesenen Patches.

    Der Patch-Manager operiert auf Basis von Baselines, die sich mit diesem Tool definieren lassen.

    Er dient auch dem Definieren von Baselines und ist eng mit der Funktion Wartungsfenster integriert, in dem der Nutzer wieder­kehrende Zeitpläne für das Ausführen von Verwaltungs­aufgaben definiert. Dazu gehören etwa das Installieren von Patches und Updates, ohne dass es zu Unter­brechungen geschäfts­kritischer Vorgänge kommt.

    State Manager und Automation

    Der State Manager schließlich automatisiert den Vorgang, mit dem die verwalteten Instanzen in einem definierten Status gehalten werden. Mit seiner Hilfe können Admins zum Beispiel sicherstellen, dass im Rahmen des Bootstrapping (cloudinit) nur bestimmte Software-Updates installiert oder beim Starten von Windows-Instanzen der Beitritt zu einer Windows-Domäne erfolgt.

    Das Automation-Feature schließlich dient dem Automatisieren von Wartungs- und Bereit­stellungs­aufgaben, wie dem Erzeugen oder Aktualisieren von Amazon Machine Images, dem Update von Treibern und Agents sowie dem Anwenden von Betriebssystem-Patches oder Anwendungs-Updates.

    Das älteste Feature von AWS Systems Manager ist EC2 Run Command, mit dem AWS-Nutzer von extern (remote) Shell-Scripts oder einzelne Befehle auf EC2-Instanzen ausführen können. Es stellt quasi eine Untermenge von Automation dar.

    Documents

    Die eigentliche Handhabung von Systems Manager ist relativ ungewöhnlich. Während man in Patch Manager, Maintenance Windows und State Manager gewisser­maßen nur Profile definiert, erfordert das Anwenden von Run Command oder Automation das Auswählen eines so genannten SSM-Document.

    AWS stellt einige hundert vorbereitete Dokumente bereit, sie können aber vom Nutzer auch selbst erstellt werden. Sämtliche momentan verfügbaren SSM-Dokumente finden sich im Abschnitt Shared Resources => Documents.

    Für Run Command bringt der Systems Manager zahlreiche vorkonfigurierte Dokumente mit.

    Sinn und Zweck von SSM-Dokumenten bzw. der Umgang damit erschließt sich oft erst mit der Zeit oder durch praktisches Anwenden. Daher bringe ich für die zahlreichen Features von Systems Manager hier je ein Beispiel für Run Command und Automation.

    Ausführen eines Shell-Scripts über das dafür vorgesehene Document

    Um ein externes Kommando SSM Run Command abzusetzen, klickt man im Menü Actions auf Run Command und dann auf die Schaltfläche Run a Command.

    Im nächsten Schritt sucht man sich dann ein Command document aus. Wir entscheiden uns für AWS-RunShellScript. In der Spalte Platform types steht jeweils, für welche Plattform dieses geeignet ist.

    Befehl, der in der Shell ausgeführt werden soll

    Dann scrollt man etwas nach unten und trägt bei Commands das gewünschte Kommando oder Bash-Script ein. Exemplarisch belassen wir es beim einzelnen Kommando

    sudo ip addr

    Angaben für Working Directory und Execution Timeout sind optional.

    Instanzen auswählen, auf die das Kommado angewandt werden sollen.

    Schließlich wählt man ganz unten bei Targets die gewünschte Ziel-Instanz aus und aktiviert, falls gewünscht, das Schreiben der Ausgabe auf ein S3-Bucket sowie ggf. auch zu CloudWatchLogs.

    Optionen für den Output des Kommandos

    Sofern alles richtig konfiguriert war, sollte Systems Manager

    Commend ID: <Command-ID> sucessfully sent

    melden und bei Step 1 - Command description and status unter Status den Eintrag Sucess. Klappt man dann den Dialog bei Step 1- Output auf, dann sieht man die Ausgabe direkt in der SSM-Konsole.

    Ausgabe des Kommandos in der Konsole des Systems Manager

    Bei Bedarf hätte man das Kommando bzw. Shell-Script via Resource Groups auch an eine Flotte von Instanzen senden können.

    In der Praxis wird man gerade solche Operations­aufgaben eher nicht in der SSM-Konsole ausführen, sondern CLI-gesteuert im Rahmen eines Skriptes. Ein entsprechender Befehl könnte etwa so aussehen:

    aws ssm send-command --document-name "AWS-RunShellScript" --parameters commands="sudo ip addr",executionTimeout=3600 --instance-ids instance-ID --endpoint-url "https://eu-central-1.amazonaws.com" --region "eu-central-1" --document-version "\$DEFAULT, \$LATEST, or a version number"

    Als letztes Beispiel für eine Automation wählen wie nun eine Aktion mit dem Automations-Document AWS-CreateImage und aktivieren weiter unten im Dialog den Schieber bei Input parameters => Instancid => Show interactive instance picker, um explizit eine der SSM-verwalteten Instanzen auswählen zu können. Dann klickt man rechts unten auf Execute automation und schon wird das gewünschte Image erzeugt.

    Neues AMI erzeugen mit Hilfe eines Kommandos im Systems Manager

    Der eigentliche Prozess dauert allerdings hier etwas länger. Daher meldet die SSM-Konsole oben zunächst Execution has been initiated und bei Execution status erscheint vorerst In Progress.

    Ausgabe von AWS-CreateImage in der SSM-Konsole

    Hat der Status nach kurzer Zeit auf Success gewechselt, dann kann man wieder weiter unten den Bereich Outputs aufklappen, der die erzeugte AMI-ID anzeigt.

    Keine Kommentare