Commit 1f58e728 authored by k.elaammari's avatar k.elaammari
Browse files

readme

parent 629c6869
......@@ -94,85 +94,6 @@ Um ein Backup in die InfluxDB wieder zurück zuspielen, benutzen Sie folgendes S
Die %PFAD% Variable ist hierbei der Ordner indem sich die Backupdateien befinden. Sollte in Ihrer Influx-Instanz schon die Datenbank "prom" existieren, werden Sie gefragt ob Sie diese löschen wollen, um die "prom"-Datenbank aus dem Backup laden zu können. Diese Operation ist notwendig, da hier bei jedem Backup die vollständige Datenbank gesichert wird und dementsprechend eine vollständige Datenbank zurück gespielt wird.
## Openssl
Um den Datenverkehr zu verschlüsseln und die Dienste authentifizieren zu können, benötigen wir TLS-Zertifikat die wir mit dem Openssl-Toolkit erzeugen (<https://www.openssl.org/>). Hierfür wird zuerst ein Root-Zertifikat (cacert.pem) erzeugt und anschließend die Zertifikate für die Dienste Grafana, Influx und Chronograf. Diese werden von dem Root-Zertifikat signiert, sodass mit dem Root-Zertifikat die Authentifizierung erfolgen kann. Wichtig ist zu beachten, dass zu jedem Zertifikat auch ein Private-Key existiert, so z.B. cacert.pem und cakey.pem oder influxcert.pem und influxkey.pem.
### Openssl Ordnerstruktur
```shell
./openssl
./config
./chronograf.cnf
./grafana.cnf
./influx.cnf
./openssl-ca.cnf
./data
./certificates
./csrdb
```
Im Config-Verzeichnis befinden sich die Konfigurationsdateien für die Zertifikate. In diesen können Sie die Standardwerte für organizationName, commonName, emailAddress, usw. ändern, die bei der Erzeugung in die Zertifikate eingetragen werden. Das Data-Verzeichnis wird erst nachdem ausführen von ```./scripts/openssl_generate.sh``` erstellt und enthält die Zertifikate im Ordner "certificates", sowie den Zustand der Openssl-Textdatenbank im Ordner "csrdb". Csrdb wird für das Signieren der Zertifikate gebraucht und enthält unteranderem die aktuelle Seriennummer.
### Zertifikat-Seriennummer
Zertifikate enthalten nach dem X.509 Standard eine Seriennummer, die bei der Signierung bestimmt wird. Die mit dem ```./scripts/openssl_generate.sh``` erstellten und signierten Zertifikate werden Standartmäßig mit der Seriennummer 0x2 aufwärts signiert. Manche Browser, wie z.B. der Firefox, melden aber einen Fehler, wenn vom Selben "Issuer: C, ST, L, O, OU, CN" eine vergebene Seriennummer nochmal an ein anderes Zertifikat vergeben wird. In diesem Fall können sie mit einem CLI-Argument die anfangs Seriennummer auf einen andere Wert setzen. Die Seriennummer wird als Hex-Zahl angegeben und die Anzahl der Ziffern muss grade sein. So würde z.B. 0F1 zu einem Fehler führen und sollte als F1 oder 00F1 eingegeben werden.
```shell
#./scripts/openssl_generate.sh 01
#./scripts/openssl_generate.sh FF
#./scripts/openssl_generate.sh 0100
#./scripts/openssl_generate.sh FFFF
#./scripts/openssl_generate.sh 010000
#./scripts/openssl_generate.sh 0FFF8729
#./scripts/openssl_generate.sh 01FA55DEC3
...
```
### Private-Key verloren
Wenn ein Private-Key auf irgendeine Art an Dritte verloren gegangen ist, müssen Sie reagieren. In diesem Fall ist zu unterscheiden, ob es sich um den cakey.pem, also der Root-Key oder den Key eines Dienstes wie grafanakey.pem handelt. Sollten Sie ihren Root-Key verlieren, ist ihre Kommunikation zwischen den Diensten auch für 3.te weiterhin sicher verschlüsselt, aber mit dem Root-Key könnten fremde Zertifikate signiert werden, welche dann von Ihrem installierten Root-Zertifikat als gültig anerkannt werden würden. Im zweiten Fall, wenn Sie den Privat-Key eines Dienstes verloren haben, könnten zwar keine Zertifikate signiert werden, aber mit dem aktuellen Privat-Key, kann sich ein 3.ter als der Dienst ausgeben, für den das Zertifikat ausgestellt wurde. Des Weiteren sind die mit dem Zertifikat aufgebauten verschlüsselten Verbindungen auch nur noch bedingt sicher vor dem Mitlesen Dritter.
* Root-Key verloren, in diesem Fall müssen alle Zertifikate neu erzeugt werden. Zusätzlich müssen sie jeden informieren, dem aktuellen Root-Zertifikat cacert.pem das Vertrauen zu entziehen. Führen Sie ```./scripts/openssl_generate.sh``` neu aus und verteilen die Zertifikate mit dem Vagrant File-Provisionierer neu auf die Maschinen. Beachten Sie die Zertifikat-Seriennummer.
```shell
./scripts/openssl_generate.sh
vagrant provision --all
```
* Dienst-Key verloren, bedeutet, dass Sie nur das jeweilige Zertifikat ersetzen müssen.
```shell
./scripts/openssl_node.sh (flux | graf | chron)
vagrant provision (flux | graf | chron)
```
### Eigene Zertifikate
Wenn Sie eigene Zertifikate erzeugen und diese in diesem Workflow benutzen möchten, müssen Sie diese an die entsprechenden Pfade kopieren oder verlinken. Standardmäßig werden die erzeugten Zertifikate aus ```./openssl/data/certificates``` mit dem jeweiligen Provision-Verzeichnis der VMs verlinkt. Sie können an dieselben Stellen ````./provision/*/https``` Ihre Zertifikate kopieren und mit dem Provisionierer diese übertragen lassen. Sollten ihre Zertifikate nicht wie unten benannt werden können, müssen Sie zusätzlich in den Konfigurationen die geänderten Dateinamen eintragen.
```shell
./provision
./chronograf
./config/chronograf.service # TLS_CERTIFICATE, TLS_PRIVATE_KEY
./https
./cacert.pem
./chronografcert.pem
./chronografkey.pem
./grafana
./config/graf_conf.ini # Sektion [server]: cert_file, cert_key
./https
./cacert.pem
./grafanacert.pem
./grafanakey.pem
./influx
./config/influxdb.conf # Sektion [http]: https-certificate, https-private-key
./https
./cacert.pem
./influxcert.pem
./influxkey.pem
```
## Authentifizierung
### Grafana
......@@ -236,13 +157,13 @@ sudo curl -X POST http://localhost:9090/-/reload
```
##### Grafana
Um die Influx-Datasource zu aktualisieren, wählen Sie im Grafana-UI > Configuration > Data Source > InfluxDB aus und tragen in der Sektion "InfluxDB Details" die neuen Benutzerdaten ein. Wenn Sie zusätzlich auch das Standartpassword in den Influx-Setupqueries geändert haben, sollten Sie diese Änderung auch in die JSON-Datei der Datasource eintragen, ohne die Provisionierung neu auszuführen.
Tragen Sie die neuen Benutzerdaten in folgende Datei ein, führen die Provisionierung neu aus.
```shell
./provision/grafana/config/datasources/ds_influx.json
```
#### Admin Passwort zurücksetzen
#### Influx-Admin Passwort zurücksetzen
Sollte ein 2.ter Admin-Benutzer existieren, kann mit den oben beschriebenen Methoden das Passwort geändert werden. Ist kein weitere Admin-Benutzer verfügbar, muss die Authentifizierung abgeschaltet werden und dann ein neuer Admin erzeugt werden.
......@@ -262,3 +183,81 @@ sudo nano /etc/influxdb/influxdb.conf
systemctl restart influx
```
## Openssl
Um den Datenverkehr zu verschlüsseln und die Dienste authentifizieren zu können, benötigen wir TLS-Zertifikat die wir mit dem Openssl-Toolkit erzeugen (<https://www.openssl.org/>). Hierfür wird zuerst ein Root-Zertifikat (cacert.pem) erzeugt und anschließend die Zertifikate für die Dienste Grafana, Influx und Chronograf. Diese werden von dem Root-Zertifikat signiert, sodass mit dem Root-Zertifikat die Authentifizierung erfolgen kann. Wichtig ist zu beachten, dass zu jedem Zertifikat auch ein Private-Key existiert, so z.B. cacert.pem und cakey.pem oder influxcert.pem und influxkey.pem.
### Openssl Ordnerstruktur
```shell
./openssl
./config
./chronograf.cnf
./grafana.cnf
./influx.cnf
./openssl-ca.cnf
./data
./certificates
./csrdb
```
Im Config-Verzeichnis befinden sich die Konfigurationsdateien für die Zertifikate. In diesen können Sie die Standardwerte für organizationName, commonName, emailAddress, usw. ändern, die bei der Erzeugung in die Zertifikate eingetragen werden. Das Data-Verzeichnis wird erst nachdem ausführen von ```./scripts/openssl_generate.sh``` erstellt und enthält die Zertifikate im Ordner "certificates", sowie den Zustand der Openssl-Textdatenbank im Ordner "csrdb". Csrdb wird für das Signieren der Zertifikate gebraucht und enthält unteranderem die aktuelle Seriennummer.
### Zertifikat-Seriennummer
Zertifikate enthalten nach dem X.509 Standard eine Seriennummer, die bei der Signierung bestimmt wird. Die mit dem ```./scripts/openssl_generate.sh``` erstellten und signierten Zertifikate werden Standartmäßig mit der Seriennummer 0x2 aufwärts signiert. Manche Browser, wie z.B. der Firefox, melden aber einen Fehler, wenn vom Selben "Issuer: C, ST, L, O, OU, CN" eine vergebene Seriennummer nochmal an ein anderes Zertifikat vergeben wird. In diesem Fall können sie mit einem CLI-Argument die anfangs Seriennummer auf einen andere Wert setzen. Die Seriennummer wird als Hex-Zahl angegeben und die Anzahl der Ziffern muss grade sein. So würde z.B. 0F1 zu einem Fehler führen und sollte als F1 oder 00F1 eingegeben werden.
```shell
#./scripts/openssl_generate.sh 01
#./scripts/openssl_generate.sh FF
#./scripts/openssl_generate.sh 0100
#./scripts/openssl_generate.sh FFFF
#./scripts/openssl_generate.sh 010000
#./scripts/openssl_generate.sh 0FFF8729
#./scripts/openssl_generate.sh 01FA55DEC3
...
```
### Private-Key verloren
Wenn ein Private-Key auf irgendeine Art an Dritte verloren gegangen ist, müssen Sie reagieren. In diesem Fall ist zu unterscheiden, ob es sich um den cakey.pem, also der Root-Key oder den Key eines Dienstes wie grafanakey.pem handelt. Sollten Sie ihren Root-Key verlieren, ist ihre Kommunikation zwischen den Diensten auch für 3.te weiterhin sicher verschlüsselt, aber mit dem Root-Key könnten fremde Zertifikate signiert werden, welche dann von Ihrem installierten Root-Zertifikat als gültig anerkannt werden würden. Im zweiten Fall, wenn Sie den Privat-Key eines Dienstes verloren haben, könnten zwar keine Zertifikate signiert werden, aber mit dem aktuellen Privat-Key, kann sich ein 3.ter als der Dienst ausgeben, für den das Zertifikat ausgestellt wurde. Des Weiteren sind die mit dem Zertifikat aufgebauten verschlüsselten Verbindungen auch nur noch bedingt sicher vor dem Mitlesen Dritter.
* Root-Key verloren, in diesem Fall müssen alle Zertifikate neu erzeugt werden. Zusätzlich müssen sie jeden informieren, dem aktuellen Root-Zertifikat cacert.pem das Vertrauen zu entziehen. Führen Sie ```./scripts/openssl_generate.sh``` neu aus und verteilen die Zertifikate mit dem Vagrant File-Provisionierer neu auf die Maschinen. Beachten Sie die Zertifikat-Seriennummer.
```shell
./scripts/openssl_generate.sh
vagrant provision --all
```
* Dienst-Key verloren, bedeutet, dass Sie nur das jeweilige Zertifikat ersetzen müssen.
```shell
./scripts/openssl_node.sh (flux | graf | chron)
vagrant provision (flux | graf | chron)
```
### Eigene Zertifikate
Wenn Sie eigene Zertifikate erzeugen und diese in diesem Workflow benutzen möchten, müssen Sie diese an die entsprechenden Pfade kopieren oder verlinken. Standardmäßig werden die erzeugten Zertifikate aus ```./openssl/data/certificates``` mit dem jeweiligen Provision-Verzeichnis der VMs verlinkt. Sie können an dieselben Stellen ````./provision/*/https``` Ihre Zertifikate kopieren und mit dem Provisionierer diese übertragen lassen. Sollten ihre Zertifikate nicht wie unten benannt werden können, müssen Sie zusätzlich in den Konfigurationen die geänderten Dateinamen eintragen.
```shell
./provision
./chronograf
./config/chronograf.service # TLS_CERTIFICATE, TLS_PRIVATE_KEY
./https
./cacert.pem
./chronografcert.pem
./chronografkey.pem
./grafana
./config/graf_conf.ini # Sektion [server]: cert_file, cert_key
./https
./cacert.pem
./grafanacert.pem
./grafanakey.pem
./influx
./config/influxdb.conf # Sektion [http]: https-certificate, https-private-key
./https
./cacert.pem
./influxcert.pem
./influxkey.pem
```
\ No newline at end of file
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment