Policy as Code¶

Policy as Code ermöglicht die automatische Durchsetzung von Sicherheitsrichtlinien und Best Practices in der ayedo Software Delivery Plattform mittels Kyverno.

Relevante Vorschriften¶

Obwohl "Policy-as-Code" nicht explizit in Regulierungen genannt wird, wird die technische Durchsetzung von Richtlinien als wichtige Strategie angesehen, um Compliance-Verletzungen zu reduzieren und den Compliance-Aufwand zu minimieren.

GDPR Artikel 32 fordert:

Unter Berücksichtigung des Stands der Technik [...] treffen der Verantwortliche und der Auftragsverarbeiter [...] geeignete technische und organisatorische Maßnahmen [...] sowie ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen zur Gewährleistung der Sicherheit der Verarbeitung. [Hervorhebung hinzugefügt]

BSI IT-Grundschutz¶

APP.4.4.A13: Zugriffsschutz

Der Zugriff auf die Management-Funktionen der Control Plane SOLLTE beschränkt werden. Die Ressourcen der Workload-Cluster SOLLTEN ausschließlich aus entsprechenden Namespaces zugewiesen werden. [Hervorhebung hinzugefügt]

APP.4.4.A14: Verwendung von Admission Controllern

Admission Controller SOLLTEN aktiviert werden. Die Funktion der Admission Controller SOLLTE über Richtlinien (engl. Policies) geeignet konfiguriert werden.

Mapping zu Norm-Controls¶

ISO 27001 Annex A 5.36 Compliance with Policies, Rules and Standards¶

Die Einhaltung der Informationssicherheitspolitik, themenspezifischen Richtlinien und Standards der Organisation sowie alle geltenden Sicherheitsanforderungen MUSS regelmäßig überprüft werden.

Implementierung in der ayedo SDP:

✅ Kyverno Policies: Automatische Durchsetzung von Sicherheitsrichtlinien
✅ Policy Violations Dashboard: Grafana-Dashboard zur Überwachung
✅ Audit Mode: Policies können im Audit-Modus laufen (Warn statt Block)
✅ Reporting: Automatische Compliance-Reports

ISO 27001 Annex A 5.1 Policies for Information Security¶

Informationssicherheitspolitiken MÜSSEN definiert, von der Führung genehmigt, veröffentlicht, kommuniziert und allen relevanten Mitarbeitern und externen Parteien zur Kenntnis gebracht werden.

Implementierung in der ayedo SDP:

✅ Policies als Code in Git (Infrastructure as Code)
✅ Review-Prozesse für Policy-Änderungen
✅ Automatische Dokumentation der aktiven Policies

Policy as Code Dashboard¶

Die ayedo SDP stellt ein Policy as Code Dashboard in Grafana bereit, das einen Überblick über Policy-Verstöße und -Einhaltung bietet:

Dashboard-Inhalte:

Policy Violations: Aktuelle Verstöße gegen Policies
Blocked Requests: Anzahl der durch Policies blockierten Requests
Audit Mode Warnings: Policies im Audit-Modus
Policy by Type: Übersicht nach Policy-Kategorie
Compliance Rate: Prozentsatz der Policy-Einhaltung

Zugriff auf das Dashboard:

Das Dashboard ist über Grafana verfügbar: Kyverno Policy Reports

Kyverno Policies¶

Die ayedo SDP nutzt Kyverno für Policy-Enforcement.

Vorteile von Kyverno¶

Kubernetes-nativ: YAML-basierte Policy-Definition
Einfache Syntax: Keine spezielle Policy-Sprache notwendig
Admission Control: Validierung, Mutation und Generierung von Ressourcen
Audit Mode: Policies können im Warn-Modus laufen
Policy Reports: Automatische Reports über Policy-Status

Policy-Modi¶

Enforce Mode (Standard)¶

Policies im Enforce Mode blockieren nicht-konforme Ressourcen:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-labels
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-for-labels
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Label 'app' is required"
        pattern:
          metadata:
            labels:
              app: "?*"

Audit Mode¶

Policies im Audit Mode loggen Verstöße, blockieren aber nicht:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-labels
spec:
  validationFailureAction: Audit  # Nur warnen, nicht blockieren
  rules:
    # ...

Kategorien von Policies¶

Security Policies¶

Verbot privilegierter Container¶

Verhindert, dass Container mit Root-Rechten laufen:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-containers
spec:
  validationFailureAction: Enforce
  rules:
    - name: privileged-containers
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Privileged containers are not allowed"
        pattern:
          spec:
            containers:
              - securityContext:
                  privileged: false

