Entwerfen von Workflows für Azure Policy-as-Code

  • Artikel

Je weiter Sie mit Cloud Governance fortschreiten, desto eher werden Sie von der manuellen Verwaltung jeder Richtlinienzuweisung im Azure-Portal oder über die verschiedenen SDKs zu etwas übergehen wollen, das auf Unternehmensebene leichter zu verwalten und zu wiederholen ist. Im Folgenden finden Sie die beiden vorherrschenden Ansätze für die Verwaltung von umfangreichen Systemen in der Cloud:

  • Infrastructure-as-Code: Bei diesem Ansatz werden alle Inhalte, die Ihre Umgebungen definieren – von Azure Resource Manager-Vorlagen (ARM-Vorlagen) über Azure Policy-Definitionen bis hin zu Azure Blueprints – als Quellcode behandelt.
  • DevOps: DevOps vereint Personen, Prozesse und Produkte, um hochwertige Continuous Delivery-Prozesse an Endbenutzer zu ermöglichen.

Azure Policy-as-Code ist eine Kombination dieser beiden Ansätze. Im Wesentlichen behalten Sie Ihre Richtliniendefinitionen in der Quellcodeverwaltung und testen und validieren Änderungen, wann immer diese eingeführt werden sollen. Dies sollte jedoch nicht der einzige Aspekt der Einbeziehung von Richtlinien in Infrastructure-as-Code oder DevOps sein.

Der Validierungsschritt sollte auch eine Komponente anderer Continuous Integration- oder Continuous Deployment-Workflows (CI/CD) sein, z. B. das Bereitstellen einer Anwendungsumgebung oder einer virtuellen Infrastruktur. Indem die Azure Policy-Validierung bereits frühzeitig im Erstellungs- und Bereitstellungsprozess erfolgt, können Anwendungs- und Betriebsteams ermitteln, ob sich ihre Änderungen wie erwartet verhalten, lange bevor es zu spät ist und die Teams die Anwendung in der Produktion bereitstellen möchten.

Definitionen und grundlegende Informationen

Bevor Sie sich mit den Details des Azure Policy as Code-Workflows befassen, sollten Sie einige grundlegende Konzepte verstehen, z. B. wie Sie Richtliniendefinitionen und Initiativendefinitionen erstellen und wie Sie Ausnahmen für Zuweisungen dieser Definitionen nutzen können:

Die Dateinamen entsprechen bestimmten Teilen von Richtlinien- oder Initiativendefinitionen und anderen Richtlinienressourcen:

Dateiformat Dateiinhalte
policy.json Die gesamte Richtliniendefinition
policyset.json Die gesamte Initiativendefinition
policy.parameters.json Der properties.parameters-Teil der Richtliniendefinition
policyset.parameters.json Der properties.parameters-Teil der Initiativendefinition
policy.rules.json Der properties.policyRule-Teil der Richtliniendefinition
policyset.definitions.json Der properties.policyDefinitions-Teil der Initiativendefinition
exemptionName.json Die Richtlinienausnahme, die auf eine bestimmte Ressource oder einen bestimmten Bereich ausgerichtet ist

Beispiele für diese Dateiformate sind im Azure Policy-GitHub-Repository verfügbar.

Übersicht über Workflow

Der empfohlene allgemeine Workflow für Azure Policy-as-Code sieht in etwa wie das folgende Diagramm aus:

Diagram showing Azure Policy as Code workflow boxes from Create to Test to Deploy.

Quellcodeverwaltung

Vorhandene Richtlinien- und Initiativendefinitionen können über verschiedene Wege exportiert werden, beispielsweise über PowerShell-, CLI- oder Azure Resource Graph-Abfragen (ARG). Die gewünschte Quellcodeverwaltungsumgebung zum Speichern dieser Definitionen kann eine von vielen Optionen sein, einschließlich GitHub oder Azure DevOps.

Erstellen und Aktualisieren von Richtliniendefinitionen

Die Richtliniendefinitionen werden mit JSON erstellt und in der Quellcodeverwaltung gespeichert. Jede Richtlinie verfügt über einen eigenen Satz Dateien, z. B. Parameter, Regeln und Umgebungsparameter, die im gleichen Ordner gespeichert werden sollten. Die folgende Struktur zeigt eine empfohlene Methode zum Speichern der Richtliniendefinitionen in der Quellcodeverwaltung.

.
|
|- policies/  ________________________ # Root folder for policy resources
|  |- policy1/  ______________________ # Subfolder for a policy
|     |- policy.json _________________ # Policy definition
|     |- policy.parameters.json ______ # Policy definition of parameters
|     |- policy.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- assign.<name2>.json _________ # Assignment 2 for this policy definition
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- policy2/  ______________________ # Subfolder for a policy
|     |- policy.json _________________ # Policy definition
|     |- policy.parameters.json ______ # Policy definition of parameters
|     |- policy.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

