Wie Sie ZETA-Guard in einem Kubernetes-Cluster installieren und konfigurieren


Status: Grob-Entwurf

Zielgruppe: Systemadministratoren

Inhalt: Beschreibung der erforderlichen Hardware und Software, mögliche Betriebssysteme und -Versionen, vorausgesetzte Software-Umgebung wie etwa Standardbibliotheken und Laufzeitsysteme. Erläuterung der Prozeduren zur Installation, außerdem zur Pflege (Updates) und De-Installation, bei kleinen Produkten eine Readme-Datei. Zielgruppe sind Administratoren beim Anwender, die die Software nicht zwangsläufig unmittelbar selbst nutzen müssen.


[TOC]

Überblick

To-do: ein Verteilungsdiagramm wäre schöner

Abbildung Zero Trust-Architektur der TI 2.0

Voraussetzungen

  • ein Kubernetes-Cluster
    • in dem sich Resource Server und Application Authorization Backend befinden
    • mit einem Ingress-Controller
    • mit Zugang zu den relevanten Container-Registries
  • alle Dienste aus der Liste der Abhängigkeiten unten

  • To-do: sammle Voraussetzungen der einzelnen Bausteine

Vorgehen

1. Ingress-Controller installieren und Ingress konfigurieren

In dem Cluster muss ein Ingress-Controller installiert sein und erlaubter Ingress definiert werden. Nur der HTTP-Proxy des Enforcement-Points, der Authorization-Server des Decision-Points und der Notification Service dürfen von außerhalb des Clusters erreichbar sein.

Als Vorlage für einen Ingress mit einem nginx-basierten Ingress-Controller können Sie diese Ingress-Definition verwenden.

2. Egress konfigurieren

Richten Sie für den Cluster Network-Policys ein, die unerwarteten Netzwerkverkehr aus dem Cluster unterbinden.

Bekannte, valide Ziele außerhalb des Clusters sind

  • Clientsystem Notification Service(s) – Apple Push Notifications, Firebase
  • Email Confirmation-Code – Mailversand
  • Federated IDP
  • Dienstanbieter-Monitoring
  • Dienstanbieter-SIEM
  • Diensthersteller-Monitoring
  • TI-Monitoring
  • TI-SIEM
  • ZETA Container-Registry
  • ZETA Git Repository
  • ZETA PAP Service
  • ZETA PIP Service

3. Management Service (ArgoCD) installieren und konfigurieren

  • Kommt in Meilenstein 2
  • To-Do: Sidecar Container mit OpenTelemetry Collector
  • Ggf. mit Zugang zur UI für Administratoren einrichten

Verwandte Dokumentation

Abhängigkeiten / erforderliche Konfiguration

  • Adresse von und Credentials für ZETA Container Registry
  • Adresse von und Credentials für ZETA Git Repository
  • Adresse von und Credentials für kube-apiserver zur Verwaltung des Kubernetes-Clusters

4. Telemetriedaten Service (OpenTelemetry Collector) installieren und konfigurieren

Zunächst erfassen Komponenten-spezifische Collector-Instanzen Telemetriedaten. Ein zentraler Collector bündelt und filtert diese, bevor sie an die Monitoring- und SIEM-Dienste der TI weitergeleitet werden.

  • To-do
  • To-do: als Kubernetes Sidecar Container für jede Komponente

Verwandte Dokumentation

Abhängigkeiten / erforderliche Konfiguration

  • Muss wahrscheinlich die Adressen der Open-Telemetrie-Endpunkte kennen, von denen er Telemetrie-Daten einsammeln soll
  • Muss ggf. die Adresse des nächsten Telemetrie-Dienstes in der Kette kennen

5. Notification Service (TI-M Notification Service) installieren und konfigurieren

  • Kommt in Meilenstein 2
  • To-do: Sidecar Container mit OpenTelemetry Collector

Abhängigkeiten / erforderliche Konfiguration

  • APN-Konfiguration (Apple Push Notification)
  • Firebase-Konfiguration (Android Push Notification)

6. Policy Decision Point installieren und konfigurieren

6.1 PDP Datenbank (PostgreSQL) installieren und konfigurieren

Für Keycloak müssen Sie eine PostgreSQL-Datenbank installieren und konfigurieren. Hierfür können Sie beispielsweise Zalandos Postgres-Operator verwenden.

Als Anschauungsbeispiel kann dieser Helm-Chart herangezogen werden.

To-do: Sidecar Container mit OpenTelemetry Collector

6.2 Policy Engine (OPA) installieren und konfigurieren

Jede OPA-Instanz muss Policys vom PIP abfragen und Metriken für seinen OpenTelemetry Collector bereitstellen.

Zur Veranschaulichung dienen Deployment- und Service-Definitionen in folgendem Helm-Chart als Beispiel.

  • To-do: PIP – kommt in Meilenstein 2
  • To-do: Sidecar Container mit OpenTelemetry Collector
Verwandte Dokumentation
Abhängigkeiten / erforderliche Konfiguration
  • PIP stellt Policy Bundles und Bundle Signer Zertifikate bereit

6.3 Authorization Service (Keycloak) installieren und konfigurieren

Keycloak muss mit seiner Datenbank und seinem OPA verbunden sein, einen eigenen Open Telemetry Collector besitzen und von außerhalb des Clusters erreichbar sein.

Als Beispiel können Sie die Deployment- und-Service-Definitionen in folgendem Helm-Charts verwenden.

Die Installation erfolgt über den Helm-Chart, während die eigentliche Konfiguration des deployten Keycloak mittels Terraform vorgenommen wird.

  • To-do: OPA-Verbindung, späterer Meilenstein?
  • To-do: Sidecar Container mit OpenTelemetry Collector
Abhängigkeiten / erforderliche Konfiguration
Datenbankverbindung und Benutzer-Credentials für die PDP Datenbank

Die Konfiguration einer Datenbankverbindung für Keycloak wird in dieser Anleitung erklärt. Die für die Datenbankverbindung relevanten Umgebungsvariablen lauten:

  • KC_DB (Standardwert postgres)
  • KC_DB_URL: (Standardwert jdbc:postgresql://keycloak-db:5432/keycloak)
  • KC_DB_USERNAME: (Technischer Datenbank-User)
  • KC_DB_PASSWORD: (DB-Passwort)
Adresse der Policy Engine (OPA)
Verwandte Dokumentation

7. Policy Enforcement Point einrichten

7.1 PEP Datenbank (Infinispan) einrichten

  • Kommt in Meilenstein 2
  • To-do: Sidecar Container mit OpenTelemetry Collector

7.2 HTTP Proxy (nginx) installieren und konfigurieren

Zur Veranschaulichung der Installation und Konfiguration des HTTP-Proxys eignet sich die Deployment-Definition in diesem Helm-Chart.

  • Kommt in Meilenstein 2:
    • To-do: Zugang zur PEP-Datenbank
    • To-do: Zugang zur PDP-Datenbank (oder zum Authorization Server?)
    • To-do: Adresse des Resource Servers
    • To-do: Sidecar Container mit OpenTelemetry Collector