Incus – Teil 16: Sicherheit in Incus – Container, AppArmor, Seccomp und Zugriffsrechte richtig absichern

Linux-Container und virtuelle Maschinen sicher betreiben: Sicherheitskonzepte, Benutzerrechte, Netzwerkschutz und Best Practices für Debian 13

Container gelten häufig als leichtgewichtige und effiziente Alternative zu klassischen virtuellen Maschinen. Sie starten schnell, benötigen vergleichsweise wenig Ressourcen und lassen sich flexibel verwalten. Doch gerade die gemeinsame Nutzung des Linux-Kernels stellt besondere Anforderungen an die Sicherheit.

Incus bringt bereits zahlreiche Sicherheitsmechanismen mit. Dazu gehören unprivilegierte Container, Benutzer-Namespaces, AppArmor, Seccomp, Ressourcenbegrenzungen und verschiedene Möglichkeiten zur Zugriffskontrolle.

Allerdings bedeutet eine sichere Standardkonfiguration nicht automatisch, dass jede Incus-Umgebung ausreichend geschützt ist. Besonders im produktiven Betrieb müssen Administratoren verstehen, wie die einzelnen Schutzmechanismen zusammenwirken und welche Konfigurationen zusätzliche Risiken verursachen können.

Im sechzehnten Teil unserer Incus-Serie beschäftigen wir uns ausführlich mit der Absicherung von Incus unter Debian 13. Wir betrachten die wichtigsten Sicherheitsfunktionen, zeigen praktische Konfigurationsbeispiele und erklären, worauf Unternehmen und Behörden besonders achten sollten.

Warum ist Sicherheit bei Incus besonders wichtig?

Incus unterstützt zwei unterschiedliche Virtualisierungstechnologien:

• Linux-Systemcontainer
• Virtuelle Maschinen auf Basis von QEMU/KVM

Beide Technologien verfolgen unterschiedliche Sicherheitskonzepte.

Ein Linux-Container verwendet den Kernel des Hostsystems. Prozesse innerhalb des Containers werden durch Linux-Namespaces, Kontrollgruppen und weitere Sicherheitsmechanismen voneinander und vom Host isoliert.

Eine virtuelle Maschine verfügt dagegen über einen eigenen Gastkernel und wird durch die Virtualisierungsschicht vom Host getrennt.

Das bedeutet nicht, dass virtuelle Maschinen grundsätzlich unangreifbar sind. Allerdings unterscheidet sich die Sicherheitsgrenze deutlich.

Container und virtuelle Maschinen im Vergleich

Linux-Container

Container eignen sich besonders für Linux-Anwendungen, Entwicklungsumgebungen, Webserver und zahlreiche Infrastrukturservices.

Vorteile sind der geringe Ressourcenbedarf, schnelle Startzeiten und eine hohe Integrationsfähigkeit.

Ein wesentliches Sicherheitsmerkmal ist die Isolation von Prozessen, Dateisystemen, Netzwerken und Benutzerkennungen.

Allerdings bleibt der gemeinsam verwendete Hostkernel eine zentrale Vertrauenskomponente.

Virtuelle Maschinen

Virtuelle Maschinen verfügen über einen eigenen Kernel und eine stärker getrennte Betriebssystemumgebung.

Sie sind deshalb häufig die bevorzugte Wahl für Workloads mit erhöhten Isolationsanforderungen, nicht vertrauenswürdige Betriebssysteme oder spezielle Kernelanforderungen.

Auch virtuelle Maschinen müssen jedoch gegen Schwachstellen in QEMU, KVM und den verwendeten virtuellen Geräten geschützt werden.

Praxisempfehlung: Für gewöhnliche Linux-Dienste sind unprivilegierte Incus-Container häufig eine gute Wahl. Bei besonders sensiblen oder nicht vertrauenswürdigen Workloads sollte geprüft werden, ob eine virtuelle Maschine die geeignetere Sicherheitsgrenze bietet.

Unprivilegierte Container: Die wichtigste Sicherheitsgrundlage

Eine der wichtigsten Sicherheitsfunktionen von Incus ist der Betrieb unprivilegierter Container.

Dabei wird verhindert, dass der Root-Benutzer innerhalb eines Containers automatisch über Root-Rechte auf dem Host verfügt.

Wie funktionieren unprivilegierte Container?

Unter Linux besitzt jeder Benutzer eine numerische Benutzerkennung, die sogenannte UID.

Der Benutzer root verwendet normalerweise die UID 0.

In einem unprivilegierten Container wird diese Kennung über einen User-Namespace auf einen anderen Benutzerkennungsbereich des Hosts abgebildet.

Ein vereinfachtes Beispiel:

Container                 Host
--------------------------------
root (UID 0)          →    UID 1000000
Benutzer (UID 1000)   →    UID 1001000