Wenn eine neue Richtlinie hinzugefügt oder eine vorhandene Richtlinie aktualisiert wird, sollte der Workflow die Richtliniendefinition in Azure automatisch aktualisieren. Das Testen der neuen oder aktualisierten Richtliniendefinition erfolgt in einem späteren Schritt.

Erstellen und Aktualisieren von Initiativendefinitionen

Initiativendefinitionen werden auch mithilfe von JSON-Dateien erstellt, die im selben Ordner wie Richtliniendefinitionen gespeichert werden sollten. Die Initiativendefinition erfordert eine bereits vorhandene Richtliniendefinition und kann daher erst erstellt oder aktualisiert werden, wenn die Quelle für die Richtlinie zunächst in der Quellcodeverwaltung und dann in Azure aktualisiert wurde. Die folgende Struktur zeigt eine empfohlene Methode zum Speichern der Initiativendefinitionen in der Quellcodeverwaltung.

.
|
|- initiatives/ ______________________ # Root folder for initiatives
|  |- init1/ _________________________ # Subfolder for an initiative
|     |- policyset.json ______________ # Initiative definition
|     |- policyset.definitions.json __ # Initiative list of policies
|     |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- assign.<name2>.json _________ # Assignment 2 for this policy initiative
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- init2/ _________________________ # Subfolder for an initiative
|     |- policyset.json ______________ # Initiative definition
|     |- policyset.definitions.json __ # Initiative list of policies
|     |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

Wie bei Richtliniendefinitionen sollte der Workflow die Initiativendefinition in Azure automatisch aktualisieren, wenn eine vorhandene Initiative hinzugefügt oder aktualisiert wird. Das Testen der neuen oder aktualisierten Initiativendefinition erfolgt in einem späteren Schritt.

Hinweis

Es wird empfohlen, einen zentralisierten Bereitstellungsmechanismus wie GitHub-Workflows oder Azure Pipelines für die Bereitstellung von Richtlinien zu verwenden. Dadurch wird sichergestellt, dass nur überprüfte Richtlinienressourcen in Ihrer Umgebung bereitgestellt werden und dass ein schrittweiser und zentraler Bereitstellungsmechanismus verwendet wird. Schreibberechtigungen für Richtlinienressourcen können auf die in der Bereitstellung verwendete Identität beschränkt werden.

Testen und Validieren der aktualisierten Definition

Sobald die Automatisierung Ihre neu erstellten oder aktualisierten Richtlinien- oder Initiativendefinitionen übernommen und das entsprechende Objekt in Azure aktualisiert hat, ist es an der Zeit, die Änderungen zu testen. Entweder die Richtlinie oder die zugehörige Initiative sollte Ressourcen in der Umgebung zugewiesen werden, die am weitesten von der Produktion entfernt ist. Diese Umgebung ist in der Regel die Entwicklungsumgebung: Dev.

Hinweis

In diesem Schritt führen wir Integrationstests der Richtliniendefinition in Ihrer Azure-Umgebung durch. Dies ist unabhängig von der Überprüfung der Funktionalität der Richtliniendefinition, die während des Erstellungsprozesses der Definition erfolgen sollte.

Die Zuweisung sollte den enforcementModedeaktiviert verwenden, damit Ressourcenerstellung und -aktualisierung nicht blockiert, aber vorhandene Ressourcen weiterhin auf Einhaltung der aktualisierten Richtliniendefinition überwacht werden. Auch im enforcementMode wird empfohlen, entweder eine Ressourcengruppe oder ein Abonnement, das speziell zur Validierung von Richtlinien dient, als Zuweisungsbereich zu verwenden.

Hinweis

Dieser Modus ist zwar hilfreich, darf aber gründliche Tests einer Richtliniendefinition unter verschiedenen Bedingungen nicht ersetzen. Die Richtliniendefinition sollte mit den REST-API-Aufrufen PUT und PATCH, konformen und nicht konformen Ressourcen sowie für Sonderfälle wie fehlenden Ressourceneigenschaften getestet werden.

Verwenden Sie nach der Bereitstellung der Zuweisung das Azure Policy SDK, die Azure Pipelines-Aufgabe: Sicherheits- und Compliancebewertung oder Azure Resource Graph (ARG)-Abfragen (siehe Beispiele), um Compliancedaten für die neue Zuweisung zu erhalten. Die Umgebung, die zum Testen der Richtlinien und Zuweisungen verwendet wird, sollte über Ressourcen mit unterschiedlichen Konformitätszuständen verfügen. Ebenso wie bei einem sorgfältigen Komponententest für Code sollten Sie überprüfen, ob die Ressourcen wie erwartet evaluiert werden und dass Sie keine falsch positiven oder falsch negativen Ergebnisse erhalten. Wenn Sie nur auf Ergebnisse testen, die Sie erwarten, kann die Richtlinie unerwartete und nicht identifizierte Auswirkungen nach sich ziehen. Weitere Informationen finden Sie unter Auswerten der Auswirkung einer neuen Azure Policy-Definition.

