Kubernetes DISA STIG

Konfigurieren Sie ein Kubernetes-System, um DISA STIG konform zu sein.

Basierend auf Kubernetes DISA STIG Version 1, Rel 8, veröffentlicht am 26. Januar 2023

Suchen Sie Unterstützung?

Lockdown Enterprise

Ansible Unterstützung

Community

Treten Sie unserem Discord Server bei, um Fragen zu stellen, Funktionen zu diskutieren oder einfach mit anderen Ansible-Lockdown-Benutzern zu plaudern.

Vorsicht(en)

Diese Rolle wird Änderungen am System vornehmen, die unbeabsichtigte Folgen haben können. Dies ist kein Auditing-Tool, sondern ein Remediation-Tool, das nach einer durchgeführten Prüfung verwendet werden soll.

Der Prüfmodus wird nicht unterstützt! Die Rolle wird im Prüfmodus ohne Fehler abgeschlossen, aber sie wird nicht unterstützt und sollte mit Vorsicht verwendet werden.

Diese Rolle wurde gegen eine saubere Installation von Kubernetes entwickelt. Wenn Sie sie auf einem bestehenden System implementieren, überprüfen Sie diese Rolle auf notwendige standortspezifische Änderungen.

Um die Release-Version zu verwenden, weisen Sie auf den Haupt-Branch und die relevante Veröffentlichung für den STIG-Standard, mit dem Sie arbeiten möchten, hin.

Angleichung eines Sicherheitsniveaus für STIG

Es ist möglich, nur Kontrollen auszuführen, die auf einem bestimmten Sicherheitsniveau für STIG basieren. Dies wird mit Tags verwaltet:

• CAT1
• CAT2
• CAT3

Die Kontrolle, die in den Standardwerten der Hauptdatei gefunden wird, muss ebenfalls auf "wahr" gesetzt werden, damit die Kontrollen beim Start des Playbooks ausgeführt werden können.

Kommen von einer früheren Veröffentlichung

STIG-Veröffentlichungen enthalten immer Änderungen. Es wird dringend empfohlen, die neuen Referenzen und verfügbaren Variablen zu überprüfen. Dies hat sich seit der ursprünglichen Veröffentlichung von ansible-lockdown erheblich geändert. Dies ist jetzt kompatibel mit Python3, wenn es als Standard-Interpreter gefunden wird. Dies hat auch Vorbedingungen, die das System entsprechend konfigurieren.

Weitere Details sind im Changelog zu finden.

Auditing (neu)

Derzeit hat diese Veröffentlichung kein Auditing-Tool.

Dokumentation

• Dokumente lesen
• Erste Schritte
• Rollen anpassen
• Pro-Host-Konfiguration
• Das Beste aus der Rolle herausholen

Anforderungen

Allgemein:

• Grundkenntnisse in Ansible. Hier sind einige Links zur Ansible-Dokumentation, die Ihnen helfen, sich einzuarbeiten, wenn Sie mit Ansible nicht vertraut sind:

  • Hauptseite der Ansible-Dokumentation
  • Ansible Erste Schritte
  • Tower-Benutzerhandbuch
  • Ansible Community Info

• Funktionierendes Ansible- und/oder Tower-Setup, konfiguriert und ausgeführt. Dies umfasst alle Basis-Konfigurationen von Ansible/Tower, erforderliche Pakete und die eingerichtete Infrastruktur.

• Bitte lesen Sie die Aufgaben in dieser Rolle durch, um zu verstehen, was jede Kontrolle bewirkt. Einige Aufgaben sind disruptiv und können unbeabsichtigte Konsequenzen in einem Live-Produktionssystem haben. Machen Sie sich auch mit den Variablen in der defaults/main.yml-Datei vertraut.

Technische Abhängigkeiten:

• Kubernetes 1.16.7 oder höher - Andere Versionen werden nicht unterstützt.
• Betrieb von Ansible/Tower-Setup (diese Rolle wurde gegen Ansible-Version 2.9.1 und neuer getestet)
• Python3-Umgebung für den Ansible-Betrieb
• python-def (sollte in RHEL/CentOS 7 enthalten sein) - Die erste Aufgabe richtet die Voraussetzungen (Tag Preconditions) für Python3 und Python2 (wo erforderlich) ein
  • libselinux-python
  • python3-rpm (Paket, das von py3 zur Verwendung mit rpm-Paketen verwendet wird)

Rollenvariablen

Diese Rolle ist so gestaltet, dass der Endbenutzer die Aufgaben nicht selbst bearbeiten muss. Alle Anpassungen sollten über die defaults/main.yml-Datei oder mit zusätzlichen Variablen innerhalb des Projekts, des Jobs, des Workflows usw. erfolgen.

Tags

Es gibt viele Tags, die für eine präzisere Kontrolle verwendet werden können. Jede Kontrolle hat ihren eigenen Satz von Tags, die das Level, ob es gewertet wurde oder nicht, auf welches Betriebssystem-Element es sich bezieht, ob es ein Patch oder ein Audit ist, und die Regelnummer kennzeichnen.

Unten ist ein Beispiel des Tag-Abschnitts aus einer Kontrolle innerhalb dieser Rolle. Wenn Sie in diesem Beispiel Ihre Ausführung so einstellen, dass alle Kontrollen mit dem Tag "kernel" übersprungen werden, wird diese Aufgabe übersprungen. Umgekehrt ist auch möglich, dass Sie nur Kontrollen ausführen, die mit "kernel" getaggt sind.

tags:
      - CNTR-K8-001620
      - CAT1
      - CCI-001084
      - SRG-APP-000233-CTR-000585
      - SV-242434r864009_rule
      - V-242434
      - kubelet
      - kernel

Community-Beitrag

Wir ermutigen Sie (die Community), zu dieser Rolle beizutragen. Bitte lesen Sie die folgenden Regeln.

• Ihre Arbeit erfolgt in Ihrem eigenen individuellen Branch. Stellen Sie sicher, dass alle Commits, die Sie zusammenführen möchten, signiert und GPG-signiert sind.
• Alle Community-Pull-Anfragen werden in den Entwicklungsbranch integriert.
• Pull-Requests in den Entwicklungsbranch bestätigen, dass Ihre Commits eine GPG-Signatur, eine Signatur und einen funktionalen Test haben, bevor sie genehmigt werden.
• Sobald Ihre Änderungen zusammengeführt wurden und eine detailliertere Überprüfung abgeschlossen ist, wird ein autorisiertes Mitglied Ihre Änderungen in den Hauptbranch für eine neue Veröffentlichung zusammenführen.

Pipeline-Test

verwendet:

• ansible-core 2.12
• Ansible-Collections - zieht die neueste Version basierend auf der Anforderungen-Datei
• führt das Audit unter Verwendung des Entwicklungs-Branchs aus
• Dies ist ein automatisierter Test, der bei Pull-Anfragen in den Entwicklungsbranch erfolgt