Die tatsächlichen Werte hängen von der Konfiguration des Systems ab.

Dadurch kann ein Prozess innerhalb des Containers zwar als Root auftreten, besitzt außerhalb seines Benutzer-Namespace aber nicht automatisch die entsprechenden Host-Rechte.

Das erschwert insbesondere Angriffe auf das Host-Dateisystem.

Prüfen, ob ein Container privilegiert ist

Die Konfiguration einer Instanz lässt sich mit folgendem Befehl überprüfen:

incus config show web01 --expanded

Interessant ist insbesondere die Einstellung:

security.privileged: "false"

Ist diese Einstellung nicht ausdrücklich gesetzt, gilt bei einem regulären Incus-Systemcontainer standardmäßig der unprivilegierte Betrieb.

Eine gezielte Abfrage ist ebenfalls möglich:

incus config get web01 security.privileged

Eine leere Ausgabe bedeutet, dass kein expliziter Wert auf Instanzebene gesetzt wurde. Zur Beurteilung der wirksamen Konfiguration sollten deshalb auch Profile berücksichtigt werden.

Privilegierte Container vermeiden

Ein privilegierter Container kann mit folgender Einstellung konfiguriert werden:

incus config set web01 security.privileged true

Dieser Befehl ist keine Sicherheitsempfehlung.

Er dient ausschließlich zur Veranschaulichung einer sicherheitskritischen Einstellung.

Privilegierte Container verzichten auf einen wesentlichen Teil der Isolation durch Benutzer-Namespaces. Dadurch steigt das Risiko, dass Prozesse innerhalb des Containers Auswirkungen auf den Host haben können.

Für produktive Umgebungen sollten privilegierte Container deshalb nur in begründeten Ausnahmefällen eingesetzt werden.

Besondere Vorsicht ist bei Containern geboten, die zusätzliche Kernel-Funktionen, Hardwarezugriffe oder verschachtelte Containertechnologien benötigen.

Benutzer-Namespaces und UID/GID-Mapping verstehen

Benutzer-Namespaces gehören zu den wichtigsten Sicherheitsmechanismen moderner Linux-Container.

Sie ermöglichen es, Benutzer- und Gruppenkennungen innerhalb eines Containers unabhängig von den Kennungen des Hostsystems darzustellen.

Warum ist das wichtig?

Ohne eine solche Zuordnung könnten Prozesse innerhalb eines Containers direkt mit privilegierten Host-Benutzerkennungen arbeiten.

Durch die Übersetzung der UID- und GID-Werte wird diese direkte Zuordnung verhindert.

Ein Prozess kann somit innerhalb seines Containers über administrative Rechte verfügen, ohne automatisch entsprechende Berechtigungen auf dem Host zu besitzen.

Benutzerkennungen innerhalb eines Containers prüfen

incus exec web01 -- id

Eine typische Ausgabe lautet:

uid=0(root) gid=0(root) groups=0(root)

Diese Ausgabe zeigt zunächst nur die Benutzerkennung innerhalb des Containers.

Um die tatsächliche Zuordnung auf dem Host zu untersuchen, kann beispielsweise die Prozess-ID des Containers ermittelt werden:

incus info web01

Anschließend lassen sich auf dem Host die UID- und GID-Zuordnungen des betreffenden Prozesses überprüfen:

sudo cat /proc/<PID>/uid_map
sudo cat /proc/<PID>/gid_map

<PID> muss dabei durch die tatsächliche Prozess-ID ersetzt werden.

Sicherheitsrelevante Besonderheiten

Besonders aufmerksam sollten Administratoren bei folgenden Funktionen sein:

• Benutzerdefinierte UID- und GID-Zuordnungen
• Direkte Einbindung von Host-Verzeichnissen
• Zugriff auf Hardwaregeräte
• Verschachtelte Container
• Privilegierte Instanzen

Solche Funktionen sind nicht grundsätzlich unsicher. Sie können jedoch die Isolation zwischen Host und Container beeinflussen.

Deshalb sollten zusätzliche Berechtigungen immer auf den konkreten Einsatzzweck begrenzt werden.

AppArmor: Prozesse und Dateisystemzugriffe einschränken

AppArmor ist ein Linux-Sicherheitsmodul, das Anwendungen anhand von Sicherheitsprofilen einschränken kann.

Es arbeitet nach dem Prinzip der Mandatory Access Control, kurz MAC.

Während klassische Linux-Dateiberechtigungen festlegen, welche Benutzer auf bestimmte Dateien zugreifen dürfen, kann AppArmor zusätzliche Einschränkungen für Prozesse definieren.

Damit lassen sich beispielsweise Zugriffe auf Dateisystembereiche, bestimmte Kernel-Schnittstellen und weitere Ressourcen begrenzen.

AppArmor unter Debian 13 prüfen

Zunächst sollte kontrolliert werden, ob AppArmor aktiv ist:

