estenrye.cis_ubuntu_2004

Ansible-Rolle Ansible-Qualitätsbewertung GitHub-Tag (neueste SemVer) GitHub-Repo-Größe

Ansible-Rolle: cis_ubuntu_2004 :computer:

Ansible-Rolle zur Anwendung des CIS-Benchmarks für Ubuntu Linux 20.04 LTS.

Aktuell unterstützte und verfügbare Versionen sind:

CIS-Benchmark für Ubuntu Linux 20.04 LTS v1.1.0
CIS-Benchmark für Ubuntu Linux 20.04 LTS v1.0.0

Versionierung

Die folgende Tabelle beschreibt die verfügbaren Versionen der Rolle auf Ansible Galaxy und GitHub Releases in Bezug auf den entsprechenden CIS-Benchmark für Ubuntu Linux 20.04 LTS.

CIS Ubuntu 20.04 Benchmark-Version	Ansible Galaxy-Version	Repository-Tag-Version
1.0.0	1.0.0, 1.0.1, 1.0.2	1.0.0, 1.0.1, 1.0.2
1.1.0	2.0.0, 2.0.1, 2.1.0, 3.0.0, 3.1.0	2.0.0, 2.0.1, 2.1.0, 3.0.0, 3.1.0

1. Installations-/Download-Anweisungen:

Diese Rolle ist auf Ansible Galaxy verfügbar. Es gibt mehrere Methoden, um die Rolle cis_ubuntu_2004 in Ihrem Ansible-Controller-Knoten entweder von Ansible Galaxy oder direkt aus dem Repository zu installieren/herunterzuladen.

Ohne requirements.yml-Datei:

Neueste (Standard-)verfügbare Tag-Version installieren/herunterladen:
```
ansible-galaxy install darkwizard242.cis_ubuntu_2004
```
Bestimmte verfügbare Tag-Version installieren/herunterladen (mit 3.1.0 als Beispiel):
```
ansible-galaxy install darkwizard242.cis_ubuntu_2004,3.1.0
```
Bestimmte verfügbare Branch-Version aus dem Repository installieren/herunterladen (unter Verwendung des master-Branches als Beispiel, master wird immer mit der neuesten verfügbaren Version des CIS Ubuntu 20.04 Benchmark übereinstimmen):
```
ansible-galaxy install darkwizard242.cis_ubuntu_2004,master
```
Bestimmte verfügbare Branch-Version aus dem Repository installieren/herunterladen (unter Verwendung des feature/cis_version_1.1.0-Branches als Beispiel, der mit den neuesten Updates für CIS Ubuntu 20.04 Benchmark Version v1.1.0 übereinstimmt):
```
ansible-galaxy install darkwizard242.cis_ubuntu_2004,feature/cis_version_1.1.0
```
Bestimmte verfügbare Branch-Version aus dem Repository installieren/herunterladen (unter Verwendung des feature/cis_version_1.0.0-Branches als Beispiel, der mit den neuesten Updates für CIS Ubuntu 20.04 Benchmark Version v1.0.0 übereinstimmt):
```
ansible-galaxy install darkwizard242.cis_ubuntu_2004,feature/cis_version_1.0.0
```

Mit einer requirements.yml-Datei:

Fügen Sie die Rolle zu einer bestehenden requirements.yml-Datei zusammen mit Ihren anderen Rollen hinzu oder erstellen Sie eine neue, um cis_ubuntu_2004 zu installieren.

Neueste Version direkt von Ansible Galaxy.
```
- name: darkwizard242.cis_ubuntu_2004
```

Bestimmte Version direkt von Ansible Galaxy.

- name: darkwizard242.cis_ubuntu_2004
  version: 3.1.0

Bestimmter Branch aus dem Repository.

- name: cis_ubuntu_2004
  src: https://github.com/darkwizard242/cis_ubuntu_2004
  version: master

Installation/Download nach dem Hinzufügen zur requirements.yml:

ansible-galaxy install -r requirements.yml

