---
title: "IT-Grundschutz trifft Kubernetes: Praxisnahe Umsetzung sicherheitsrelevanter Anforderungen"
weight: 3
tags:
 - security
 - compliance
---

> The talk is in german, so the notes will be a fun™ mix of german and english.

<!-- {{% button href="https://youtu.be/rkteV6Mzjfs" style="warning" icon="video" %}}Watch talk on YouTube{{% /button %}} -->
<!-- {{% button href="https://docs.google.com/presentation/d/1nEK0CVC_yQgIDqwsdh-PRihB6dc9RyT-" style="tip" icon="person-chalkboard" %}}Slides{{% /button %}} -->

Intro statement: "Ich weis nicht, ob wir hier gleich die Therapiegruppe eröffnen sollen"
Mantra: "Papier ist belastbar"
Von der HPA: Hamburg Port Authority

## Grundschutz Kompakt

- Warum:
  - Weil wir kritische Infra sind (oder so ähnlich)
  - Weil wir Zulieferer für kritische Infa sind
- Wie: Naja les halt einfach mal die BSI Anforderungen

## Herausforderungen

- Das liest sich alles immer echt träge
- APP4.4 für diesen Talk: Planung der Automatisierung mit CI/CD (Wenn du CI/CD Machtst darf das nur nach Planung erfolgen inkl Lifecycle und Teardown)

## Theorie -> Praxis

### Lösungsvorschlag für TODO:

1. IaC + CI
2. K8S als Orchestrator mit Hosted Control Plane (Cluster of Clusters)
3. Service Katalog (Helm Charts)
4. Rollout von neuen Clustern mit Argo und Helm
5. Externer Vault für Secrets, States und Certs

Multiple Node Types pro Cluster:

- Infra-Nodes: Zentral ausgerollte Services
- App-Nodes: Kundenanwendungen

TODO: Lösungsvorschlag Slide klauen

### Lösungsvorschlag für APP 4.4.A.7 Separierung der Netze

- Netztypen
  - Physich
  - Interne Overlay Netze: Pod, Service
- Idee: Netowrk Policies nutzen (Also außer flannel)
- Macht immer security happy: Deny all policy -> Enforcement: Kyverno
- Herausforderung: Projekte haben verschiedene Backends/Dienste und dann wird die DX eher so mittel
- Anderer Ansatz: Otterize zum generieren von Policies
  - Hat einen Network-Mapper, der automatisch alle Verbindungen erkennt
  - Generiert Intents aus dem beobachteten traffic
  - Generiert Policies aus den intents
  - Cool: Intents können auf DNS gehen und otterize löst dann für die policy die ips auf

### Lösungsvorschlag 4.4.A21 Regelmäßiger Neustart von Pods

> Kein Pod sollte länger als 24h laufen
> Die verfügbarkeit der Pods sollte sichergestellt werden

- Idee: Eigener Operator oder CronJob
- Aber: Kyverno kann das auch über ne annotation an namespace und/oder deployment

## Fazit

- IT-Grundschutz ist kein selbstzweck, sondern soll sicherheit im cluster sichtbar und messbar machen
- Die CNCF hat Projekte, die uns da weiterhelfen können

## Sonstiges

- Alles nicht security relevante is open source wegen öffentliche anstalt und so
- Die Freunde haben einen blog und veröffentlichen da schritt für schritt lösungsvorschläge