sudo systemctl status apparmor

Eine weitere Prüfung erfolgt mit:

sudo aa-status

Falls das Werkzeug nicht installiert ist:

sudo apt update
sudo apt install apparmor-utils

Anschließend:

sudo aa-status

Die Ausgabe informiert über geladene Profile und deren Betriebsmodus.

AppArmor und Incus

Incus kann AppArmor-Profile verwenden, um die Prozesse seiner Container zusätzlich einzuschränken.

Dabei werden Sicherheitsprofile auf Grundlage der jeweiligen Instanzkonfiguration erzeugt.

Diese Profile können unter anderem dazu beitragen, unzulässige Zugriffe auf Host-Ressourcen zu verhindern.

Wichtig ist allerdings, dass AppArmor auf dem Host aktiviert und vom verwendeten Kernel unterstützt wird.

Sicherheitsprofile nicht unnötig abschwächen

In bestimmten Situationen können Anwendungen innerhalb eines Containers mit AppArmor-Einschränkungen kollidieren.

Beispielsweise bei:

• Verschachtelten Containerumgebungen
• Speziellen Systemdiensten
• Direktem Hardwarezugriff
• Anwendungen mit ungewöhnlichen Kernel-Anforderungen

Eine mögliche, aber sicherheitskritische Einstellung ist:

incus config set web01 \
  raw.apparmor "..."

Über raw.apparmor können zusätzliche AppArmor-Regeln eingebracht werden.

Solche Eingriffe sollten ausschließlich durch erfahrene Administratoren erfolgen.

Insbesondere sollte nicht versucht werden, Sicherheitsprobleme pauschal durch das Abschalten von AppArmor zu lösen.

Besser ist es, zunächst die tatsächliche Ursache zu ermitteln und anschließend eine möglichst eng begrenzte Anpassung vorzunehmen.

AppArmor-Probleme analysieren

Relevante Meldungen können im Systemjournal gesucht werden:

sudo journalctl -k | grep -i apparmor

Alternativ:

sudo journalctl -k | grep -i denied

Diese Ausgaben können Hinweise auf blockierte Aktionen liefern.

Nicht jede verweigerte Aktion ist automatisch ein Fehler. Häufig handelt es sich um eine beabsichtigte Sicherheitsbeschränkung.

Seccomp: Gefährliche Systemaufrufe begrenzen

Neben AppArmor verwendet Incus weitere Sicherheitsmechanismen des Linux-Kernels.

Dazu gehört Seccomp, kurz für Secure Computing.

Seccomp ermöglicht es, Systemaufrufe von Prozessen zu filtern.

Was sind Systemaufrufe?

Anwendungen greifen nicht unmittelbar auf alle Funktionen des Linux-Kernels zu.

Stattdessen verwenden sie Systemaufrufe, sogenannte Syscalls.

Beispiele sind:

• Dateien öffnen
• Prozesse erstellen
• Speicher verwalten
• Netzwerkverbindungen aufbauen
• Bestimmte Kernel-Funktionen aufrufen

Nicht jede Anwendung benötigt sämtliche verfügbaren Systemaufrufe.

Seccomp kann daher bestimmte Aufrufe blockieren oder einschränken.

Warum ist das für Container wichtig?

Da Linux-Container denselben Kernel wie der Host verwenden, sind Kernel-Schnittstellen besonders sicherheitsrelevant.

Durch Seccomp lässt sich die erreichbare Angriffsfläche reduzieren.

Ein Angreifer, der eine Anwendung innerhalb eines Containers kompromittiert, kann dadurch nicht zwangsläufig sämtliche Kernel-Funktionen nutzen.

Seccomp ersetzt jedoch keine Kernel-Updates und schützt nicht gegen jede denkbare Schwachstelle.

Seccomp-Konfiguration in Incus

Incus verwendet eigene Sicherheitsmechanismen und unterstützt verschiedene Seccomp-bezogene Einstellungen.

Eine sicherheitsrelevante Option ist beispielsweise:

incus config get web01 \
  security.syscalls.intercept.mknod

Bestimmte Syscall-Interception-Funktionen können erforderlich sein, wenn Anwendungen besondere Containerfunktionen benötigen.

Sie sollten allerdings nicht ohne konkreten Bedarf aktiviert werden.

Auch andere Einstellungen zur Behandlung von Systemaufrufen müssen im Zusammenhang mit der jeweiligen Anwendung bewertet werden.

Best Practice

Für normale Web-, Datenbank- und Anwendungscontainer empfiehlt es sich, die vorgesehenen Incus-Sicherheitsmechanismen beizubehalten.

Zusätzliche Freigaben sollten nur erfolgen, wenn sie technisch erforderlich sind und ihre Auswirkungen verstanden wurden.

Linux Capabilities: Root-Rechte gezielt einschränken

