TL;DR

Policy Frameworks (Kyverno/Gatekeeper) erzwingen Naming-Conventions, Label-Standards und Security-Baselines automatisiert
RBAC-Governance braucht ein klares Rollen-Modell mit regelmaessigen Access-Reviews -- nicht nur einmalige Konfiguration
Golden Paths und Templates beschleunigen Teams und stellen Compliance sicher, ohne die Entwicklerproduktivitaet zu bremsen
Resource Quotas pro Namespace verhindern, dass einzelne Teams die gesamte Cluster-Kapazitaet beanspruchen
Compliance-Dashboards machen den Governance-Status sichtbar und ersetzen manuelle Audit-Checklisten

Kubernetes Governance: Richtlinien und Compliance fuer grosse Organisationen

Wenn mehrere Teams auf gemeinsamen Kubernetes-Clustern arbeiten, reicht technische Konfiguration allein nicht aus. Ohne klare Governance entstehen Wildwuchs bei Namespaces, inkonsistente Labels, unkontrollierte Ressourcennutzung und Security-Luecken, die erst beim naechsten Audit auffallen.

Dieser Guide beschreibt, wie Plattform-Teams im Mittelstand eine Kubernetes-Governance aufbauen, die Compliance sicherstellt, ohne Teams auszubremsen.

Warum Kubernetes-Governance im Mittelstand wichtig ist

Ab einer bestimmten Groesse (3+ Teams, 2+ Cluster) treten typische Probleme auf:

Ohne Governance:
├── Namespace "test-jan-backup-2" existiert seit 14 Monaten
├── 40% der Deployments haben keine Resource Limits
├── 6 verschiedene Label-Schemata im selben Cluster
├── ServiceAccounts mit cluster-admin-Rechten
└── Audit-Vorbereitung dauert 3 Wochen

Mit Governance:
├── Naming-Conventions per Policy erzwungen
├── Pflicht-Labels automatisch validiert
├── RBAC nach Least-Privilege-Prinzip
├── Resource Quotas pro Team-Namespace
└── Compliance-Dashboard zeigt Status in Echtzeit

Policy Framework: Kyverno als Governance-Engine

Kyverno hat sich als Standard fuer Kubernetes Policy Management etabliert, weil es native YAML-Policies verwendet und keine eigene Sprache erfordert.

Naming-Conventions erzwingen

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: enforce-namespace-naming
spec:
  validationFailureAction: Enforce
  background: true
  rules:
  - name: validate-namespace-name
    match:
      any:
      - resources:
          kinds:
          - Namespace
    exclude:
      any:
      - resources:
          namespaces:
          - kube-system
          - kube-public
          - monitoring
    validate:
      message: >-
        Namespace-Name "{{ request.object.metadata.name }}" entspricht nicht
        der Konvention. Erlaubtes Format: teamname-env-service
        (z.B. commerce-prod-api, logistics-staging-worker)
      pattern:
        metadata:
          name: "?*-?*-?*"

Pflicht-Labels validieren

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-governance-labels
spec:
  validationFailureAction: Enforce
  background: true
  rules:
  - name: check-required-labels
    match:
      any:
      - resources:
          kinds:
          - Deployment
          - StatefulSet
          - DaemonSet
    validate:
      message: >-
        Pflicht-Labels fehlen. Jedes Deployment braucht:
        app.kubernetes.io/name, team, cost-center, environment
      pattern:
        metadata:
          labels:
            app.kubernetes.io/name: "?*"
            team: "?*"
            cost-center: "?*"
            environment: "production | staging | development"

Fuer eine detaillierte Einfuehrung in Kyverno-Policies empfehlen wir unseren Kyverno-Praxisguide.

RBAC-Governance: Zugriffskontrolle skalierbar gestalten

