3 files changed, 73 insertions, 0 deletions
diff --git a/Infrastruktur/Hosting/Benutzerzertifikat.mdwn b/Infrastruktur/Hosting/Benutzerzertifikat.mdwn
new file mode 100644
index 00000000..6e408df7
--- /dev/null
+++ b/Infrastruktur/Hosting/Benutzerzertifikat.mdwn
@@ -0,0 +1,30 @@
+[[!meta title="Verwaltung von Benutzerzertifikaten"]]
+
+Der Zugriff auf viele Ressourcen für die Administration von Starship Factory-Diensten erfordert ein gültiges Benutzerzertifikat. Diese werden üblicherweise durch [[Benutzer/caoimhe]] für maximal 90 Tage ausgestellt.
+
+Zertifikate befinden sich im git-Repository `git+ssh://git@starship-factory.ch:2222/ca-certificates.git` im Verzeichnis *users*.
+
+## Welche Dienste benutzen Clientzertifikate?
+
+* [[Kubernetes|kubernetes-and-ceph]]
+* VPN
+* Sämtliche gRPC-Services in Produktion
+
+## Neues Benutzerzertifikat anlegen
+
+Um ein neues Benutzerzertifikat anzulegen, muss zuerst eine Zertifikatsanfrage gestellt werden. Dazu erzeugen wir eine entsprechende Datei:
+
+`$ umask 077`
+`$ openssl req -new -newkey rsa:4096 -keyout meinuser.key -out meinuser.csr -nodes -subj /OU=starship-factory/CN=meinuser`
+
+Hierbei sollte *meinuser* selbstverständlich durch den eigenen Benutzernamen ersetzt werden.
+
+Die csr-Datei sollte dann in das *users*-Verzeichnis verschoben werden und mittels `git add meinuser.csr && git commit && git push` hochgeladen. Wichtig: nicht die .key-Datei hochladen! Diese sollte sicher gespeichert und mit niemandem geteilt werden.
+
+Nun muss die Anfrage gegenüber [[Benutzer/caoimhe]] autorisiert werden. Das kann durch ein persönliches Treffen geschehen oder durch eine Signatur durch einen vormalig autorisierten PGP-Schlüssel.
+
+Nachdem [[Benutzer/caoimhe]] ihre Arbeit erledigt hat, sollte sich eine Datei namens `meinuser.crt` im Git-Verzeichnis befinden. Diese Datei kann nun zur Authentifizierung benutzt werden.
+
+## Benutzerzertifikat erneuern
+
+Leider haben wir noch keine automatisierten Prozesse zur Erneuerung der Zertifikate (sonst würden wir auch die Erstellung komplett automatisieren). Daher einfach [[Benutzer/caoimhe]] kontaktieren und das erneuerte Zertifikat aus dem *ca-certificates*-Git fischen.
diff --git a/Infrastruktur/Hosting/kubectl.mdwn b/Infrastruktur/Hosting/kubectl.mdwn
new file mode 100644
index 00000000..bbfc00e2
--- /dev/null
+++ b/Infrastruktur/Hosting/kubectl.mdwn
@@ -0,0 +1,37 @@
+[[!meta title="Auf Kubernetes zugreifen"]]
+
+In diesem Dokument ist kurz zusammengefasst, wie der Zugriff auf Kubernetes erfolgt.
+
+[[!toc levels=2]]
+
+## Voraussetzungen
+
+* Gültiges [[Benutzerzertifikat]]
+
+## kubectl installieren und konfigurieren
+
+Um auf Kubernetes zugreifen zu können, wird der Befehl «kubectl» benötigt. Dieser kann auf verschiedenen Wegen installiert werden. Siehe dazu [die Installationsanleitung auf kubernetes.io](https://kubernetes.io/de/docs/tasks/tools/install-kubectl/).
+
+Anschliessend müssen wir noch die Konfiguration einrichten:
+
+`$ kubectl config set-credentials meinuser --username=meinuser --client-certificate=path/to/meinuser.crt --client-key=path/to/meinuser.key`
+`$ kubectl config set-cluster eur --server=https://master.kube.eur.internetputzen.com:6443 --certificate-authority=path/to/certroll.pem`
+`$ kubectl config set-context eur --cluster=eur --user=meinuser --namespace=starship-factory`
+
+## Kubernetes-Konfigurationen
+
+Sämtliche Kubernetes-Konfigurationen für Deployments, Services etc sind unter `git+ssh://git@starship-factory.ch:2222/kube-configs.git` zu finden.
+
+Änderungen an bestehenden Konfigurationen sollten stets im git nachgeführt und mit allen geteilt werden.
+
+## Häufige Befehle
+
+* Liste aller laufenden Containergruppen-Instanzen: `$ kubectl --context=eur get -o wide pods`
+* Liste aller konfigurierten Deployments (Replizierte Container-Gruppen): `$ kubectl --context=eur get -o wide deployment`
+* Liste aller konfigurierten Service-IPs: `$ kubectl --context=eur get -o wide svc`
+* Details über ein Deployment anzeigen: `$ kubectl --context=eur describe deployment blog`
+* Deployment/Service/etc erzeugen oder ändern aus bestehendem YAML-File: `$ kubectl --context=eur apply -f input.yaml`
+
+## Befehle in Notfällen
+
+* Deployment-Eintrag ad-hoc editieren: `$ kubectl --context=eur edit deployment blog`
+\ No newline at end of file
diff --git a/Infrastruktur/Hosting/kubernetes-and-ceph.mdwn b/Infrastruktur/Hosting/kubernetes-and-ceph.mdwn
index c84f5f25..e94583ca 100644
--- a/Infrastruktur/Hosting/kubernetes-and-ceph.mdwn
+++ b/Infrastruktur/Hosting/kubernetes-and-ceph.mdwn
@@ -2,6 +2,8 @@
 
 Wir benutzen für das Hosting der Dienste der Starship Factory die Dienste [Kubernetes](https://kubernetes.io/) und [ceph](https://ceph.io/). Für Details bitte die Dokumentation der jeweiligen Dienste konsolutieren, aber hier gibt es eine Übersicht der Funktionalität.
 
+[[!toc levels=2]]
+
 ## Dienste auf verteilten Serversystemen
 
 Die Grundlage des Hostingsystems basiert darauf, dass unsere Dienste nicht auf einem Server laufen, sondern auf vielen. Dies hat verschiedene Gründe, die auch in den vergangenen Erfahrungen der Starship Factory begründet sind:
@@ -73,3 +75,7 @@ Daten können in Ceph auf verschiedene Arten gespeichert werden. Dadurch können
 * Rados Block Devices funktionieren wie virtuelle Festplatten. Sie können von genau einem Dienst verwendet werden und funktionieren quasi transparent als Speichermedien.
 * Das Rados-System erlaubt das Lesen und Schreiben von Dateien ("Objekten") mittels einer speziellen API (i.e. man muss Dienste speziell dafür entwickeln). Je nach Design der Programme können beliebig viele Dienste darauf zugreifen.
 * Das Ceph File System (CephFS) erlaubt das Speichern vieler Dateien in einer Art virtueller Festplatte, auf welche viele Dienste gleichzeitig zugreifen können; es ist jedoch bedeutend langsamer als Rados Block Devices und verbraucht mehr CPU und RAM.
+
+## Weiterführende Themen
+
+* [[Kubernetes-Zugriff erhalten|kubectl]]