Traditionell besitzt der Root-Benutzer unter Linux weitreichende Rechte.

Moderne Linux-Systeme unterteilen einen Teil dieser Rechte in sogenannte Capabilities.

Dazu gehören beispielsweise:

• CAP_NET_ADMIN für bestimmte Netzwerkadministrationsaufgaben
• CAP_SYS_ADMIN für zahlreiche administrative Kernel-Funktionen
• CAP_NET_BIND_SERVICE zum Binden privilegierter Netzwerkports
• CAP_SYS_TIME zum Verändern der Systemzeit

Container benötigen normalerweise nicht sämtliche verfügbaren Capabilities.

Deshalb kann Incus diese Rechte begrenzen.

Warum ist das wichtig?

Je mehr privilegierte Funktionen ein Container nutzen darf, desto größer ist seine potenzielle Angriffsfläche.

Besonders kritisch ist CAP_SYS_ADMIN, da diese Capability zahlreiche weitreichende Funktionen umfasst.

Ein Container sollte daher nur die tatsächlich benötigten Fähigkeiten erhalten.

Sicherheitsprinzip

Für Incus gilt:

So wenig Berechtigungen wie möglich, so viele wie erforderlich.

Das betrifft nicht nur Linux Capabilities, sondern auch Gerätezugriffe, Netzwerkberechtigungen und eingebundene Host-Verzeichnisse.

Host-Verzeichnisse sicher in Container einbinden

Incus ermöglicht es, Verzeichnisse des Hostsystems innerhalb eines Containers bereitzustellen.

Das ist praktisch, beispielsweise für gemeinsam genutzte Daten oder Anwendungsverzeichnisse.

Allerdings entstehen dadurch zusätzliche Sicherheitsrisiken.

Beispiel: Ein Verzeichnis einbinden

incus config device add web01 daten disk \
  source=/srv/webdaten \
  path=/var/www/daten

Damit wird das Host-Verzeichnis /srv/webdaten innerhalb des Containers bereitgestellt.

Problem: Schreibzugriff auf Host-Daten

Besitzt der Container Schreibrechte auf das eingebundene Verzeichnis, kann eine kompromittierte Anwendung möglicherweise Dateien verändern oder löschen.

Daher sollten Host-Verzeichnisse nur dann schreibbar eingebunden werden, wenn dies tatsächlich erforderlich ist.

Schreibgeschützte Einbindung

incus config device add web01 daten disk \
  source=/srv/webdaten \
  path=/var/www/daten \
  readonly=true

Damit wird das Verzeichnis innerhalb des Containers schreibgeschützt eingebunden.

Zusätzlich müssen die Linux-Dateiberechtigungen und UID-/GID-Zuordnungen korrekt konfiguriert sein.

Besonders sensible Host-Verzeichnisse wie /etc, /root, /var/lib/incus oder Bereiche mit administrativen Zugangsdaten sollten niemals leichtfertig in Container eingebunden werden.

Rechte und Benutzerverwaltung auf dem Incus-Host

Die Sicherheit einer Incus-Umgebung hängt wesentlich davon ab, wer den Incus-Daemon verwalten darf.

Ein Benutzer mit umfassenden Incus-Administrationsrechten kann Instanzen erstellen, konfigurieren, Geräte einbinden und weitere sicherheitskritische Aktionen durchführen.

Deshalb sind solche Berechtigungen besonders schützenswert.

Benutzergruppen überprüfen

getent group incus-admin

Je nach Installation und Konfiguration können weitere Incus-bezogene Gruppen vorhanden sein.

Auf unterstützten Installationen stellt die Gruppe incus-admin umfassende Verwaltungsrechte bereit.

Mitgliedschaften lassen sich beispielsweise folgendermaßen überprüfen:

groups benutzername

Benutzer zur Administratorengruppe hinzufügen

sudo usermod -aG incus-admin benutzername

Dieser Befehl sollte nur verwendet werden, wenn der betreffende Benutzer tatsächlich vollständige Incus-Administrationsrechte benötigt.

Die neue Gruppenmitgliedschaft wird normalerweise erst nach einer erneuten Anmeldung wirksam.

Warum sind Incus-Administrationsrechte kritisch?

Ein Administrator kann unter Umständen Container mit weitreichenden Geräte- und Dateisystemzugriffen konfigurieren.

Damit kann eine umfassende Incus-Berechtigung praktisch einer weitreichenden Kontrolle über den Host entsprechen.

Daher sollte der Zugriff auf die administrative Incus-Schnittstelle ähnlich streng behandelt werden wie Root-Zugriff.

Für normale Benutzer, Entwickler oder Projektverantwortliche sind eingeschränkte Rollen und geeignete Autorisierungsmechanismen vorzuziehen.

Rollenbasierte Zugriffskontrolle und Projekte