Ein klares Rollen-Modell ist die Basis fuer RBAC-Governance. Teams bekommen volle Kontrolle in ihren Namespaces, aber keinen Zugriff auf Cluster-weite Ressourcen:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: team-namespace-admin
rules:
- apiGroups: ["", "apps", "batch", "networking.k8s.io"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: [""]
  resources: ["resourcequotas", "limitranges"]
  verbs: ["get", "list"]  # Lesen ja, aendern nein

RoleBinding per Namespace automatisieren

# Kyverno: Automatisch RoleBindings erstellen wenn ein Namespace angelegt wird
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: generate-rbac-for-namespace
spec:
  rules:
  - name: create-team-rolebinding
    match:
      any:
      - resources:
          kinds:
          - Namespace
    generate:
      synchronize: true
      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      name: team-admin-binding
      namespace: "{{request.object.metadata.name}}"
      data:
        roleRef:
          apiGroup: rbac.authorization.k8s.io
          kind: ClusterRole
          name: team-namespace-admin
        subjects:
        - apiGroup: rbac.authorization.k8s.io
          kind: Group
          name: "team-{{request.object.metadata.labels.team}}"

Regelmaessige Access-Reviews

# RBAC-Audit: Alle ClusterRoleBindings mit cluster-admin auflisten
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") |
  .metadata.name + " -> " +
  (.subjects[]? | .kind + "/" + .name)'

# Service Accounts mit weitreichenden Rechten finden
kubectl auth can-i --list --as=system:serviceaccount:default:default

Einen umfassenden Guide zu RBAC-Strategien finden Sie in unserem Artikel zu RBAC fuer Enterprise-Umgebungen.

Resource Quotas und LimitRanges pro Team

# ResourceQuota und LimitRange fuer ein Team-Namespace
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: commerce-prod-api
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi
    limits.cpu: "16"
    limits.memory: 32Gi
    pods: "50"
    persistentvolumeclaims: "20"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: container-limits
  namespace: commerce-prod-api
spec:
  limits:
  - type: Container
    default:
      cpu: 200m
      memory: 256Mi
    defaultRequest:
      cpu: 100m
      memory: 128Mi
    max:
      cpu: "2"
      memory: 4Gi

Quota-Monitoring per PrometheusRule

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: quota-alerts
  namespace: monitoring
spec:
  groups:
  - name: resource-quota-alerts
    rules:
    - alert: NamespaceQuotaNearLimit
      expr: |
        kube_resourcequota{type="used"} /
        kube_resourcequota{type="hard"} > 0.85
      for: 15m
      labels:
        severity: warning
      annotations:
        summary: "Namespace {{ $labels.namespace }} nutzt ueber 85% der {{ $labels.resource }}-Quota"

Golden Paths und Templates

Golden Paths sind vordefinierte, gepruefte Pfade fuer haeufige Aufgaben. Sie geben Teams eine schnelle, compliant-konforme Loesung:

# golden-path-deployment/values.yaml
team: ""           # Pflichtfeld
costCenter: ""     # Pflichtfeld
environment: ""    # production | staging | development

replicaCount: 2
image:
  repository: ""
  tag: ""

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 512Mi

securityContext:
  runAsNonRoot: true
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop:
    - ALL

# Neues Deployment mit Golden Path erstellen
helm install my-service company-charts/golden-path \
  --set team=commerce \
  --set costCenter=CC-4711 \
  --set environment=production \
  --set image.repository=registry.company.io/order-service \
  --set image.tag=v2.3.1

Audit-Trail und Change Management

# Audit-Policy: Relevante Aktionen protokollieren
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  resources:
  - group: ""
    resources: ["secrets", "configmaps"]
  - group: "rbac.authorization.k8s.io"
    resources: ["clusterroles", "clusterrolebindings", "roles", "rolebindings"]
- level: Metadata
  resources:
  - group: "apps"
    resources: ["deployments", "statefulsets", "daemonsets"]
- level: None
  resources:
  - group: ""
    resources: ["events", "endpoints"]

Governance-konformer Aenderungsprozess

1. Entwickler erstellt PR mit Kubernetes-Manifesten
2. CI-Pipeline prueft:
   ├── kubeconform: YAML-Validierung
   ├── kyverno test: Policy-Compliance
   ├── trivy: Security-Scan
   └── kubecost predict: Kosten-Schaetzung
3. Platform-Team reviewed Infrastruktur-Aenderungen
4. GitOps (ArgoCD) synchronisiert nach Merge
5. Admission Controller validiert nochmals beim Apply
6. Audit-Log dokumentiert alle Aenderungen

Wie Policy-Automatisierung in der Praxis funktioniert, beschreibt unser Artikel zur Policy-Automatisierung.

Compliance-Dashboard aufbauen

# ServiceMonitor fuer Kyverno-Metriken
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: kyverno-metrics
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: kyverno
  endpoints:
  - port: metrics-port
    interval: 30s
    path: /metrics

Relevante Metriken fuer das Governance-Dashboard:

Compliance-Score:
├── kyverno_policy_results_total{rule_result="pass"} / total * 100

Resource-Governance:
├── Namespaces ohne ResourceQuota: 0
├── Deployments ohne Resource Limits: 0
└── Pods ohne Security Context: 0

Governance-Rollout-Plan

Woche 1-2: Bestandsaufnahme
├── Alle Namespaces und deren Ownership dokumentieren
├── RBAC-Audit durchfuehren
└── Bestehende Labels und Naming-Conventions erfassen

Woche 3-4: Standards definieren
├── Naming-Convention fuer Namespaces
├── Pflicht-Label-Schema
└── RBAC-Rollen-Modell

Woche 5-8: Policies im Audit-Modus ausrollen
├── Kyverno installieren
├── Policies als Audit (nicht Enforce) deployen
└── Teams ueber Violations informieren

Woche 9-12: Enforce-Modus und Dashboards
├── Policies schrittweise auf Enforce stellen
├── Compliance-Dashboard aufbauen
└── Golden Paths bereitstellen

Checkliste: Governance-Grundlagen

Naming-Convention fuer Namespaces definiert und dokumentiert
Pflicht-Labels festgelegt (team, cost-center, environment)
Kyverno/Gatekeeper installiert mit Audit-Modus
RBAC nach Least-Privilege-Prinzip konfiguriert
ResourceQuotas in allen Team-Namespaces
LimitRanges mit sinnvollen Defaults
Audit-Logging aktiviert
Compliance-Dashboard in Grafana
Quartalsweise Access-Reviews geplant

Wie Compliance-Automatisierung den Governance-Prozess unterstuetzt, erfahren Sie in unserem Artikel zur Compliance-Automatisierung.

Fazit

Kubernetes Governance ist kein Buerokratie-Projekt, sondern eine Investition in Skalierbarkeit. Der wichtigste Grundsatz: Governance muss automatisiert sein. Richtlinien, die nur in einem Wiki-Dokument stehen, werden ignoriert. Richtlinien, die als Kyverno-Policies im Cluster laufen, werden eingehalten.

Sie moechten Kubernetes Governance in Ihrer Organisation einfuehren? Wir helfen bei der Definition von Standards, der Implementierung von Policy Frameworks und dem Aufbau eines Platform-Team-Modells. Kontaktieren Sie uns fuer eine individuelle Beratung.

Kubernetes Governance: Richtlinien für Multi-Team-Cluster