CloudLand 2023, Juni 2023, Andreas Zitzelsberger & Alex Krause
Robustes und sicheres Continuous Deployment braucht getestete Konfigurationen. Manuelle Review-Prozesse sind langsam und eklig. Werkzeuge gibt es viele, alle mit eigenen Konzepten und begrenzten Einsatzbereichen. Genauso schaut es bei Autorisierung und Anwendungskonfiguration aus. Es wäre doch schön, wenn es ein kleines, schlankes Werkzeug gäbe, um Policies überall einheitlich umzusetzen.Der Open Policy Agent (OPA) ist eine generische, cloud-native Open Source Policy Engine. OPA ermöglicht es, Policies einheitlich zu definieren und an vielen Stellen im Betriebs-, Deployment- und Entwicklungs-Stack umzusetzen, unter anderem für Autorisierung, Prüfung von Konfigurationen, Admission Control oder jeder anderen Art von Policies.
1. qaware.de
Eine Einführung in den
Open Policy Agent (OPA)
Andreas Zitzelsberger
andreas.zitzelsberger@qaware.de
Klassifizierung: Awesome
2. Eine Einführung in den Open Policy Agent (OPA)
Ihr braucht einen Laptop
2
https://t.ly/zWsh
QAware
3. Vorbrenner: Was ist eine Policy?
■ Eine Policy ist eine Funktion der Form f:Input -> Output
– Ohne Nebeneffekte
– Input / Output können strukturierte Daten sein.
■ Sinn: Eine Policy definiert Regelwissen formal.
■ Beispiele:
– Nur authentifizierte Benutzer dürfen den Dienst benutzen.
– Nutzer der Gruppe "Premium" können 8 requests/min stellen, andere nur 2.
– Zwischen 18:00 und 6:00 dürfen nur Mitglieder der "on-call"- Gruppe auf das System zugreifen
■ Policy ≠ Business Rule
■ Business Rule = Policy + Wirkung
3
QAware
4. Welche Probleme wollen wir lösen?
■ Einheitliche Policies,
– Die auf eine Art und Weise definiert
– und verwaltet werden.
■ Entkopplung: Policy-Entscheidung und Durchsetzung trennen. Policies raus aus den Anwendungen holen
■ Robuste und sichere Konfigurationen
– für Continuous Deployment
– und alles andere
■ Reviews automatisieren
■ Regeln für Regel-basierte Autorisierung (RuBAC) definieren
4
QAware
5. Was ist der Open Policy Agent?
5
■ Generische Policy-Engine
■ FOSS, Apache-2.0 Lizenz, CNCF Projekt
■ Wesentlicher Backer: Styra, baut Produkte auf OPA
auf (Styra DAS)
■ Ein Executable
■ Gebaut in Go
■ Betrieb zentral oder verteilt
■ Eigene Policy-Sprache "Rego"
■ Reichhaltige Standard Library
■ Eingebautes Testing, Benchmarking
■ Direkte Unterstützung von JWT, OAuth, OpenID
Connect
■ Schnittstellen zur Verwaltung
■ Breites Ökosystem
Quelle: OPA Dokumentation
QAware
6. Was bietet OPA zur Verwaltung?
■ OPA bietet eine Satz an Verwaltungs-Schnittstellen
■ Der OPA Agent ist immer der nutzende Part
■ Es gibt keine fertige Control Plane
■ Schnittstellen:
– Policy distribution (Bundles)
– Decision telemetry (Decision Logs)
– Agent telemetry (Status)
– Dynamic agent configuration (Discovery)
6
Quelle: OPA Dokumentation
QAware
7. Wie schaut das Ökosystem asus?
7
Beispiele
■ conftest - Standalone Validierung strukturierter
Daten
■ gatekeeper - Kubernetes Admission Control
■ Envoy, Istio - Proxy & Service Mesh Validierung
■ Spring Security - Autorisierung in der Anwendung
■ Pulumi CrossGuard - Cross-Plane
Infrastruktur-Policies
■ Kafka - Autorisierung, Message Filtering
https://www.openpolicyagent.org/docs/latest/ecosystem/
QAware
11. Aufgabe:
Alle Resourcen müssen Tags haben!
11
https://github.com/neiser/conftest-terraform-demo/tree/demo/01-tags
Tip für die erste Zeile:
resource = input.resource[type][name]
QAware
13. Hands-On Conftest mit Terraform
13
■ Terraform configuration kann mit
conftest geprüft werden
■ conftest überführt *.tf Datei als
strukturierte Daten in ein “input” Objekt
gegen das Rego Policies wirken
■ conftest bietet Tests für Policies an
(auch in Rego geschrieben)
https://www.conftest.dev/
QAware
14. Aufgabe:
Alle Resourcen müssen Tags haben!
14
https://github.com/neiser/conftest-terraform-demo/tree/demo/01-tags
Tip für die erste Zeile:
resource = input.resource[type][name]
QAware
17. Wir legen eine OAuth-Application auf GitHub an
17
1. Gehe zu
“Settings”
-> “Developer Settings”
-> “OAuth Apps”
2. “New OAuth App”, Ausfüllen, “Register application”
a. Homepage URL:
http://localhost:8080
b. Authorization callback URL:
http://localhost:8080/_renarde/security/github-success
3. “Generate a new client secret”
4. Secret und Client Id in .env-File kopieren
Siehe auch:
https://quarkus.io/guides/security-openid-connect-providers
QAware