Wie Azure Machine Configuration für mehr Sicherheit und Transparenz sorgt

Was ist Powershell Desired State Configuration?

Powershell Desired State Configuration (DSC) in Version 1.1. ist Teil von Powershell 5.1 und seit Windows Server 2016 in das Betriebssystem integriert. Es ist ein „Configuration-as-Code“-Tool, das speziell für Windows-Systeme entwickelt wurde.

Im Gegensatz zu Powershell-Skripten, die definieren, welche Aufgaben in welcher Reihenfolge erledigt werden sollen, beschreibt Powershell DSC nur noch das Ergebnis. Wie dieses Ergebnis erreicht wird, ist bereits in dem verwendeten Powershell DSC Modul definiert. Dazu bietet der Local Configuration Manager in Windows, der Dienst, der im Hintergrund die definierte Konfiguration anwendet, eine Audit- und Korrektur-Funktion an. Damit kann die definierte Konfiguration auf Abweichungen überwacht und falls gewünscht auch automatisch wieder korrigiert werden.

Die Ergebnisse der Überwachung sowie Fehlermeldungen bei der Anwendung der Konfiguration werden in einem speziellen Windows Ereignis-Protokoll gespeichert.

Aber warum lohnt sich denn der Einsatz von Configuration-As-Code-Tools gegenüber klassischen Skripten denn überhaupt? In vielen Umgebungen liegen doch bereits funktionierende Skripte vor. Warum also wieder auf was anderes umstellen?

Der Nachteil von Skripten ist, dass diese nicht mit den gleichen Ergebnissen mehrfach auf der gleichen Umgebung ausgeführt werden können. Auch brechen die meisten Skripte beim Auftreten von Fehlern ab und müssen dann wieder von vorn gestartet werden. Dies kann wieder zu anderen Problemen führen, wenn Teile der Konfiguration schon vorhanden sind, andere aber noch nicht. Am Ende kann man oft nicht genau sagen, welchen Zustand eine Maschine genau hat, ob alle geforderten Einstellungen auch wirklich umgesetzt wurden. Sollen später Änderungen gemacht werden oder bestimmte Konfigurationen komplett entfernt werden, werden wieder andere Skripte benötigt.

Das Ziel von Configuration-as-Code-Tools wie Powershell DSC ist, die Komplexität bei der Einrichtung von Servern zu reduzieren und einen gewünschten Zustand reproduzierbar auf einer großen Anzahl an Maschinen sicherzustellen.

Was ändert sich mit Powershell DSC 2.0?

Mit Powershell DSC 2.0 löst sich Microsoft vom Local Configuration Manager und macht den Sprung zu Powershell 7.0. Die Powershell DSC-Module sind nicht mehr Bestandteil der allgemeinen Powershell-Installation und eigenständig zu installieren. Das ermöglicht es, unabhängig vom Powershell-Release-Zyklus häufiger Updates bereitzustellen.

Die Anwendung der Konfiguration wird jetzt ausschließlich in Azure mit Hilfe von Policy-Mechanismen gesteuert. Dieser Ansatz erlaubt es, auch die Vorteile der Policy-Infrastruktur in Azure zu nutzen, wie

• Zentrale Verteilung von Konfigurationen auf verschiedenen Hierarchie-Ebenen
• Überwachung der Ergebnisse in übersichtlichen Dashboards mit Hinweis auf Maschinen, die von der Definition abweichen
• Paralleles Anwenden verschiedener Konfigurationen
• Unterscheidung zwischen reinen Audit-Konfigurationen und erzwungenen Konfigurationen
• Unterstützung für hybride Umgebungen über Azure Arc-integrierte virtuelle Maschinen

Wo Powershell DSC 1.1. nur eine Konfiguration für eine virtuelle Maschine anwenden konnte, können nun mit Azure Machine Configuration beliebig viele Konfigurationen parallel angewendet werden. Das erleichtert das Schreiben von Konfigurationen und vereinheitlicht das Management der Umgebung deutlich.

Für komplexere Konfigurationen, die nicht geteilt werden können, empfiehlt es sich, eigene Powershell DSC-Module dafür zu erstellen. Dadurch wird das Deployment selbst wieder vereinfacht. Die Erstellung eines Moduls ist zwar am Anfang deutlich aufwändiger als die Erstellung komplexer Konfigurationen, dies rentiert sich in entsprechend großen Umgebungen schnell durch eine höhere Flexibilität und Konformität. Auch gehe ich davon aus, dass die DSC-Community weitere Module bereitstellt, die für Powershell DSC 2.0 und neuer eingesetzt werden können.

Ein Nachteil aus meiner Sicht ist, dass die Ausführung der Konfiguration jetzt ausschließlich mit dem „Local System“-Konto vorgenommen wird. In Powershell DSC 1.1 konnte man noch ein Credential mitgeben, welches dann nur die notwendigen Berechtigungen besitzen musste. Da das Credential Teil der Konfigurationsdatei ist, muss dieses aus Sicherheitsgründen immer mit einem Zertifikat verschlüsselt werden. Diesen zusätzlichen Konfigurationsaufwand spart man sich nun in Powershell DSC 2.0. Dabei ließe sich in Azure die Ablage eines Credential gut über den Azure Key Vault lösen. Ich würde es begrüßen, wenn eine solche Integration möglich wäre. Alternativ kann diese Integration in selbstgeschriebenen Modulen natürlich umgesetzt werden.

Wer nicht nach Azure umsteigen möchte, sich aber trotzdem von Powershell DSC 1.1 und damit Powershell 5.1 lösen möchte, hat derzeit nur die Möglichkeit, die Methoden aus den Powershell-DSC-Modulen direkt mit „invoke-DscResource“ aufzurufen. Das ist zwar etwas umständlicher, ermöglicht aber, ein eigenes Skript zu bauen, welches die Aufgabe des Local Configuration Managers übernimmt.

Wo geht die Reise hin?

Aktuell gibt es Powershell DSC 3.0 in der Preview. Die wesentliche Neuerung hier ist, dass jetzt auch Linux-Systeme damit konfiguriert werden können. Z.B. kann damit die Installation von Anwendungen und Diensten auf neuen Linux-Systemen besser gesteuert werden als bisher nur mit der Script-Extension in Azure.

Um dies zu erreichen hat sich Microsoft von Powershell gelöst und unterstützt jetzt verschiedene weitere Skriptsprachen wie bash, python, C# oder Go. Der Name in der Preview ist deshalb auch nur noch „Desired State Configuration (DSC) 3.0“ oder kurz DSCv3.

In der neuen CLI für DSCv3 wird es dann auch wieder möglich sein, ein gesamtes Konfigurations-Dokument auf einmal anzuwenden, wo noch bei Powershell DSC 2.0 nur eine einzelne Ressource manuell gesteuert werden konnte.

Fazit

Ich finde die aktuellen Entwicklungen von Microsofts Desired State Configuration vielversprechend. Die Entkopplung von Powershell sorgt sicher für eine größere Akzeptanz und bessere Integrationsmöglichkeiten in etablierte Configuration as Code-Tools wie Ansible, Chef oder Puppet.

Die Möglichkeit, DSC-Konfigurationen über Azure Policy-Mechanismen großflächig zu verteilen und zu überwachen, bietet eine deutlich höhere Transparenz über den Zustand der laufenden Maschinen. Damit können auch Sicherheitsregularien nicht nur auf Maschinen-Ebene, sondern auch auf Anwendungsebene angewendet und überwacht werden.