---
title: Sicherer Betrieb von Diensten in eScience
lang: de
tags: eScience, Sicherheit, Dienste
---

Sicherer Betrieb von Diensten in eScience
===

| | |
| ---------- | ---------- |
| Gültig ab: | |
| Version: | 0.1.0 |
| Datum: | 20.07.2021 |

<!-- !!! error "TLP:RED"
Not for disclosure, restricted to participants only. Distribution outside this audience requires written permission from the originator. -->

!!! attention "TLP:AMBER"
Limited disclosure, restricted to participants' organizations.
Distribution outside this audience requires written permission from the originator.

<!-- !!! important "TLP:GREEN"
Limited disclosure, restricted to the community/sector. Distribution outside this audience requires written permission from the originator. -->

<!-- !!! note "TLP:WHITE"
Disclosure not limited. -->

Version | Datum | Autor*innen | Änderungen
------- | ---------- | --------------- | ----------
0.1.0 | 19.07.2021 | MJ | Dokumentenstub erstellt. Erste Dienste testweise beschrieben.

## Inhalt

[TOC]

## Einleitung

TODO

## Sicherheitszonen


## Zone 1: Authentifizierung und Autorisierung

TOD: Wie wollen wir das machen? Ist noch die größte Unbekannte.

## Zone 2: Persistenter und Sicherer Speicher

TODO: Wenn wir wissen welche Speicher wir brauchen, hier kurz eingehen.

## Zone 3: Dienste

Die Zone muss so konfiguriert sein,
dass Dienste auch im Desasterfall, schnell, einfach und sicher wiederhergestellt werden können.
Einige Dienste werden zum Kickstart bzw. Bootstrap benötigt.
Das Dokument ist in mehrere Phasen gegliedert,
die eine komplette Wiederherstellung der Zone 3 beschreiben.

### Phase I: Wiederherstellung Rezepte und Konfigurationen

#### GIT

Dieser Dienst ist essenziell und wird für Ansible-Rezepte und Konfigurationen benötigt.
Um ein Mehraugenprinzip du gewährleisten,
sollte die Möglichkeit bestehen,
Repositorien zu "forken" und Pull-Requests zu stellen.
Dieser Dienst muss eventuell als erstes wiederhergestellt werden und sollte weitgehend ohne große Anpassungen und Konfigurationen auskommen müssen.

Empfohlen wird Gitea, Gogs, etc.
Diese Git-Dienste bieten Forks und Pull-Requests und können einfach aufgesetzt werden.
Eine Installation ist nicht notwendig, das das Binary direkt heruntergeladen werden kann.
Somit kann der Dienst im Desasterfall sofort und überall aufgesetzt werden.

Gitea und Gogs können Mirroring in andere Git-Repositorien https://docs.gitea.io/en-us/comparison/ (12.10.2021).
Bei Gitlab ist neben Mirroring in Enterprise-Edition ebenfalls Geo-Replikation möglich https://about.gitlab.com/solutions/geo/ (12.10.2021).

##### Abhängigkeiten und Netzwerk

Die Git-Datenbank muss aus der Zone 2 wiederhergestellt werden können. Hierzu sollte ein Git-Backupserver betrieben werden.

TODO: Wie bekommt man das sicher hin, dass man zb, wenn der Primäre GIT geknackt wurde, nicht gleich der andere mit entsorgt wird?

Der Git-Dienst muss von allen Diensten in Zone 3 erreichbar sein,
jedoch nicht in die Zone 4 exponiert werden.
Er benötigt Zugriff auf eine Sicherheitskopie des Git-Repos in Zone 2.

##### Wiederherstellungsprozedur

Der Dienst kann auf einen Knoten, der lokal mit einer SSD,
einem USB-Stick oder als VM gestartet wurde und ein minimales Linux-System beinhaltet, gestartet werden.
Hierzu muss lediglich ein Binary herunter geladen werden und der Dienst gestartet werden.
Die Git-Datenbank, sollte von einem weiteren Git-Dienst wiederhergestellt werden.
Um die Konfiguration der nachgelagerten Dienste zu vereinfachen,
sollte der alte Hostname auf den neuen Knoten zeigen.

### Phase II: Wiederherstellung des Direktor- oder Orchestreirungsdienstes

#### Ansible

Ansible wird benötigt um die meisten Dienste initial zu installieren und zu konfigurieren.
Spätere Konfigurationen müssen mit Ansible erfolgen,
damit alle Anpassungen für den Fall einer Wiederherstellung vorhanden sind.
Die Konfigurationen werden in Git gespeichert,
damit Änderungen nachverfolgbar sind.
Es sollten jeweils nur einzelne Dateien oder Rollen in einem Commit verwendet werden.
So wird sichergestellt, dass falls Commits zurückgenommen werden müssen nur eine Rolle betroffen ist.
Außerdem sollte zur Sicherheit kein direkter Push in das Git-Repository möglich sein.
Wenn immer Möglich sollte mit Forks und Pull-Requests gearbeitet werden, um ein Mehraugenprinzip zu gewährleisten.
Hier ist weniger der Code-Review im Vordergrund,
sondern dass hierbei schädlicher Code oder Manipulation von außen erschwert wird.

##### Abhängigkeiten

Ansible hängt vom Git-Dienst ab.
Es benötigt Zugriff alle Server in Zone 3, da es die Dienste ausrollt und konfiguriert.
Auf den Ansible-Dienst sollte kein anderer Dienst Zugriff haben.

##### Wiederherstellungsprozedur

Der Dienst kann auf einen Knoten, der lokal mit einer SSD,
einem USB-Stick oder als VM gestartet wurde und ein minimales Linux-System beinhaltet, installiert werden.
Die Konfiguration des Dienstes und die Rezepte werden von einem Git-Dienst gezogen.

### Phase III: Wiederherstellung der Image-Dienste

#### DNBD3

Der DNBD3-Dienst stellt das Bootsystem für Zone 4 und für einige der Dienste in Zone 3 dar.
Dabei sollten die Netze der Zonen 3 und 4 getrennt werden,
so dass es nicht möglich ist,
Betreibssystem-Images der Server auf den Clients in Zone 4 zu starten.

TODO: Sollten wir sicherstellen, da wir da andere Passwörter etc. benötigen.

Der Primär- und alle Sekundärdienste müssen lokal starten,
und dürfen nicht von einem anderen DNBD3-dienst abhängen.
Der Primärserver ist üblicherweise der Bootserver,
bis die Knoten gebootet sind.
Sekundärdienste dienen der Ausfallsicherheit und der Verringerung der Latenz.

##### Abhängigkeiten

DNBD3 hängt vom Ansible-Dienst ab.
Es benötigt keinen Zugriff auf andere Dienste.
Knoten in Zone 3 und 4 müssen Zugriff auf den DNBD3-Dienst erhalten.

##### Wiederherstellungsprozedur

Der Dienst kann auf einen Knoten, der lokal mit einer SSD,
einem USB-Stick oder als VM gestartet wurde und ein minimales Linux-System beinhaltet,
installiert und konfiguriert werden.
Die Installation und Konfiguration erfolgt über Ansible.

#### HTTP und TFTP

TODO: Für Diskless-Boot, sollte selbst nicht diskless betrieben werden ;)
Derzeit ist das der BAS. Das sollte man evtl ,am mit einer Ansible-Rolle aufsetzen + die Configs in ipxelinux nach -> GIT (zb als Ansible-Rolle).

#### Kubernetes-Gedöns benötigt?

### Phase IIII: Wiederherstellung der restlichen Dienste in Zone 3

#### SLURM

TODO: DNBD3 + Docker, oder DNBD3 + Kubernetes, oder schmales System auf SSD + Container?
Würde ich mal Kubernetes testen, da das dann vom System drunter unabhängig ist. Falls wir Kubernetes machen wollen. Wenn Kubernetes nicht geeignet ist, evtl. Docker und als letztes bare-metal mit Ansible.

### Zusammenfassung

Zugriff | Dienst | Z1 | Z2 | Z3 | Z4
------- | ------ | -- | -- | -- | --
Dienst | | | DNBD3, Git
Z1 |
Z2 | DNBD3
Z3 | DNBD3, Git
Z4 | DNBD3

## Zone 4: Nutzerzone

###### tags: `eScience` `Sicherheit` `Dienste`