HINWEIS: Die Installation einer Rolle wie oben beschrieben lädt nur die Rolle herunter, damit sie in Ihren Ansible-Playbooks verfügbar ist. Weitere Informationen zu den Anweisungen zur Installation/Herunterladen von Rollen finden Sie hier.

2. Einige Überlegungen:

Benchmarks zu Festplattenpartitionierung und deren Einbaupunkten aus Abschnitt 1 werden in dieser Rolle nicht angewendet. Der Grund ist einfach, dass die Systemarchitektur und die Festplattenanordnung jedes Einzelnen/Jeder Organisation voraussichtlich variieren werden. Ich empfehle, diese selbst anzuwenden. Folgende Benchmarks sind betroffen:

1.1.10 Sicherstellen, dass eine separate Partition für /var existiert (Automatisiert)
1.1.11 Sicherstellen, dass eine separate Partition für /var/tmp existiert (Automatisiert)
1.1.12 Sicherstellen, dass die Partition /var/tmp die Option nodev enthält (Automatisiert)
1.1.13 Sicherstellen, dass die Partition /var/tmp die Option nosuid enthält (Automatisiert)
1.1.14 Sicherstellen, dass die Partition /var/tmp die Option noexec enthält (Automatisiert)
1.1.15 Sicherstellen, dass eine separate Partition für /var/log existiert (Automatisiert)
1.1.16 Sicherstellen, dass eine separate Partition für /var/log/audit existiert (Automatisiert)
1.1.17 Sicherstellen, dass eine separate Partition für /home existiert (Automatisiert)
1.1.18 Sicherstellen, dass die Partition /home die Option nodev enthält (Automatisiert)
1.1.19 Sicherstellen, dass die Option nodev auf Partitionen für wechselbare Medien gesetzt ist (Manuell)
1.1.20 Sicherstellen, dass die Option nosuid auf Partitionen für wechselbare Medien gesetzt ist (Manuell)
1.1.21 Sicherstellen, dass die Option noexec auf Partitionen für wechselbare Medien gesetzt ist (Manuell)

Folgende Benchmarks aus Abschnitt 4 wurden ebenfalls nicht umgesetzt:

4.2.1.5 Sicherstellen, dass rsyslog so konfiguriert ist, dass Protokolle an einen Remote-Protokoll-Host gesendet werden (Automatisiert)
4.2.1.6 Sicherstellen, dass Remote-rsyslog-Nachrichten nur auf bestimmten Protokoll-Hosts akzeptiert werden. (Manuell)
4.3 Sicherstellen, dass logrotate konfiguriert ist (Manuell)

3. Anforderungen

Keine.

4. Rollenvariablen

Die standardmäßigen Variablen der Rolle, die in den Rollentasks verwendet werden, befinden sich in defaults/main/.

defaults/main/main.yml enthält Variablen, die sich auf die gesamten CIS-Abschnitte beziehen, wie die folgenden und die Systemvariablen, die in der Wichtigen Variablen Sektion erwähnt sind:

ubuntu_2004_cis_section1: true
ubuntu_2004_cis_section2: true
ubuntu_2004_cis_section3: true
ubuntu_2004_cis_section4: true
ubuntu_2004_cis_section5: true
ubuntu_2004_cis_section6: true

Der Zweck der oben genannten Variablen besteht darin, anzuzeigen, dass alle Aufgaben, die sich auf diese Abschnitte beziehen, durch die Rolle cis_ubuntu_2004 angewendet werden sollten.

Die Variablen für jeden Abschnitt befinden sich in ihren eigenen Dateien.

Variablen für Abschnitt 1 befinden sich in defaults/main/section_01.yml
Variablen für Abschnitt 2 befinden sich in defaults/main/section_02.yml
Variablen für Abschnitt 3 befinden sich in defaults/main/section_03.yml
Variablen für Abschnitt 4 befinden sich in defaults/main/section_04.yml
Variablen für Abschnitt 5 befinden sich in defaults/main/section_05.yml
Variablen für Abschnitt 6 befinden sich in defaults/main/section_06.yml

Standardwerte für alles in der Rolle cis_ubuntu_2004 können überschrieben werden, indem sie in ein Playbook oder durch jede andere Variable-Vorrangmethode übergeben werden.

