Cloudrichtlinien mit Azure Policy

Die Übersicht über Cloud Services und Ressourcen zu behalten und diese zu Verwalten, kann schnell herausfordernd werden. Vor allem, wenn sich ein Projekt über mehrere Azure Subscriptions wie Development, Test oder Production erstreckt und unterschiedliche Teams involviert sind, die miteinander an einer Cloud Lösung arbeiten.  

Für solche Fälle kann es sinnig sein, dass beispielsweise gewisse Richtlinien für die Erstellung von Ressourcen festgelegt werden. Oder eine schnelle Übersicht über den aktuellen Compliance Stand der Umgebungen gewünscht ist, also geprüft werden soll, ob die eingeführten Regeln auch eingehalten werden.  

Um diese Problematiken zu erleichtern kann der Azure Policy Service genutzt werden. Um das umzusetzen muss einfach im Azure Portal unter All Services der Policy Service ausgewählt werden. Azure Policy verursacht keine Kosten.

Eine Policy ist eine Richtlinie, welche gewisse Vorgaben und Effekte festlegt und deren Einhaltung überprüft. So können Standards leicht umgesetzt und kontrolliert werden. Eine Policy kann auf Subscription oder Resource Group Ebene zugewiesen werden. 

Die Policies können über das Azure Portal, PowerShell und Azure CLI zugewiesen werden. Eine Übersicht über die aktuell festgelegten Richtlinien ist im Portal zu sehen. Hier ist im Detail jeder Service aufgeschlüsselt, der die gewünschten Vorgaben nicht erfüllt.  

Es ist möglich bereits fertige “Built-in” Policies zu nutzen oder eigene sog. “Custom Policies” zu implementieren. Weiterhin können verschiedene Policies zu sogenannten “Initiatives” zusammengefasst werden. Eine solche legt ein Ziel fest, welches durch die Einhaltung mehrere Policies erreicht wird, die so gruppiert werden. 

Funktionsweise

Soll eine Ressource erstellt werden, so erfolgt dies normalerweise über einen Request an den Azure Resource Manager. Es gibt auch ältere Services, bei denen dies anders verläuft aber darauf möchte ich hier nicht weiter eingehen. Jedenfalls werden die hinterlegten Policies geprüft und nur wenn alle Richtlinien erfüllt sind erfolgt ein Deployment der Ressource. Ansonsten kommt es zu einer Fehlermeldung. Wird eine Policy eingeführt werden alle Ressourcen in der Gruppe oder Subscription auf Compliance geprüft. Diese Überprüfung erfolgt periodisch und sobald eine neue Policy eingesetzt oder eine bestehende verändert wurde.

Bestandteile einer Policy

Wie bereits erwähnt, besteht eine Policy aus einem “if..then” Statement. Weiterhin gibt es logische Operatoren wie z.B “not”, Accessors und Conditions und natürlich die Felder die angesprochen werden können. 

Im “then” Statement gibt es zudem verschiedene Aktionen wie deny, audit, append, sowie “auditIfNotExists” und “deployIfNotExists”. Welche ausgeführt werden, wenn der “if” Teil erfüllt ist. Die letzten beiden sind beispielsweise dafür da, um unter gewissen Voraussetzungen zu prüfen ob Bestandteile einer Architektur fehlen und diese ggf. automatisch zu deployen. Also etwa wenn z. B. ein Virtuelles Netzwerk (VNET) erstellt wird, dann soll auch ein Network Watcher existieren. Es ist zu empfehlen, vorab eine neue Policy auf “audit” zu setzten, da hierdurch erstmal evaluiert wird für welche Ressourcen sie gültig ist und so keine Probleme mit einer laufenden Umgebung auftreten.

Beispielweise kann durch eine Custom Policy auch die Einhaltung einer Namenskonvention erzwungen werden.

Built-in Policies

Oftmals gibt es den Fall, dass dass ein Team (A) die Azure Umgebung verwaltet. Ein weiteres Team (B) aber darauf arbeitet und Services nutzt und erstellt. Das erste Team möchte nun, dass gewisse Vorgaben eingehalten werden. So soll es etwa nur möglich sein, Ressourcen in den Regionen Westeuropa und Nordeuropa zu erstellen. Dies wird durch die Verwendung der Built-in” Policy “Allowed Locations” möglich.

Diese Policy kann über das Azure Portal zugewiesen werden. Betrachtet man das zugehörige JSON so gibt es Einblick in den Aufbau. Jede Policy besteht aus einer “if..then” Struktur. Hier wird für alle Ressourcen das Feld “location” betrachtet. Passt nun eine Auswahl beim Erstellen eines Service nicht zu einem der Parameter in der vorgegebenen Liste, so tritt der Effekt “deny” in Kraft und die Erstellung wird verhindert. Die Auswahl der erlaubten Regionen wird beim aktivieren der Policy getroffen. 

Azure Policy kann weiterhin auch dafür genutzt werden, Audits durchzuführen.  Ssoll beispielsweise geprüft werden, wie viele VM’s keine Managed Disks nutzen. Dies ist mit einer der “Audit” Policies möglich. 

Custom Policies

Wie bereits erwähnt besteht eine weitreichende Möglichkeit, die Policies individuell anzupassen und zu erstellen. Hierfür werden JSON Dateien benutztIst hier, zur Veranschaulichung, die Erstellung der Policy über das Portal aufgezeigt, so ist dies auch mittels PowerShell und Azure CLI möglich. 

Hier noch der Link zur passenden Azure Dokumentation:  Azure Policy Dokumentation