Best Practices

Sicherheit von VMs

IT Sicherheit ist auch für SPARCI sehr relevant. Jeder SPARCI-User kann dazu einen Beitrag leisten. Um möglichst sicher mit virtuellen Maschinen arbeiten zu können, insbesondere über ssh, ist Folgendes zu berücksichtigen:

Für grundsätzliche Hinweise zur fehlenden Safe-Computing-Zertifizierung der SPARCI-Cloud, zur Eigenverantwortung bei Verschlüsselung und Hardening sowie zu Backups lesen Sie bitte die Seite Safe Computing und Nutzerverantwortung.

  • Einen User mit bspw. "user" und PW "123456" oder "password" anzulegen und den ssh-Login mit diesem trivialen Passwort zu erlauben ist nicht sehr empfehlenswert, erst recht nicht, wenn die Uni-eigene Blockade von Port 22 umgegangen wird
  • Ein starkes Root-Passwort (lässt sich mit einem Passwortmanager generieren) verwenden und den Root-Login per ssh unterbinden (siehe Tutorials im Web). Die klassichen Zugangsdaten sind hilfreich bei Störungsfällen um sich über die Cloudstack-Webkonsole auf eine VM einzuloggen.
  • Legen Sie für jeden User der Zugriff auf die VM haben soll einen sprechenden Usernamen an (Nicht "UserA" bspw., besser an der Unikennung orientieren) und fordern Sie einen Public-Key an. Auch hier: Login über das Passwort ist über die ssh Konfig zu unterbinden, nur die Authentifizierung über einen Token (Private Key) erlauben!
  • Account Sharing unbedingt vermeiden! Bitte nicht auf die Idee kommen einen Dummy User anzulegen mit Dummy Public und Private Key und die Keys im Anschluss zu verteilen
  • Die oben genannten Schritte sollten insbesondere bei studentischen Projekten angewendet werden, legen Sie für jeden benötigten Zugriff einen User an, kopieren Sie die Public Keys und unterbinden Sie den Passwort-Login per ssh
  • Darüber hinaus rate ich dringend davon ab, User-Accounts von Cloudstack zu teilen, das birgt noch ein ganz anderes Sicherheitsrisiko
  • Bitte prüfen ob es unbedingt erforderlich ist, dass jeder User Root-Rechte auf eine Linux-Maschine hat, jeder User sollte so wenig Rechte haben wie nötig! Wenn User grundsätzlich direkt nach dem ssh-Login auf Root-User wechseln hat derjenige/diejenige auch alle Rechte
  • Um SSH Public Keys auf die VM zu kopieren brauchen Sie Cloudstack nicht unbedingt, das geht auch per scp Befehl von der lokalen Maschine aus auf die VM
  • Wichtig ist, das zuvor der entsprechende User auf der VM angelegt wird (muss kein Cloudstack-User sein)
  • Prüfen Sie bei sensiblen Daten ausdrücklich, ob eigene Schutzmaßnahmen innerhalb der VM erforderlich sind; verlassen Sie sich nicht auf plattformseitiges Hardening.

Virtuelle Maschinen

Anbei sind einige Punkte aufgezählt, die sich als sehr hilfreich sowohl bei der Erstellung der virtuellen Maschinen als auch im Betrieb erwiesen haben:

  • Verwenden Sie bei der Erstellung einer VM ein Template statt einer ISO. Der Vorteil liegt insbesondere darin, dass Sie bereits ein vorinstalliertes Betriebssystem starten können und der Installationsvorgang wegfällt.
  • Legen Sie in der virtuellen Maschine immer einen lokalen User (kein ssh) an, der über Root-Rechte auf der VM verfügt. Bei ssh- oder Netzwerkproblemen können Sie über die Cloudstack-Oberfläche immer auf das Linux-System der VM zugreifen
  • Da die Computing-Ressourcen von SPARCI begrenzt sind, wird dringend empfohlen so wenig CPU und Arbeitsspeicher wie nötig zu nutzen. Das bedeutet dass bei Bedarf die VM nur schrittweise skaliert werden sollte bis ausreichend(!) Ressourcen für die VM zur Verfügung stehen.
  • Beobachten Sie bei produktiven Workloads RAM- und Swap-Auslastung. Wenn eine VM stark swappt oder der Kernel Prozesse wegen Speichermangel beendet, kann sie sehr langsam werden oder einfrieren.