Wichtige Variablen

Die CIS-Ubuntu 20.04-Härtegrad-Benchmarks erfordern das Löschen vieler Dienste, die ausgenutzt werden können, bekannte Schwachstellen haben oder eine Angriffsfläche bilden oder deaktiviert werden sollten, wenn sie nicht benötigt werden. Laut dem Benchmark werden standardmäßig alle diese Dienste gelöscht, und der Wert ihrer Variablen wurde auf false gesetzt. Wenn Sie jedoch aus irgendeinem Grund die Verwendung dieser Dienste weiterhin benötigen, ändern Sie deren Werte auf true, damit die Aufgaben der Rolle beim Anwenden des Playbooks zum Löschen dieser Dienste übersprungen werden können.

Neben den oben erwähnten Erklärungen für einige Variablen gibt es auch andere Variablen, die festlegen, ob ein bestimmter Dienst im System gewünscht ist oder nicht (z. B. SSH-Daemon), Parameter für die Konfiguration verschiedener Tools (z. B. auditd) usw. Diese können ebenfalls in einem Playbook überschrieben werden.

# Setzen Sie auf `true`, wenn IPv6 benötigt wird.
ubuntu_2004_cis_require_ipv6: false

# Setzen Sie auf `true`, wenn drahtlos benötigt wird.
ubuntu_2004_cis_require_wireless: false

# Setzen Sie auf `true`, wenn das System als Router fungieren soll.
ubuntu_2004_cis_require_router: false

# Setzen Sie auf `false`, wenn der SSH-Daemon nicht erforderlich ist.
ubuntu_2004_cis_require_ssh_server: true