Incus unterstützt die Aufteilung einer Infrastruktur in Projekte.

Projekte ermöglichen die logische Trennung von Instanzen und weiteren Ressourcen.

Beispielsweise könnten folgende Projekte angelegt werden:

incus project create entwicklung
incus project create test
incus project create produktion

Anschließend kann ein Projekt ausgewählt werden:

incus project switch entwicklung

Neue Container werden dann im ausgewählten Projekt erstellt.

Projekte sind keine vollständige Sicherheitsgrenze

Wichtig ist die Unterscheidung zwischen organisatorischer Trennung und tatsächlicher Zugriffskontrolle.

Allein durch die Erstellung verschiedener Projekte wird noch keine vollständige Mandantentrennung erreicht.

Dazu müssen zusätzlich geeignete Berechtigungen, Ressourceneinschränkungen und Netzwerkregeln eingerichtet werden.

Je nach Incus-Version und Konfiguration können dafür unterschiedliche Autorisierungsmechanismen eingesetzt werden.

OpenFGA und rollenbasierte Berechtigungen

Für anspruchsvollere Umgebungen kann Incus mit externen Autorisierungssystemen wie OpenFGA integriert werden.

Damit lassen sich differenzierte Zugriffsmodelle umsetzen.

Beispielsweise könnte ein Benutzer ausschließlich Container innerhalb eines bestimmten Projekts verwalten dürfen.

Andere Benutzer erhalten lediglich lesenden Zugriff.

Solche Modelle sind besonders für Unternehmen, Hosting-Umgebungen und größere IT-Abteilungen interessant.

Die konkret verfügbaren Berechtigungen und deren Einrichtung hängen von der eingesetzten Incus-Version und dem konfigurierten Autorisierungsmodell ab.

Netzwerksicherheit in Incus

Container benötigen häufig Netzwerkzugriff.

Dabei entstehen ähnliche Sicherheitsrisiken wie bei klassischen Servern.

Ein kompromittierter Container könnte beispielsweise versuchen, andere Systeme innerhalb des Netzwerks anzugreifen.

Deshalb sollte die Netzwerkarchitektur nicht ausschließlich auf Erreichbarkeit und Komfort ausgerichtet sein.

Standardnetzwerk verstehen

Viele Incus-Installationen verwenden eine verwaltete Netzwerk-Bridge.

Ein typisches Netzwerk könnte folgendermaßen aussehen:

Internet
   |
Firewall
   |
Incus-Host
   |
incusbr0
   |
   +-- web01
   +-- web02
   +-- db01

Die Container können je nach Konfiguration untereinander kommunizieren und über NAT auf externe Netzwerke zugreifen.

Für einfache Testumgebungen ist dies praktisch.

Im produktiven Betrieb sollte allerdings geprüft werden, ob sämtliche Container tatsächlich uneingeschränkt miteinander kommunizieren müssen.

Separate Netzwerke erstellen

Ein zusätzliches internes Netzwerk kann beispielsweise folgendermaßen erstellt werden:

incus network create backend \
  ipv4.address=10.50.0.1/24 \
  ipv4.nat=false \
  ipv6.address=none

Dieses Netzwerk verwendet eine eigene IPv4-Adressierung und deaktiviert IPv4-NAT.

Wichtig: Das Deaktivieren von NAT bedeutet nicht automatisch, dass das Netzwerk vollständig isoliert ist. Routing, Firewall-Regeln und weitere Host-Netzwerkeinstellungen müssen ebenfalls berücksichtigt werden.

Container mit einem Netzwerk verbinden

incus config device add db01 eth1 nic \
  network=backend \
  name=eth1

Damit wird dem Container db01 eine zusätzliche Netzwerkschnittstelle zugewiesen.

Ein solches Konzept eignet sich beispielsweise zur Trennung von Frontend- und Backend-Diensten.

Incus-Netzwerke mit ACLs absichern

Incus unterstützt Netzwerk-ACLs, also Access Control Lists.

Damit können Kommunikationsbeziehungen innerhalb geeigneter verwalteter Netzwerke gezielt eingeschränkt werden.

Beispiel: Eine ACL erstellen

incus network acl create web-acl

Anschließend kann eine Regel definiert werden, die eingehende TCP-Verbindungen auf Port 443 erlaubt:

incus network acl rule add web-acl ingress \
  action=allow \
  protocol=tcp \
  destination_port=443

Eine zusätzliche Regel könnte andere eingehende Verbindungen blockieren:

incus network acl rule add web-acl ingress \
  action=drop

Die konkrete Wirksamkeit hängt von der Reihenfolge, den Regelprioritäten, der Netzwerkkonfiguration und der Zuordnung der ACL ab.

Die ACL muss anschließend dem vorgesehenen Netzwerk oder der betreffenden Netzwerkschnittstelle zugewiesen werden.

Warum ACLs sinnvoll sind