Compliance: ISO 27001 A.8.30, BSI APP.4.4.A10

Network Policies erforderlich¶

Erzwingt, dass jeder Namespace NetworkPolicies definiert hat:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-networkpolicies
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-networkpolicy-exists
      match:
        any:
          - resources:
              kinds:
                - Namespace
      validate:
        message: "NetworkPolicy is required in each namespace"
        # Policy-Logik...

Compliance: ISO 27001 A.8.20, BSI APP.4.4.A19

Trusted Container Registries¶

Erlaubt nur Images aus vertrauenswürdigen Registries:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-image-registries
spec:
  validationFailureAction: Enforce
  rules:
    - name: validate-registries
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Images must be from harbor.example.com"
        pattern:
          spec:
            containers:
              - image: "harbor.example.com/*"

Compliance: ISO 27001 A.8.19, BSI APP.4.4.A8

Reliability Policies¶

Resource Requests erforderlich¶

Erzwingt, dass alle Pods CPU/Memory Requests definieren:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-requests-limits
spec:
  validationFailureAction: Enforce
  rules:
    - name: validate-resources
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "CPU and memory resource requests are required"
        pattern:
          spec:
            containers:
              - resources:
                  requests:
                    memory: "?*"
                    cpu: "?*"

Compliance: ISO 27001 A.8.6 (Kapazitätsplanung)

Minimum Replicas¶

Verhindert Single-Pod-Deployments in Production:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: minimum-replicas
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-replicas
      match:
        any:
          - resources:
              kinds:
                - Deployment
              namespaces:
                - production
      validate:
        message: "Minimum 2 replicas required in production"
        pattern:
          spec:
            replicas: ">=2"

Compliance: ISO 27001 A.8.6, GDPR Art. 32 (Availability)

PodDisruptionBudget erforderlich¶

Erzwingt PodDisruptionBudgets für HA-Deployments:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-pdb
spec:
  validationFailureAction: Audit  # Nur Warnung
  rules:
    - name: check-pdb
      match:
        any:
          - resources:
              kinds:
                - Deployment
      validate:
        message: "PodDisruptionBudget recommended for HA"
        # ...

Compliance: ISO 27001 A.8.6, GDPR Art. 32 (Resilience)

Compliance Policies¶

Image Tag nicht "latest"¶

Verhindert Nutzung des "latest" Tags:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
spec:
  validationFailureAction: Enforce
  rules:
    - name: validate-image-tag
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Image tag 'latest' is not allowed"
        pattern:
          spec:
            containers:
              - image: "!*:latest"

Compliance: ISO 27001 A.8.19 (Change Management)

Backup Annotations¶

Erzwingt Backup-Annotations für PVCs:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-backup-annotations
spec:
  validationFailureAction: Audit
  rules:
    - name: check-backup-annotation
      match:
        any:
          - resources:
              kinds:
                - PersistentVolumeClaim
      validate:
        message: "Backup annotation is recommended"
        pattern:
          metadata:
            annotations:
              backup.velero.io/backup-volumes: "?*"

Compliance: ISO 27001 A.8.13 (Information Backup)

Policy Lifecycle¶

1. Policy Design¶

Risikoanalyse: Welche Risiken soll die Policy adressieren?
Compliance Mapping: Welche Norm-Controls werden erfüllt?
Impact Assessment: Welche Auswirkungen hat die Policy auf Entwickler?

2. Policy Implementation¶

YAML Definition: Policy als Kyverno ClusterPolicy oder Policy
Git Commit: Policy in Git-Repository einchecken
Review: Code Review durch Security/Compliance Team

3. Policy Testing¶

Audit Mode: Policy zunächst im Audit-Modus deployen
Monitoring: Policy Violations Dashboard beobachten
Developer Feedback: Feedback von Anwendungsentwickler einholen

4. Policy Enforcement¶

Enforce Mode: Policy auf Enforce umstellen
Documentation: Policy in Dokumentation aufnehmen
Communication: Entwickler über neue Policy informieren

5. Policy Review¶

Quarterly Review: Vierteljährliche Überprüfung aller Policies
Incident Analysis: Policy-Anpassung nach Security Incidents
Continuous Improvement: Policies basierend auf Feedback anpassen

Handling Non-Compliance¶

Für Plattform Administratoren¶

Wenn eine Policy wiederholt verletzt wird:

Policy überprüfen: Ist die Policy korrekt definiert?
Developer kontaktieren: Warum tritt die Verletzung auf?
Risk Assessment: Ist die Policy zu strikt?
Policy anpassen: Falls notwendig, Policy lockern oder Ausnahmen definieren

Für Anwendungsentwickler¶

Wenn eine Policy Ihr Deployment blockiert:

Policy verstehen: Lesen Sie die Fehlermeldung
Dokumentation: Konsultieren Sie die Policy-Dokumentation
Anpassung: Passen Sie Ihr Deployment an die Policy an
Ausnahme beantragen: Falls notwendig, kontaktieren Sie das Platform-Team

Policy Exceptions¶

In begründeten Fällen können Policy Exceptions gewährt werden:

apiVersion: kyverno.io/v1
kind: PolicyException
metadata:
  name: allow-privileged-for-gpu
  namespace: ml-workloads
spec:
  exceptions:
    - policyName: disallow-privileged-containers
      ruleNames:
        - privileged-containers
  match:
    any:
      - resources:
          namespaces:
            - ml-workloads
          names:
            - gpu-training-*

Wichtig: Exceptions müssen dokumentiert und regelmäßig überprüft werden!

Best Practices¶

Für Plattform Administratoren¶

Audit Mode First: Neue Policies zunächst im Audit-Modus deployen
Gradual Rollout: Policies schrittweise auf Namespaces ausrollen
Documentation: Policies gut dokumentieren
Developer Communication: Proaktiv mit Entwicklern kommunizieren
Regular Reviews: Quartalsweise Policy-Reviews

Für Anwendungsentwickler¶

Policy Awareness: Machen Sie sich mit Policies vertraut
Early Testing: Testen Sie Deployments frühzeitig
Resource Requests: Definieren Sie immer CPU/Memory Requests
Security Best Practices: Folgen Sie Security Best Practices
Feedback: Geben Sie Feedback zu Policies

Monitoring und Alerting¶

VictoriaMetrics Alerts¶

Automatische Alerts bei Policy-Verletzungen:

- alert: HighPolicyViolationRate
  expr: kyverno_policy_results_total{result="fail"} > 10
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "High rate of policy violations"
    description: "More than 10 policy violations in 5 minutes"

Grafana Dashboard¶

Das Kyverno Policy Reports Dashboard zeigt:

Policy Violation Trends
Top Violated Policies
Namespace-wise Compliance
Policy Enforcement vs. Audit Mode

Compliance-Checkliste¶

✅ Kyverno installiert und konfiguriert
✅ Basis-Policies deployed (Security, Reliability)
✅ Policy as Code Dashboard in Grafana verfügbar
✅ Alerting bei Policy-Verletzungen konfiguriert
✅ Policy-Dokumentation erstellt
✅ Developer-Training zu Policies durchgeführt
✅ Quartalsweise Policy-Reviews geplant
✅ Policy Exception-Prozess definiert

Weitere Informationen¶

Support¶

Bei Fragen zu Policy as Code:

E-Mail: support@ayedo.de
Website: ayedo.de

Policy as Code¶

Relevante Vorschriften¶

GDPR Art. 32¶

BSI IT-Grundschutz¶

Mapping zu Norm-Controls¶

ISO 27001 Annex A 5.36 Compliance with Policies, Rules and Standards¶

ISO 27001 Annex A 5.1 Policies for Information Security¶

Policy as Code Dashboard¶

Kyverno Policies¶

Vorteile von Kyverno¶

Policy-Modi¶

Enforce Mode (Standard)¶

Audit Mode¶

Kategorien von Policies¶

Security Policies¶

Verbot privilegierter Container¶

Network Policies erforderlich¶

Trusted Container Registries¶

Reliability Policies¶

Resource Requests erforderlich¶

Minimum Replicas¶

PodDisruptionBudget erforderlich¶

Compliance Policies¶

Image Tag nicht "latest"¶

Backup Annotations¶

Policy Lifecycle¶

1. Policy Design¶

2. Policy Implementation¶

3. Policy Testing¶

4. Policy Enforcement¶

5. Policy Review¶

Handling Non-Compliance¶

Für Plattform Administratoren¶

Für Anwendungsentwickler¶

Policy Exceptions¶

Best Practices¶

Für Plattform Administratoren¶

Für Anwendungsentwickler¶

Monitoring und Alerting¶

VictoriaMetrics Alerts¶

Grafana Dashboard¶

Compliance-Checkliste¶

Weitere Informationen¶

Support¶