Eigenes Repository für PowerShell-Module
Alles auf Lager
Veröffentlicht in Ausgabe 02/2025 - PRAXIS
Die PowerShell hat sich als unverzichtbares Werkzeug für IT-Administratoren etabliert. Eine der besten Praktiken für das Erstellen von effizientem und wiederverwendbarem Code ist es, diesen in Funktionen zu abstrahieren. Die Funktionen wiederum lassen sich zu Modulen bündeln, um sie logisch zu organisieren und für alle Benutzer einfach zugänglich zu machen. Module erleichtern nicht nur die Wiederverwendbarkeit von Code, sondern tragen auch dazu bei, den Überblick über komplexe Skripte zu behalten und sicherzustellen, dass der Code gut strukturiert und wartbar bleibt. Schnell stellt sich die Frage, wie Sie diese Module am besten ablegen und zugänglich machen.
Sicherheit dank eigenem Repository
Die PowerShell Gallery, ein öffentliches Repository, bietet eine Plattform, auf der jeder seine Module bereitstellen kann. Dies hat den Vorteil, dass Module für eine breite Entwickler-Community verfügbar sind. Unternehmen möchten ihre selbst entwickelten Module jedoch oftmals nicht der Öffentlichkeit zugänglich machen. Dies kann aus verschiedenen Gründen notwendig sein, sei es aus Sicherheitsbedenken, weil sensible Informationen im Code enthalten sind, oder aufgrund von Unternehmensrichtlinien, die den Schutz interner Entwicklungen erfordern. Ein weiterer Aspekt ist der Schutz des geistigen Eigentums, da Unternehmen häufig nicht möchten, dass ihre proprietären Inhalte allgemein zugänglich sind.
Eine bewährte Lösung für dieses Problem ist das Bereitstellen eines eigenen internen Modul-Repositories. Dieses bietet die Möglichkeit, firmeneigene Module sicher zu speichern und sie nur autorisierten Mitarbeitern zugänglich zu machen. Der Code wird dabei zentral verwaltet, aktualisiert und kontrolliert verteilt.
Die PowerShell hat sich als unverzichtbares Werkzeug für IT-Administratoren etabliert. Eine der besten Praktiken für das Erstellen von effizientem und wiederverwendbarem Code ist es, diesen in Funktionen zu abstrahieren. Die Funktionen wiederum lassen sich zu Modulen bündeln, um sie logisch zu organisieren und für alle Benutzer einfach zugänglich zu machen. Module erleichtern nicht nur die Wiederverwendbarkeit von Code, sondern tragen auch dazu bei, den Überblick über komplexe Skripte zu behalten und sicherzustellen, dass der Code gut strukturiert und wartbar bleibt. Schnell stellt sich die Frage, wie Sie diese Module am besten ablegen und zugänglich machen.
Sicherheit dank eigenem Repository
Die PowerShell Gallery, ein öffentliches Repository, bietet eine Plattform, auf der jeder seine Module bereitstellen kann. Dies hat den Vorteil, dass Module für eine breite Entwickler-Community verfügbar sind. Unternehmen möchten ihre selbst entwickelten Module jedoch oftmals nicht der Öffentlichkeit zugänglich machen. Dies kann aus verschiedenen Gründen notwendig sein, sei es aus Sicherheitsbedenken, weil sensible Informationen im Code enthalten sind, oder aufgrund von Unternehmensrichtlinien, die den Schutz interner Entwicklungen erfordern. Ein weiterer Aspekt ist der Schutz des geistigen Eigentums, da Unternehmen häufig nicht möchten, dass ihre proprietären Inhalte allgemein zugänglich sind.
Eine bewährte Lösung für dieses Problem ist das Bereitstellen eines eigenen internen Modul-Repositories. Dieses bietet die Möglichkeit, firmeneigene Module sicher zu speichern und sie nur autorisierten Mitarbeitern zugänglich zu machen. Der Code wird dabei zentral verwaltet, aktualisiert und kontrolliert verteilt.
In diesem Artikel beleuchten wir, wie sich selbst geschriebene PowerShell-Funktionen zu Modulen bündeln und Mitarbeitern über ein zentrales Modul-Repository bereitstellen lassen. Zudem erläutern wir, wie Sie ein solches Repository erstellen, pflegen und in den Arbeitsablauf Ihrer IT-Abteilung integrieren. Wir betrachten die verschiedenen Schritte, die erforderlich sind, um ein internes Repository einzurichten, einschließlich der Auswahl der geeigneten Infrastruktur, der Konfiguration von Zugriffskontrollen und der Sicherstellung der kontinuierlichen Pflege des Repositories.
Vorteile der Modularisierung
PowerShell-Module sind Sammlungen verwandter Funktionen, Cmdlets, Variablen und anderer Ressourcen, die als Einheit organisiert und verteilt werden. Der Hauptzweck eines Moduls besteht darin, die Wiederverwendbarkeit von Code zu gewährleisten und die Struktur von PowerShell-Skripten zu verbessern. Durch die Modularisierung von Aufgaben aus spezifischen Anwendungsdomänen, wie beispielsweise VMware, Active Directory oder Azure, können Sie Funktionen wiederverwenden, ohne den Code erneut schreiben zu müssen. Weitere Vorteile von PowerShell-Modulen sind
- eine verbesserte Wartbarkeit und Lesbarkeit des Codes aufgrund der klaren Strukturierung,
- die Möglichkeit zur Versionierung, wodurch verschiedene Versionen eines Moduls nutzbar sind,
- die Unterstützung der Konsistenz in der gesamten Organisation durch wiederverwendbare Bausteine,
- eine Vereinfachung von Updates und Verbesserungen, da Änderungen nur im Modul nötig sind und
- die Verbesserung der Sicherheit durch die Möglichkeit, nur bestimmte Funktionen offenzulegen.
Grundaufbau eines Moduls
Ein PowerShell-Modul besteht aus mehreren Komponenten:
- PSD1-Manifestdatei: Enthält Metadaten über das Modul, wie die Version, den Autor und die Abhängigkeiten.
- PSM1-Moduldatei: Hier lagert der eigentliche PowerShell-Code.
- Verzeichnisstruktur: Module sind typischerweise in eigenen Ordnern organisiert, die mindestens die Manifest- und Moduldateien enthalten.
Beim Importieren eines Moduls sucht die PowerShell im Modulverzeichnis "($PSModulePath)" nach dem Modulnamen. Ist ein Manifest vorhanden, wird es überprüft und die Funktionen und Cmdlets des Moduls in die aktuelle Sitzung geladen. Ein importiertes Modul beansprucht Speicher, bis Sie es mit dem Befehl
Remove-Module entladen.Eigene Module entwickeln
Im Folgenden erstellen wir zwei einfache Funktionen, die wir als Beispiel in ein PowerShell-Modul packen:
# Funktion 1: Gibt "Hello, World!" aus
function Get-HelloWorld {
Write-Output "Hello, World!"
}
# Funktion 2: Gibt das aktuelle Datum aus
function Get-CurrentDate {
Write-Output (Get-Date)
}
Speichern Sie jedes Modul am besten in einem eigenen Verzeichnis, wobei der Name des Verzeichnisses mit dem Modulnamen übereinstimmen sollte:
New-Item -Path "$HOME\Documents\WindowsPowerShell\Modules\MyFirstModule" -ItemType Directory
Nun folgt das Erstellen der PSM1-Datei, in der die Funktionen lagern:
New-Item -Path "$HOME\Documents\WindowsPowerShell\Modules\MyFirstModule" -Name "MyFirstModule.psm1" -ItemType "File"
Danach geht es an das Erstellen einer Manifest-Datei (PSD1). Diese kommt zum Einsatz, um zusätzliche Informationen über das Modul zu speichern:
New-ModuleManifest -Path "$HOME\ Documents\WindowsPowerShell\Modules\MyFirstModule\MyFirstModule.psd1" -RootModule "MyFirstModule.psm1" -Author "Philip Lorenz" -Description "Ein einfaches Beispielmodul"
Module lassen sich dann in der PowerShell-Sitzung importieren und nutzen.
Funktion und Aufbau von Repositories
Ein Modul-Repository ist ein Speicherort, an dem Sie PowerShell-Module zentral ablegen und verwalten. Es dient dazu, die einfache Installation, Aktualisierung und Verwaltung von Modulen für Benutzer und Admins zu ermöglichen. Durch diese zentrale Art der Bereitstellung gewährleisten alle Beteiligten, stets die aktuellen Versionen zu verwenden, was die Sicherheit und Zuverlässigkeit der bereitgestellten Skripte erhöht. Zudem vereinfacht es die Zusammenarbeit innerhalb von Teams, da alle Mitglieder Zugriff auf dieselben Module haben.
Während öffentliche Repositories wie die PowerShell Gallery jedem zugänglich sind, können private Repositories firmenspezifische oder sicherheitsrelevante Module speichern. So haben Unternehmen die Möglichkeit, intern entwickelte Module zu hosten, die spezifische Anforderungen erfüllen oder sensible Daten enthalten. Dadurch bleibt die Kontrolle über die bereitgestellten Inhalte vollständig in den Händen der Organisation. Passwörter sind damit übrigens nicht gemeint. Diese sollten in einem Secret-Store lagern und nicht im Code.
Die PowerShell verwendet NuGet als Backend-Protokoll für Modul-Repositories. Dies ermöglicht die Verwaltung von Modulen ähnlich wie bei anderen Paketmanagern, etwa npm oder pip. NuGet bietet einen bewährten, zuverlässigen Ansatz für die Bereitstellung und Verwaltung von Softwarepaketen. Um ein Repository in der PowerShell zu verwenden, müssen Sie es zuerst registrieren. Dies erfolgt in der Regel durch den Befehl
Register-PSRepository, der das Softwareverzeichnis in der PowerShell-Umgebung bekannt macht und damit den Zugriff auf die Module ermöglicht:Register-PSRepository -Name "MeinRepository" -SourceLocation "https://<meinrepo.example.com>/ nuget" -InstallationPolicy Trusted
Module lassen sich anschließend aus dem Repository installieren und verwalten mit dem Befehl
Install-Module -Name "ModulName" -Repository "MeinRepository"
Update-Module -Name "ModulName"
Sonatype Nexus
Sonatype Nexus [1] ist eine umfassende Open-Source-Software für die Verwaltung verschiedenster Artefakte, darunter auch PowerShell-Module. Die Plattform ermöglicht nicht nur das Bereitstellen und Speichern von Modulen, sondern dient auch als Proxy für externe Quellen wie die PowerShell Gallery. Dadurch verwalten Teams PowerShell-Module zentral und stellen sicher, dass nur überprüfte Versionen von Abhängigkeiten zum Einsatz kommen.
Nexus unterstützt eine Vielzahl von Repository-Typen, was es Unternehmen erleichtert, alle wichtigen Artefakte in einer zentralen Umgebung zu speichern und zu organisieren. Als Proxy-Server ermöglicht es die effiziente Nutzung externer Bibliotheken, indem es Inhalte zwischenspeichert und mehrfach nutzbar macht. Die Folge sind unter anderem reduzierte Downloadzeiten. Zusätzlich können Sie strenge Richtlinien für den Zugriff und die Nutzung von PowerShell-Modulen festlegen, was die Sicherheit und die Nachvollziehbarkeit in Entwicklungsprozessen erhöht. Installieren lässt sich Nexus über Chocolatey mittels
choco install nexus-repository
Eine Installation in Docker (Compose) ist ebenfalls möglich. Dazu müssen Sie folgenden Inhalt in der Datei "docker-compose.yaml" ablegen:
services:
nexus:
image: sonatype/nexus3
volumes:
- "nexus-data:/nexus-data"
ports:
- "8081:8081"
volumes:
nexus-data: {}
Anschließend starten Sie den Container über
docker-compose up.Module in Nexus veröffentlichen
Für das Veröffentlichen von PowerShell-Modulen in Sonatype Nexus sind zunächst einige Schritte notwendig, um ein Repository einzurichten und die notwendigen Konfigurationen vorzunehmen. Der erste Schritt besteht darin, ein neues Repository in Nexus zu erstellen. Navigieren Sie in der Nexus-WebUI zu den Einstellungen und wählen Sie "Create Repository". Danach geben Sie einen Namen für das Repository ein und wählen die Option "nuget (hosted)" aus. Anschließend legen Sie das Repository an.
Bevor Sie ein PowerShell-Modul veröffentlichen, stellen Sie sicher, dass der "NuGet API-Key Realm" aktiviert ist. Dies ist notwendig, damit Nexus API-Schlüssel für die Authentifizierung generieren kann. Diesen Schritt führen Sie unter den "Realms" in der Konfiguration durch. Nachdem Sie den Realm aktiviert haben, generieren Sie einen API-Schlüssel, um später Module anbieten zu können. Dies erfolgt ebenfalls in der Nexus-Weboberfläche. Nach dem Erstellen des Repositories in Nexus und dem Generieren des API-Schlüssels registrieren Sie das Repository in der PowerShell. Verwenden Sie hierzu den folgenden Befehl, wobei Sie den Repository-Namen und die URL anpassen:
Register-PSRepository -Name <Name des Repos in der PowerShell> -SourceLocation http://localhost:8081/repository/ <Name des Repos in Nexus>/ -PublishLocation http://localhost:8081/repository/<Name des Repos in Nexus>/ -PackageManagementProvider nuget -InstallationPolicy Trusted
Dieser Befehl fügt das Nexus-Repository als PowerShell-Repository hinzu, sodass Sie darüber Module veröffentlichen und installieren können. Um das Modul in Nexus zu veröffentlichen, verwenden Sie den Befehl
Publish-Module. Dabei geben Sie den zuvor generierten API-Schlüssel an:Publish-Module -Name ./MyFirstModule.psd1 -Repository <Name des Repos in der PowerShell> -Verbose -NuGetApiKey "<API-Schlüssel>"
Das Kommando veröffentlicht das Modul "MyFirstModule" im Nexus-Repository. Anschließend können Sie mit dem Befehl
Find-Module die verfügbaren Module im Repository auflisten:Find-Module -Repository <Name des Repos in der PowerShell>
Um nun das veröffentlichte Modul zu installieren, verwenden Sie das Cmdlet
Install-Module. Hier ein Beispiel:Install-Module -Name MyFirstModule -Repository <Name des Repos in der PowerShell> -Force
Der Parameter "-Force" stellt sicher, dass das Modul bei Bedarf aktualisiert wird. Um eine neue Version zu veröffentlichen, müssen Sie die Modulversion in der Datei "MyFirstModule.psd1" aktualisieren. Anschließend lässt sich das Modul erneut mit dem bereits genannten Publish-Module-Befehl veröffentlichen. Nexus erkennt das Update automatisch und ordnet die neue Version korrekt ein. Über die Weboberfläche von Nexus sehen Sie die verschiedenen Versionen des Moduls unter dem Menüpunkt "Browse".
Best Practices für Module
Die technische Implementierung eines Modul-Repositories ist lediglich der erste Schritt. Ebenso wichtig ist es, organisatorische Maßnahmen zu etablieren, um den Betrieb langfristig produktiv zu gestalten. Neben internen Modulen benötigen Admins häufig auch Zugang zu Modulen Dritter, die von der PowerShell Gallery stammen. Sonatype Nexus bietet die Möglichkeit, Proxy-Repositories zu verwenden, sodass externe Module erst nach einer Prüfung über das interne Repository zur Verfügung stehen.
In der Praxis könnte eine solche Prüfung beispielsweise eine Sicherheitsbewertung des Codes beinhalten, den Check auf bekannte Schwachstellen sowie das Testen in einer isolierten Umgebung, um potenzielle Risiken zu minimieren. Erst nach erfolgreichem Abschluss dieser Prüfungen sind die Module zur Nutzung freigegeben.
Definieren Sie klare Prozesse für das Bereitstellen und Aktualisieren von internen Modulen: Wer darf Module veröffentlichen und welche Standards müssen sie erfüllen? Ein bewährtes Vorgehen besteht darin, dass alle Funktionen eines Moduls mit einem ausführlichen Hilfetext versehen sind. Zusätzlich sollten Sie sich folgende Fragen stellen:
- Wie lassen sich Freigabeprozesse möglichst effizient gestalten?
- Wie stellen Sie Rollbacks im Falle fehlerhafter Module sicher?
- Welche automatisierten Tests sollen stattfinden, um die Qualität der Module zu gewährleisten?
Es bietet sich an, die Prozesse zur Veröffentlichung und Prüfung von Modulen im Sinne von DevOps-Pipelines zu implementieren, damit diese nahtlos und automatisiert ablaufen. Automatisierte Tests, beispielsweise mittels Pester, sind ein wichtiger Bestandteil, um die Qualität der Module sicherzustellen.
Standardisierung der Repository-Nutzung
Damit ein internes Repository für alle PowerShell-Nutzer zugänglich ist, gibt es mehrere Ansätze, es auf allen Systemen verfügbar zu machen. Ein möglicher Befehl hierfür wäre:
if (!(Get-PSRepository <Repo-Name> -erroraction SilentlyContinue)){
Register-PSRepository <Repo-Name>
}
Dieser Befehl ist auf unterschiedliche Weise auf allen Systemen ausführbar:
- Über PowerShell Remoting können Sie diesen Befehl zentral starten, um sicherzustellen, dass das Repository auf allen relevanten Systemen registriert ist.
- Alternativ lässt sich das Repository bereits im Base-Image der Systeme hinterlegen, sodass es direkt nach der Installation verfügbar ist.
- In einer Windows-Domänenumgebung bietet sich eine Gruppenrichtlinie an, die ein Startskript ausführt, das das Repository registriert.
Fazit
Durch das Bündeln von Funktionen in Modulen und das Bereitstellen über ein zentrales Repository verbessern Unternehmen ihre skriptbasierten Automatisierungsprozesse. Der Einsatz von Technologien wie NuGet und Plattformen wie Sonatype Nexus sorgt dabei für eine sichere und effiziente Verwaltung von PowerShell-Modulen. Damit stehen Teams geprüfte und freigegebene Code-Module zur Verfügung, was die Sicherheit und Qualität der Skripte erhöht. Mit klar definierten Prozessen, wie Sicherheitsprüfungen externer Module und standardisierten Freigabeabläufen, lässt sich die Nutzung von Modul-Repositories innerhalb der Firma weiter konsolidieren und absichern.
(dr)
Link-Codes
[1] Sonatype Nexus: https://www.sonatype.com/products/sonatype-nexus-oss-download