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:

  • 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)

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.

Nutzung von VM-Templates

Momentan gibt es zwei Ubuntu Templates, die von den Usern der Cloud genutzt werden können:

  • Ubuntu 20.04 LTS official cloud image
  • Ubuntu 22.04 LTS official cloud image

Es wird dringend empfohlen die beiden Templates mit dem Cloud-Init Feature hochzufahren. 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.

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.

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.

#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