Performance und Stabilität

Wenn eine VM ungewöhnlich langsam ist, vergleichen Sie zunächst mit einer ähnlich konfigurierten VM im selben Account oder Projekt. Prüfen Sie innerhalb der VM CPU-Last, I/O-Wartezeit, RAM, Swap und laufende Prozesse, zum Beispiel mit top, free -h, df -h und dmesg.

Typische userseitige Ursachen sind:

  • zu wenig RAM für den Workload
  • dauerhaft hoher Swap-Verbrauch
  • volle Dateisysteme
  • I/O-intensive Jobs auf zu kleinen oder ungeeigneten Volumes
  • zu viele parallel laufende Prozesse

Wenn eine VM einfriert, nutzen Sie die CloudStack-Web-Konsole für die Diagnose. Ist die VM dort noch bedienbar, können Sie Prozesse beenden, Swap/RAM prüfen oder sauber neu starten. Wenn sie nicht mehr bedienbar ist, kann ein Neustart über CloudStack nötig sein.

Wenn mehrere VMs gleichzeitig sehr langsam sind oder eine VM 4- bis 5-mal langsamer ist als vergleichbare VMs, kann ein Hostproblem vorliegen. Nutzer:innen sehen die Host-Platzierung normalerweise nicht selbst. Melden Sie in diesem Fall VM-Namen, IP-Adressen, Zeitraum, Vergleichswerte und auffällige Messungen an die Cloud-Administration.

Nutzung von VM-Templates

Die im Portal sichtbaren Ubuntu-Templates können sich über die Zeit ändern. Prüfen Sie deshalb beim Erstellen einer VM die aktuelle Template-Liste in CloudStack. Offizielle Ubuntu-Cloud-Images sind für den SSH-Key- und Cloud-Init-Workflow vorbereitet; bei selbst installierten ISO-VMs sollten Sie bei Bedarf ein eigenes Projekt-Template erstellen.

Es wird dringend empfohlen, offizielle Cloud-Images mit Cloud-Init zu konfigurieren. Cloud-Init ist ein Linux-System, das für die Verarbeitung der frühen Initialisierung von virtuellen Instanzen zuständig ist. Cloud-Init ist für die SPARCI-Cloud verfügbar, so können zahlreiche gängige Parameter der Instanz direkt während und nach der Installation konfiguriert werden. Auf diese Weise wird eine voll funktionsfähige Instanz erstellt, die basierend auf einer Reihe von Eingaben konfiguriert wird. Der generische CloudStack-Mechanismus ist in der offiziellen Dokumentation unter User Data and Metadata beschrieben.

Das Verhalten von Cloud-Init kann über Benutzerdaten konfiguriert werden. Benutzerdaten können vom Benutzer beim Starten der Instanz angegeben werden.

Die Cloud-Init Konfiguration lässt sich einfach in der Ersellmaske für VMs unter "8 Advanced Mode" -> "Userdata" eintragen:

Create VM UI

Beispiel #1 für eine Cloud-Init Konfiguration:

Das folgende Beispiel zeigt eine Koniguration mit der Erstellung eines lokalen Users names my-local-backup-user sowie einen User my-remote-access-user mit mehreren SSH-Keys und sudo-Rechten:

#cloud-config

package_update: true
package_upgrade: true
package_reboot_if_required: true
timezone: Europe/Berlin
keyboard:
  layout: de

users:
  - name: my-local-backup-user
    lock_passwd: false
    plain_text_passwd: '123456'
    shell: /bin/bash
    sudo: ALL=(ALL) NOPASSWD:ALL
  - name: my-remote-access-user
    lock_passwd: true
    shell: /bin/bash
    ssh-authorized-keys:
      - "ssh-rsa <key1> user"
      - "ssh-rsa <key2> user"
    sudo:
      - ALL=(ALL) NOPASSWD:ALL

write_files:
  - path: /etc/ssh/sshd_config
    append: true
    content: "DenyUsers my-local-backup-user"

Als Erstes wird unter users: ein lokaler User mit Passwort ohne ssh-Zugang angelget. Unter write_files wird in der sshd_config die Anmeldung über ssh für den lokalen User gesperrt. Gleichwohl ist der Zugriff auf die VM über die Cloudstack-Konsole durch die Anlage des lokalen Users sichergestellt.

Wird darüber hinaus die virtuelle Maschine in CloudStack - nach dem ersten Start - umbenannt und anschließend neu gestartet, dann sollte der Hostname der Maschine sich dank Cloud-Init auch aktualisieren. Zu erkennen am Command Prompt ubuntu@<HOSTNAME>:~$ bzw. an der Ausgabe von hostname. Das ist stets eine einfache Möglichkeit schnell zu prüfen, ob Cloud-Init funktioniert.

Bei offiziellen Ubuntu-Templates ist ubuntu in der Regel der initiale Benutzername für den SSH-Zugriff, sofern per Cloud-Init kein anderer Benutzer angelegt wurde. Der CloudStack-Accountname, die Uni-Kennung oder der Instanzname sind nicht automatisch gültige Linux-Benutzernamen. Wenn der SSH-Login trotz hinterlegtem SSH-Key mit Permission denied fehlschlägt, sollte deshalb zuerst der verwendete Benutzername geprüft werden.

Beispiel #2 für eine Cloud-Init Konfiguration:

Das nächste Cloud-Init Beispiel zeigt die direkte Installation von Docker installieren lässt und einem User auch die Rechte gewährt Docker zu nutzen. Achtung: Das Beispiel funktioniert nur, wenn eine Festplatte mit mindestens 4 GB der VM als Root-Volume zugewiesen wird.

Docker wird in SPARCI innerhalb einer normalen CloudStack-VM betrieben. Aus Docker-Images oder Dockerfiles werden keine CloudStack-VMs direkt erzeugt; die VM bildet die Virtualisierungsschicht, Docker läuft anschließend im Betriebssystem der VM. Für GPU-Container muss zusätzlich das NVIDIA Container Toolkit in der GPU-VM installiert werden, damit die zugewiesene vGPU an Container weitergereicht werden kann.

#cloud-config

package_update: true
package_upgrade: true
package_reboot_if_required: true

keyboard:
  layout: de

packages:
  - apt-transport-https
  - ca-certificates
  - curl
  - gnupg-agent
  - software-properties-common

runcmd:
  - curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
  - add-apt-repository "deb [arch=$(dpkg --print-architecture)] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
  - apt-get update -y
  - apt-get install -y docker-ce docker-ce-cli containerd.io
  - gpasswd -a <username> docker
  - systemctl start docker
  - systemctl enable docker

Ferner ist zu berücksichtigen, dass Cloud-Init erst initialisiert wird, wenn die VM hochgefahren ist. Wenn sofort eine SSH-Verbindung aufgebaut wird kann es sein, dass die Installation von Docker noch läuft und noch nicht abgeschlossen ist. Mit sudo grep cloud-init /var/log/syslog lässt sich der Status der Installation verfolgen.

Erstellen eigener Templates

Es ist möglich eigene Templates zu erstellen. Dazu muss eine VM mit dem gewünschten Betriebssystem erstellt werden. Anschließend kann die VM heruntergefahren und ein Template erstellt werden. Das Template kann dann für die Erstellung neuer VMs verwendet werden.

Beim Erstellen von Templates ist es unerlässlich, das Feld für den Betriebssystemtyp (OS Type) korrekt auszufüllen, zum Beispiel "Ubuntu 21.04" für Templates mit Ubuntu 21 oder neuer. Eine fehlerhafte Angabe in diesem Feld, wie etwa "Linux 5.x Kernel", kann dazu führen, dass CloudStack möglicherweise nicht die passenden Treiber, DiskController und ähnliche Komponenten korrekt lädt. Dies kann zu verschiedenen Problemen führen, unter anderem zu einem inkorrekten Labelling von Volumes (beispielsweise wird /dev/sda/ statt /dev/vdb/ angezeigt).

Sollte eine solche fehlerhafte Zuweisung identifiziert werden, besteht die Möglichkeit, das Template nachträglich zu bearbeiten, um den korrekten OS-Typ anzugeben.

OS type von Templates

Bei der nachträglichen Anpassung des OS type eines Templates ist es zwingend erforderlich, auch die entsprechenden Einträge für jede virtuelle Maschine, die aus diesem Template erstellt wurde, zu aktualisieren.

OS type von VMs