Mit Netzwerk-ACLs lassen sich beispielsweise folgende Sicherheitsanforderungen umsetzen:

• Webserver dürfen nur definierte Ports anbieten.
• Datenbankserver akzeptieren ausschließlich Verbindungen bestimmter Anwendungen.
• Verwaltungsdienste sind nur aus Administrationsnetzen erreichbar.
• Entwicklungsumgebungen dürfen nicht auf Produktionssysteme zugreifen.

Eine solche Segmentierung erschwert die seitliche Ausbreitung von Angriffen innerhalb einer Infrastruktur.

Firewall auf dem Incus-Host

Neben den Incus-eigenen Netzwerkfunktionen sollte auch der Host über eine geeignete Firewall-Konfiguration verfügen.

Unter Debian 13 können beispielsweise nftables oder darauf aufbauende Verwaltungswerkzeuge eingesetzt werden.

nftables prüfen

sudo systemctl status nftables

Die aktuellen Regeln können angezeigt werden mit:

sudo nft list ruleset

Bei Incus ist jedoch Vorsicht geboten.

Incus kann selbst Firewall- und NAT-Regeln für verwaltete Netzwerke erzeugen.

Manuelle Änderungen an nftables dürfen diese Regeln nicht unbeabsichtigt überschreiben oder blockieren.

Insbesondere das vollständige Ersetzen bestehender Firewall-Regelsätze kann dazu führen, dass Container ihre Netzwerkverbindung verlieren.

Empfehlung

Die Firewall-Konfiguration sollte zentral geplant werden.

Dabei sind mindestens folgende Kommunikationsbeziehungen zu berücksichtigen:

• Administrativer Zugriff auf den Host
• Incus-API-Zugriff
• Kommunikation zwischen Containern
• Zugriff auf Datenbank- und Backend-Dienste
• DNS und DHCP
• Clusterkommunikation
• Monitoring und Backup

Für produktive Umgebungen empfiehlt sich eine dokumentierte Netzwerksegmentierung mit klar definierten Kommunikationsfreigaben.

Incus REST API absichern

Die REST API ermöglicht eine weitreichende Verwaltung der Incus-Infrastruktur.

Sie sollte deshalb besonders sorgfältig abgesichert werden.

API-Zugriff prüfen

incus config get core.https_address

Ist keine HTTPS-Adresse konfiguriert, bedeutet dies normalerweise, dass die Incus-API nicht über einen entsprechenden TCP-Listener bereitgestellt wird.

Die lokale Unix-Socket-Schnittstelle kann dennoch verfügbar sein.

API nicht unnötig veröffentlichen

Für einen einzelnen Incus-Host, der ausschließlich lokal verwaltet wird, ist eine über das Netzwerk erreichbare API häufig nicht erforderlich.

Wird der Remote-Zugriff benötigt, sollte er auf vertrauenswürdige Administrationsnetze beschränkt werden.

Zusätzlich sind geeignete Authentifizierungs- und Autorisierungsmechanismen erforderlich.

Sicherheitsmaßnahmen

Empfehlenswert sind:

• TLS-gesicherte Verbindungen
• Restriktive Firewall-Regeln
• Vertrauenswürdige Client-Zertifikate oder geeignete andere Authentifizierungsverfahren
• Regelmäßige Überprüfung berechtigter Clients
• Sichere Aufbewahrung von Zugangsdaten
• Protokollierung administrativer Aktionen

Insbesondere dauerhaft gültige Zugangsdaten sollten regelmäßig überprüft und bei Bedarf widerrufen werden.

Ressourcenbegrenzungen als Sicherheitsmaßnahme

Sicherheit bedeutet nicht nur Schutz vor unberechtigtem Zugriff.

Auch die Verfügbarkeit der Infrastruktur muss berücksichtigt werden.

Ein fehlerhafter oder kompromittierter Container kann beispielsweise versuchen, sämtliche CPU-Ressourcen oder den verfügbaren Arbeitsspeicher zu beanspruchen.

Incus unterstützt verschiedene Ressourcenlimits.

CPU begrenzen

incus config set web01 limits.cpu 2

Arbeitsspeicher begrenzen

incus config set web01 limits.memory 2GiB

Prozessanzahl begrenzen

incus config set web01 limits.processes 512

Festplattenspeicher begrenzen

Für das Root-Dateisystem kann beispielsweise ein Größenlimit konfiguriert werden:

incus config device override web01 root \
  size=20GiB

Dieser Befehl setzt voraus, dass das Root-Gerät über ein Profil eingebunden ist und der verwendete Storage-Treiber entsprechende Größenlimits unterstützt.

Warum sind Ressourcenlimits wichtig?

Ohne Begrenzungen könnte ein einzelner Container unter Umständen die Stabilität anderer Instanzen beeinträchtigen.