# Variable zur Speicherung starker Ciphers für den SSH-Daemon.
ubuntu_2004_cis_require_ssh_ciphers: [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr

# Variable zur Speicherung starker MAC-Algorithmen für den SSH-Daemon.
ubuntu_2004_cis_require_ssh_macs: [email protected],[email protected],hmac-sha2-512,hmac-sha2-256

# Variable zur Speicherung starker Schlüssel Austausch-Algorithmen für den SSH-Daemon.
ubuntu_2004_cis_require_ssh_kexalgorithms: curve25519-sha256,[email protected],diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

# Variable zur Speicherung des Client Alive Intervalls in Sekunden für den SSH-Daemon.
ubuntu_2004_cis_require_ssh_clientaliveinterval: '300'

# Variable zur Speicherung der maximalen Anzahl von Client Alive Count für den SSH-Daemon.
ubuntu_2004_cis_require_ssh_clientalivecountmax: '3'

# Variable zur Speicherung der Login-Grace-Zeit in Sekunden für den SSH-Daemon.
ubuntu_2004_cis_require_ssh_logingracetime: '60'

# Variable zur Speicherung von AllowUsers für den SSH-Daemon.
ubuntu_2004_cis_require_ssh_allowusers: ubuntu vagrant

# Variable zur Speicherung von AllowGroups für den SSH-Daemon.
ubuntu_2004_cis_require_ssh_allowgroups: ubuntu vagrant

# Variable zur Speicherung von DenyUsers für den SSH-Daemon.
ubuntu_2004_cis_require_ssh_denyusers: bogus dummy

# Variable zur Speicherung von DenyGroups für den SSH-Daemon.
ubuntu_2004_cis_require_ssh_denygroups: bogus dummy

# Variable zur Speicherung der minimalen Länge und der Zeichensatz-Klasse für die PAM-Passwortqualität.
ubuntu_2004_cis_require_pam_pwquality:
  - key: 'minlen'
    value: '14'
  - key: 'minclass'
    value: '4'

# Variable zur Speicherung des Wertes von PASS_MAX_DAYS für die Passwortablauf.
ubuntu_2004_cis_require_passmaxdays: '365'

# Variable zur Speicherung des Wertes von PASS_MIN_DAYS für die Passwortänderung.
ubuntu_2004_cis_require_passmindays: '1'

# Variable zur Speicherung des Wertes von INACTIVE, um die Standard-Password-Inaktivitätsperiode auf 30 Tage festzulegen.
ubuntu_2004_cis_require_passwarnage: '7'

# Variable zur Speicherung des Wertes von PASS_WARN_AGE zur Festlegung des Passwortablauffrists in Tagen.
ubuntu_2004_cis_require_passinactive: '30'

# Variable zur Speicherung des Zeitlimits für die Shell in Sekunden.
ubuntu_2004_cis_require_shell_timeout: '900'

# Variable zur Speicherung des Gruppennamens, der für die Nutzung von su erforderlich ist.
ubuntu_2004_cis_require_su_group: sugroup

# Variable zur Speicherung der Protokolldatei, in die die Cron-Jobausführung für die 6.1.1. Audit-Systemdateiberechtigungen (manuelle) Aufgabe propagiert wird.
ubuntu_2004_cis_require_audit_system_file_permissions_logfile: /var/log/6_1_1_cis_audit_system.log

# kann einer von 'iptables', 'nftables' oder 'ufw' sein.
ubuntu_2004_cis_firewall: ufw

# WENN 'ufw' verwendet wird, ermöglicht das Einstellen auf 'yes' die Konfiguration und Erlaubung eines UFW-Git-Anwendungsprofils.
ubuntu_2004_cis_section3_rule_3_5_1_7_ufw_require_git_profile: yes

# WENN 'ufw' verwendet wird, ermöglicht das Einstellen auf 'yes' die Konfiguration und Erlaubung eines UFW-HTTP-Anwendungsprofils.
ubuntu_2004_cis_section3_rule_3_5_1_7_ufw_require_http_profile: yes

# WENN 'ufw' verwendet wird, ermöglicht das Einstellen auf 'yes' die Konfiguration und Erlaubung eines UFW-HTTPS-Anwendungsprofils.
ubuntu_2004_cis_section3_rule_3_5_1_7_ufw_require_https_profile: yes

# WENN 'ufw' verwendet wird, wird durch das Setzen auf 'true' standardmäßig der gesamte eingehende Verkehr blockiert. Fällt zurück auf `ufw default deny incoming`. Setzen Sie auf `false`, wenn Sie dies nicht anwenden möchten.
ubuntu_2004_cis_section3_rule_ufw_default_deny_incoming: true

# WENN 'ufw' verwendet wird, wird durch das Setzen auf 'true' standardmäßig der gesamte ausgehende Verkehr blockiert. Fällt zurück auf `ufw default deny outgoing`. Setzen Sie auf `false`, wenn Sie dies nicht anwenden möchten.
ubuntu_2004_cis_section3_rule_ufw_default_deny_outgoing: true

# WENN 'ufw' verwendet wird, wird durch das Setzen auf 'true' standardmäßig der gesamte weitergeleitete Verkehr blockiert. Fällt zurück auf `ufw default deny routed`. Setzen Sie auf `false`, wenn Sie dies nicht anwenden möchten.
ubuntu_2004_cis_section3_rule_ufw_default_deny_routed: true

# WENN 'nftables' verwendet wird, wird durch das Setzen auf 'true' standardmäßig der gesamte eingehende/weitergeleitete/ausgehende Verkehr blockiert, wodurch das System unerreichbar wird. Setzen Sie auf `false`, wenn Sie dies nicht anwenden möchten oder die Verbindung verlieren.
ubuntu_2004_cis_section3_rule_3_5_2_8: true

# WENN 'iptables' verwendet wird, wird durch das Setzen auf 'true' standardmäßig der gesamte eingehende Verkehr bei IPv4 blockiert, wodurch das System unerreichbar wird. Setzen Sie auf `false`, wenn Sie dies nicht anwenden möchten oder die Verbindung verlieren.
ubuntu_2004_cis_section3_rule_iptables_ipv4_default_deny_input: true

# WENN 'iptables' verwendet wird, wird durch das Setzen auf 'true' standardmäßig der gesamte ausgehende Verkehr bei IPv4 blockiert, wodurch das System unerreichbar wird. Setzen Sie auf `false`, wenn Sie dies nicht anwenden möchten oder die Verbindung verlieren.
ubuntu_2004_cis_section3_rule_iptables_ipv4_default_deny_output: true

# WENN 'iptables' verwendet wird, wird durch das Setzen auf 'true' standardmäßig der gesamte weitergeleitete Verkehr bei IPv4 blockiert, wodurch das System unerreichbar wird. Setzen Sie auf `false`, wenn Sie dies nicht anwenden möchten oder die Verbindung verlieren.
ubuntu_2004_cis_section3_rule_iptables_ipv4_default_deny_forward: true

# WENN 'iptables' verwendet wird und IPv6 aktiviert ist, wird durch das Setzen auf 'true' standardmäßig der gesamte eingehende Verkehr bei IPv4 blockiert, wodurch das System unerreichbar wird. Setzen Sie auf `false`, wenn Sie dies nicht anwenden möchten oder die Verbindung verlieren.
ubuntu_2004_cis_section3_rule_iptables_ipv6_default_deny_input: true

# WENN 'iptables' verwendet wird und IPv6 aktiviert ist, wird durch das Setzen auf 'true' standardmäßig der gesamte ausgehende Verkehr bei IPv4 blockiert, wodurch das System unerreichbar wird. Setzen Sie auf `false`, wenn Sie dies nicht anwenden möchten oder die Verbindung verlieren.
ubuntu_2004_cis_section3_rule_iptables_ipv6_default_deny_output: true

# WENN 'iptables' verwendet wird und IPv6 aktiviert ist, wird durch das Setzen auf 'true' standardmäßig der gesamte weitergeleitete Verkehr bei IPv4 blockiert, wodurch das System unerreichbar wird. Setzen Sie auf `false`, wenn Sie dies nicht anwenden möchten oder die Verbindung verlieren.
ubuntu_2004_cis_section3_rule_iptables_ipv6_default_deny_forward: true

# kann einer von 'ntp', 'chrony' oder 'systemd-timesyncd' sein.
ubuntu_2004_cis_time_synchronization: systemd-timesyncd

# Auditd-Rückstandlimit, um ausreichend Aufzeichnungen beim Booten zu speichern.
ubuntu_2004_cis_auditd_backloglimit: '8192'

# Protokolldateigröße für Auditd-Protokolle. Nach Bedarf festlegen.
ubuntu_2004_cis_auditd_maxlogfile: '25'

# Aktion, die zu ergreifen ist, wenn die Auditd-Protokolle die maximale Größe erreicht haben. Nach Bedarf festlegen.
ubuntu_2004_cis_auditd_maxlogfileaction: keep_logs

# Aktion bei wenig verbleibendem Speicherplatz für Auditd. Nach Bedarf festlegen.
ubuntu_2004_cis_auditd_spaceleftaction: email

# Wer für Auditd zu mailen ist. Nach Bedarf festlegen.
ubuntu_2004_cis_auditd_actionmailacct: root

# Option zum Anhalten, wenn die Audit-Protokolle voll sind. Nach Bedarf festlegen.
ubuntu_2004_cis_auditd_adminspaceleftaction: halt

# Benutzer, die Cronjobs planen dürfen.
ubuntu_2004_cis_cron_allow_users:
  - root
  - ubuntu

# Benutzer, die 'at' verwenden dürfen, um Jobs zu planen.
ubuntu_2004_cis_at_allow_users:
  - root
  - ubuntu

# Setzen Sie auf `true`, wenn das X Windows System erforderlich ist.
ubuntu_2004_cis_require_xwindows_system: false

# Setzen Sie auf `true`, wenn CUPS erforderlich ist.
ubuntu_2004_cis_require_cups: false

# Setzen Sie auf `true`, wenn ein DHCP-Server erforderlich ist.
ubuntu_2004_cis_require_dhcp_server: false

# Setzen Sie auf `true`, wenn ein LDAP-Server erforderlich ist.
ubuntu_2004_cis_require_ldap_server: false

# Setzen Sie auf `true`, wenn ein NFS-Server erforderlich ist.
ubuntu_2004_cis_require_nfs_server: false

# Setzen Sie auf `true`, wenn ein DNS-Server erforderlich ist.
ubuntu_2004_cis_require_dns_server: false

# Setzen Sie auf `true`, wenn ein FTP-Server erforderlich ist.
ubuntu_2004_cis_require_ftp_server: false

# Setzen Sie auf `true`, wenn ein HTTP (apache2)-Server erforderlich ist.
ubuntu_2004_cis_require_http_server: false

# Setzen Sie auf `true`, wenn IMAP- und POP3-Server erforderlich sind.
ubuntu_2004_cis_require_imap_pop3_server: false

# Setzen Sie auf `true`, wenn der Samba-Daemon erforderlich ist.
ubuntu_2004_cis_require_samba_server: false

# Setzen Sie auf `true`, wenn Squid-Server erforderlich ist.
ubuntu_2004_cis_require_squid_server: false

# Setzen Sie auf `true`, wenn ein SNMP-Server erforderlich ist.
ubuntu_2004_cis_require_snmp_server: false

# Um zu vermeiden, dass Postfix im lokalen Modus arbeitet. Definieren Sie als `false`, wenn Postfix im lokalen Modus arbeiten soll.
ubuntu_2004_cis_require_mail_server: true

# Setzen Sie auf `true`, wenn RSYNC erforderlich ist.
ubuntu_2004_cis_require_rsyncd_server: false

# Setzen Sie auf `true`, wenn ein NIS-Server erforderlich ist.
ubuntu_2004_cis_require_nis_server: false

# Setzen Sie auf `true`, wenn ein NIS-Client erforderlich ist.
ubuntu_2004_cis_require_nis_client: false

# Setzen Sie auf `true`, wenn ein RSH-Client erforderlich ist.
ubuntu_2004_cis_require_rsh_client: false

# Setzen Sie auf `true`, wenn ein TALK-Client erforderlich ist.
ubuntu_2004_cis_require_talk_client: false

# Setzen Sie auf `true`, wenn ein TELNET-Client erforderlich ist.
ubuntu_2004_cis_require_telnet_client: false

# Setzen Sie auf `true`, wenn ein LDAP-Client erforderlich ist.
ubuntu_2004_cis_require_ldap_client: false

# Setzen Sie auf `true`, wenn ein RPCBIND-Client erforderlich ist.
ubuntu_2004_cis_require_rpcbind_client: false

5. Abhängigkeiten

Keine

6. Beispiel-Playbooks:

Beispiel-Playbooks sind im playbook-examples Ordner bereitgestellt. Es enthält Playbooks mit Standards und angepassten Anforderungen.

HINWEIS: Da einige der CIS-Kontrollen zum Thema Netzwerk das System möglicherweise beschädigen und den Benutzer daran hindern können, sich erneut in das System einzuloggen, empfehle ich, dass Sie zunächst das playbook-examples/playbook_with_custom_firewall_changes.yml Playbook anwenden oder damit experimentieren. Ändern Sie den Verbindungstyp und die Hosts im Playbook, um Ihren Anforderungen gerecht zu werden.

Anwendung von Beispielen:

Wenn Sie eines der bereitgestellten Playbooks im playbook-examples-Ordner verwenden, können Sie eines davon auswählen und den folgenden Befehl ausführen, um es anzuwenden:

ansible-playbook playbook_with_defaults.yml

ansible-playbook playbook_with_custom_firewall_changes.yml

ansible-playbook playbook_with_ipv6.yml

ansible-playbook playbook_with_ufw.yml

Angenommen, Sie erstellen Ihr eigenes benutzerdefiniertes Playbook mit dem Namen myplaybook.yml, können Sie es einfach mit folgendem Befehl ausführen.

ansible-playbook myplaybook.yml

Anwendung von Beispielen mit Tags:

Alle Aufgaben in der Rolle haben Tags, die basierend auf der CIS-Level-Zuordnung, der Regelnummer und der Abschnittsnummer zugewiesen sind. Standardmäßig werden sowohl die Kontrollen der Level 1 als auch der Level 2 angewendet. Wenn Sie also benutzerdefinierte Anwendungen für Levels, Regelnummern oder Abschnitte ausführen möchten - können Sie die folgenden Beispiele verwenden:

Beispiel für die Anwendung von nur Level 1-Kontrollen:

ansible-playbook <playbook-name-here>.yml --tags "level_1"

Beispiel für die Anwendung von nur Level 2-Kontrollen:

ansible-playbook <playbook-name-here>.yml --tags "level_2"

Beispiel für die Anwendung von Kontrollen eines bestimmten Abschnitts (z. B. Abschnitt 4 des CIS Ubuntu 20.04 Benchmarks als Beispiel):

ansible-playbook <playbook-name-here>.yml --tags "section4"

Beispiel für die Anwendung einer bestimmten Kontrolle (z. B. Kontrolle 6.2.2 des CIS Ubuntu 20.04 Benchmarks als Beispiel):

ansible-playbook <playbook-name-here>.yml --tags "rule_6_2_2"

7. Lokale Entwicklung und CI/CD:

Für die lokale Entwicklung der cis_ubuntu_2004 Rolle führen Sie bitte Folgendes durch:

Forken Sie das Repo.
Klonen Sie es lokal.
Installieren Sie Vagrant auf Ihrem Rechner. Installationsanweisungen sind hier verfügbar, oder wenn Sie möchten, können Sie die darkwizard242.vagrant Rolle nutzen, um es zu installieren - aber bitte überprüfen Sie, ob sie Ihr Betriebssystem unterstützt.
Installieren Sie Virtualbox auf Ihrem Rechner. Installationsanweisungen sind hier verfügbar, oder Sie können die darkwizard242.virtualbox Rolle nutzen, um es zu installieren - aber bitte überprüfen Sie, ob sie Ihr Betriebssystem unterstützt.

Installieren Sie die erforderlichen Module mit:

# Um Pip-Module global zu installieren, wenn Sie als Nicht-Root-Benutzer arbeiten.
sudo -H python3 -m pip install -U molecule ansible-lint flake8 pytest-testinfra molecule-vagrant

ODER

# Um Pip-Module lokal im Benutzerverzeichnis zu installieren, wenn Sie als Nicht-Root-Benutzer arbeiten.
python3 -m pip install -U molecule ansible-lint flake8 pytest-testinfra molecule-vagrant

Nehmen Sie Änderungen vor und führen Sie molecule test oder molecule converge aus.

Der Befehl molecule test führt die gesamte Suite des konfigurierten Molekül-Testablaufs aus.

Der Befehl molecule converge erstellt nur die Vagrant-Instanz und führt alle Operationen aus, die in der Rolle definiert sind.

Natürlich können Sie auch einfach den Code für die cis_ubuntu_2004 Rolle herunterladen, Änderungen vornehmen und über das Ansible-Playbook auf einer Testbox ausführen, wenn Sie nicht mit molecule vertraut sind.

Wenn Sie einen Pull Request erstellen - wird automatisch ein TravisCI-Build hier ausgelöst. Die Konfiguration für den TravisCI-Build befindet sich in .travis.yml. Dies führt verschiedene Aufgaben aus wie:

Code aus dem Pull-Request klonen.
Repository-Cache-Update durchführen.
Notwendige Pakete installieren.
Vagrant und Virtualbox installieren.
SonarCloud-Codequalitätsprüfung für die gesamte Codebasis des Repositories durchführen.
Molecule-Test ausführen (was eine Vagrant-Box bereitstellt, den Rollencode anwendet und die TestInfra-Test-Suite für die Rolle cis_ubuntu_2004 ausführt).

8. Mitwirken:

Beiträge sind herzlich willkommen. Anleitungen zur Mitwirkung finden Sie hier.

Inspiration

Inspiriert von der großartigen Arbeit, die von vielen Mitgliedern der Ansible-Gemeinschaft geleistet wurde (Florian Utz und ansible-lockdown, um nur einige zu nennen). Weiter so :metal: