docs(day1): Added talk and first lesson learned
This commit is contained in:
parent
5eb7104d3f
commit
cada98e724
77
content/day1/03_grundschutz.md
Normal file
77
content/day1/03_grundschutz.md
Normal file
@ -0,0 +1,77 @@
|
||||
---
|
||||
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
|
@ -4,4 +4,6 @@ title: Lessons Learned
|
||||
weight: 3
|
||||
---
|
||||
|
||||
TODO:
|
||||
## Mal anschauen
|
||||
|
||||
- Otterize für Netzwrok policies
|
Loading…
x
Reference in New Issue
Block a user