Ressourcenlimits helfen daher bei der Absicherung gegen unbeabsichtigte Überlastungen und bestimmte Denial-of-Service-Szenarien.

Sie ersetzen allerdings kein vollständiges Monitoring und keine Kapazitätsplanung.

Sicherheitsupdates für Host und Container

Ein häufig unterschätzter Aspekt der Containersicherheit ist die regelmäßige Aktualisierung des Hostsystems.

Da Linux-Container den Kernel des Hosts gemeinsam verwenden, können Kernel-Schwachstellen Auswirkungen auf mehrere Container haben.

Debian-Host aktualisieren

sudo apt update
sudo apt upgrade

Nach sicherheitsrelevanten Kernel-Updates kann ein Neustart erforderlich sein.

Ob ein Neustart notwendig ist, sollte anhand der tatsächlich installierten Updates geprüft werden.

Container aktualisieren

Auch innerhalb der Container müssen Betriebssystem und Anwendungen aktuell gehalten werden.

Beispielsweise:

incus exec web01 -- apt update
incus exec web01 -- apt upgrade -y

Dieser Ansatz eignet sich für einfache Umgebungen.

In größeren Installationen sind zentrale Werkzeuge wie Ansible oder geeignete Patchmanagement-Systeme vorzuziehen.

Nicht nur den Host aktualisieren

Ein aktueller Hostkernel schützt nicht automatisch vor Schwachstellen in Anwendungen innerhalb der Container.

Webserver, Datenbanken, Laufzeitumgebungen und weitere Software müssen ebenfalls regelmäßig aktualisiert werden.

Daher sollte ein Patchmanagement sowohl Host- als auch Containerkomponenten berücksichtigen.

Logging und Sicherheitsüberwachung

Sicherheitsmaßnahmen sind nur dann dauerhaft wirksam, wenn ihr Zustand regelmäßig überprüft wird.

Incus stellt verschiedene Möglichkeiten zur Diagnose und Protokollierung bereit.

Incus-Dienstprotokolle anzeigen

sudo journalctl -u incus

Je nach Installationsart kann der relevante systemd-Dienst abweichen.

Instanzinformationen prüfen

incus info web01

Containerprotokolle anzeigen

incus info web01 --show-log

Diese Ausgabe kann insbesondere bei Startproblemen hilfreich sein.

Für die laufende Überwachung von Anwendungen sollten zusätzlich die Protokolle innerhalb der jeweiligen Container berücksichtigt werden.

Sicherheitsrelevante Ereignisse

Interessant sind insbesondere:

• Fehlgeschlagene Anmeldeversuche
• Ungewöhnliche administrative Aktionen
• Änderungen an Instanzkonfigurationen
• Neue privilegierte Container
• Unerwartete Gerätefreigaben
• Änderungen an Netzwerken
• Auffällige Ressourcenverbräuche
• AppArmor-Verweigerungen

In größeren Umgebungen sollten diese Informationen möglichst zentral ausgewertet werden.

Dafür kommen beispielsweise SIEM-Systeme, zentrale Syslog-Infrastrukturen oder Monitoring-Lösungen infrage.

Incus in Unternehmen und Behörden sicher betreiben

In Unternehmen und öffentlichen Verwaltungen gelten häufig höhere Anforderungen an Verfügbarkeit, Nachvollziehbarkeit und Zugriffsschutz.

Dabei reicht es nicht aus, einzelne Container technisch abzusichern.

Die gesamte Betriebsumgebung muss in ein Sicherheitskonzept eingebunden werden.

Administrationszugriffe

Administrative Zugriffe sollten möglichst über gesicherte Verwaltungsnetze erfolgen.

Persönliche Administrationskonten sind gemeinsam genutzten Konten vorzuziehen.

Zusätzlich sollten privilegierte Aktionen nachvollziehbar protokolliert werden.

Trennung von Umgebungen

Entwicklung, Test und Produktion sollten nicht nur organisatorisch, sondern entsprechend ihrem Schutzbedarf auch technisch getrennt werden.

Bei besonders sensiblen Anwendungen kann eine Trennung auf unterschiedlichen Incus-Hosts oder durch virtuelle Maschinen sinnvoll sein.

Backup und Wiederherstellung

Sicherheitskonzepte müssen auch den Wiederherstellungsfall berücksichtigen.

Dazu gehören regelmäßige Backups, geschützte Sicherungsziele und dokumentierte Wiederherstellungsverfahren.

Snapshots allein ersetzen keine unabhängigen Backups.

NIS-2 und BSI IT-Grundschutz

Incus kann im Rahmen eines Informationssicherheitsmanagementsystems betrieben werden.

Dabei sind insbesondere folgende Themen relevant:

• Risikomanagement
• Zugriffskontrolle
• Systemhärtung
• Patchmanagement
• Protokollierung
• Netzwerksicherheit
• Backup und Wiederherstellung
• Notfallmanagement
• Lieferanten- und Softwaremanagement