Ermöglichen von Korrekturtasks

Wenn die Validierung der Zuweisung den Erwartungen entspricht, besteht der nächste Schritt darin, mögliche Korrekturmaßnahmen zu überprüfen. Richtlinien, bei denen entweder deployIfNotExists oder modify verwendet wird, können einen zugeordneten Wartungstask ausgelöst haben, um Ressourcen aus einem nicht konformen Zustand in einen konformen Zustand zu bringen.

Zum Korrigieren von Ressourcen müssen Sie als Erstes der Richtlinienzuweisung die Rollenzuweisung erteilen, die in der Richtliniendefinition definiert ist. Diese Rollenzuweisung gewährt der Identität, die über die Richtlinienzuweisung verwaltet wird, ausreichende Rechte, um die erforderlichen Änderungen vorzunehmen, damit die Ressource konform wird.

Sobald die Richtlinienzuweisung über die entsprechenden Rechte verfügt, verwenden Sie das Policy SDK, um den Korrekturtask für einen Satz von Ressourcen auszulösen, die bekanntermaßen nicht konform sind. Für diese Korrekturtasks sollten drei Tests ausgeführt werden, bevor das Verfahren fortgesetzt wird:

  • Überprüfen, ob der Korrekturtask erfolgreich abgeschlossen wurde
  • Ausführen einer Richtlinienauswertung, um herauszufinden, ob die Richtlinienkonformitätsergebnisse erwartungsgemäß aktualisiert wurden
  • Ausführen eines Komponententests in der Umgebung direkt für die Ressourcen, um zu überprüfen, ob die Eigenschaften geändert wurden

Indem Sie sowohl die aktualisierten Ergebnisse der Richtlinienauswertung als auch die Umgebung direkt testen, erhalten Sie die Bestätigung, dass die Korrekturtasks alle Aspekte erwartungsgemäß geändert haben und dass die Konformitätsänderung in der Richtliniendefinition reflektiert wird.

Aktualisieren von erzwungenen Zuweisungen

Wenn alle Validierungsvorgänge abgeschlossen sind, aktualisieren Sie die Zuweisung so, dass sich der enforcementMode in aktiviert ändert. Es wird empfohlen, diese Änderung zunächst in derselben, weit von der Produktionsumgebung entfernten Umgebung durchzuführen. Überprüfen Sie, ob die gewünschten Effekte bei der Erstellung und Aktualisierung von Ressourcen angewendet werden. Sobald die erwartungsgemäße Funktionsweise dieser Umgebung überprüft wurde, kann die Änderung auf die nächste Umgebung und dann weiter ausgedehnt werden, bis die Richtlinie in Produktionsressourcen bereitgestellt ist.

Verarbeiten von integrierten Auswertungen

Im allgemeinen Workflow für Azure Policy-as-Code werden Richtlinien und Initiativen in großem Umfang für eine Umgebung entwickelt und bereitgestellt. Die Richtlinienauswertung sollte jedoch Teil des Bereitstellungsprozesses jedes Workflows sein, mit dem Ressourcen in Azure erstellt oder bereitgestellt werden. Hierzu gehören beispielsweise das Bereitstellen von Anwendung oder das Ausführen von ARM-Vorlagen zum Erstellen einer Infrastruktur.

In diesen Fällen sollte nach der Bereitstellung der Anwendung oder Infrastruktur in einem Testabonnement oder einer Testressourcengruppe eine Richtlinienauswertung für diesen Bereitstellungsumfang erfolgen, um die erfolgreiche Validierung aller vorhandenen Richtlinien und Initiativen zu überprüfen. Auch wenn Richtlinien und Initiativen in einer solchen Umgebung möglicherweise mit dem enforcementModedeaktiviert konfiguriert sind, ist es nützlich, bereits frühzeitig zu erfahren, ob eine Anwendungs- oder Infrastrukturbereitstellung gegen Richtlinien verstoßen könnte. Diese Richtlinienauswertung sollte daher als Schritt in solche Workflows eingebunden werden und Bereitstellungen, die nicht konforme Ressourcen erstellen, als fehlerhaft auswerten.

Überprüfung

Dieser Artikel beschreibt den allgemeinen Workflow für Azure Policy-as-Code und erläutert, in welchen Fällen eine Richtlinienauswertung Teil anderer Bereitstellungsworkflows sein sollte. Dieser Workflow kann in jeder Umgebung eingesetzt werden, die skriptbasierte Schritte und Automatisierung basierend auf Triggern unterstützt.

Nächste Schritte