Der 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.

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 Mangerund 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.

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.

Systems Manager: 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.

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.

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.

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.

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.

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.

Bei Bedarf hätte man das Kommando bzw. Shell-Script via „Resource Group“s 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.

Ein Automatisiertungsbeispiel „Create Image“.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.

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.