Die konkrete Umsetzung sollte sich an der Risikobewertung, dem Schutzbedarf und den jeweils anwendbaren gesetzlichen und organisatorischen Anforderungen orientieren.

Eine sichere Incus-Konfiguration allein begründet keine NIS-2-Konformität.

Praxis: Sicherheitscheck für einen Incus-Container

Zum Abschluss betrachten wir einige wichtige Prüfungen, die Administratoren regelmäßig durchführen können.

Instanzkonfiguration prüfen

incus config show web01 --expanded

Privilegierung prüfen

incus config get web01 security.privileged

Ressourcenlimits prüfen

incus config get web01 limits.cpu
incus config get web01 limits.memory

Geräte überprüfen

incus config device show web01 --expanded

Netzwerkzuordnung kontrollieren

incus list web01

AppArmor-Status prüfen

sudo aa-status

Host-Firewall kontrollieren

sudo nft list ruleset

API-Konfiguration prüfen

incus config get core.https_address

Diese Prüfungen liefern einen ersten Überblick.

Für einen vollständigen Sicherheitscheck müssen zusätzlich Benutzerberechtigungen, Netzwerkrichtlinien, Patchstände, Protokolle und Backup-Konfigurationen untersucht werden.

Best Practices für sichere Incus-Umgebungen

Für den produktiven Betrieb lassen sich einige grundlegende Empfehlungen ableiten.

Unprivilegierte Container bevorzugen

Privilegierte Container sollten nur bei nachgewiesenem technischem Bedarf eingesetzt werden.

AppArmor und Seccomp aktiviert lassen

Die vorhandenen Sicherheitsmechanismen sollten nicht ohne konkrete Begründung abgeschwächt werden.

Administrationsrechte begrenzen

Nur autorisierte Benutzer sollten vollständige Incus-Verwaltungsrechte erhalten.

Netzwerke segmentieren

Container sollten ausschließlich auf diejenigen Systeme und Dienste zugreifen können, die sie tatsächlich benötigen.

Ressourcenlimits setzen

CPU, RAM, Prozesse und Speicher sollten entsprechend dem jeweiligen Workload begrenzt werden.

Host und Container aktuell halten

Kernel, Incus, Betriebssystempakete und Anwendungen benötigen ein regelmäßiges Patchmanagement.

Sicherheitsereignisse überwachen

Logs, Konfigurationsänderungen und auffällige Ressourcenverbräuche sollten systematisch ausgewertet werden.

Wiederherstellung regelmäßig testen

Backups müssen nicht nur erstellt, sondern auch auf ihre Wiederherstellbarkeit geprüft werden.

Sicherheitskonfiguration dokumentieren

Insbesondere in Unternehmen und Behörden sollten sicherheitsrelevante Einstellungen nachvollziehbar dokumentiert und regelmäßig überprüft werden.

Fazit: Incus bietet starke Sicherheitsmechanismen – die Konfiguration entscheidet

Incus stellt zahlreiche Funktionen bereit, mit denen sich Linux-Container und virtuelle Maschinen sicher betreiben lassen.

Unprivilegierte Container, Benutzer-Namespaces, AppArmor, Seccomp und Ressourcenlimits bilden dabei wichtige technische Grundlagen.

Hinzu kommen Möglichkeiten zur Netzwerksegmentierung, Zugriffskontrolle und zentralen Administration.

Die größte Herausforderung liegt jedoch nicht in der Verfügbarkeit dieser Funktionen, sondern in ihrer konsequenten Anwendung.

Ein Container, der mit unnötigen Berechtigungen betrieben wird, sensible Host-Verzeichnisse beschreiben darf oder uneingeschränkten Netzwerkzugriff besitzt, kann trotz moderner Containertechnologie ein erhebliches Sicherheitsrisiko darstellen.

Für professionelle Umgebungen empfiehlt sich daher ein mehrschichtiges Sicherheitskonzept, das Host, Container, Netzwerk, Benutzer und Betriebsprozesse gleichermaßen berücksichtigt.

Die wichtigste Regel lautet: Ein Container sollte nur die Rechte, Ressourcen und Kommunikationsmöglichkeiten erhalten, die er für seine Aufgabe tatsächlich benötigt.

Wer dieses Prinzip konsequent umsetzt und mit regelmäßigen Updates, Monitoring und einer funktionierenden Backup-Strategie kombiniert, schafft eine solide Grundlage für den sicheren Betrieb von Incus.

Im nächsten Teil unserer Serie beschäftigen wir uns mit dem Monitoring von Incus. Dabei zeigen wir, wie sich Ressourcenverbrauch, Instanzzustände und Systemmetriken überwachen und mit Werkzeugen wie Prometheus und Grafana visualisieren lassen.