Guide: KI-Agenten auf Kubernetes mit Defense in Depth einschließen

Guide: MinIO als S3-kompatibles Backup-Ziel

Selbst gehosteter, S3-kompatibler Objektspeicher für Backups: MinIO hinter einem Nginx-Proxy, dazu ein rclone-basierter Backup-Agent mit versionierten Buckets. Ihre Offsite-Backups ohne Cloud-Rechnung

Guide: PostgreSQL + Redis als Produktionsfundament

Die zwei Services, die fast jede Anwendung braucht — getunt statt default: PostgreSQL produktionskonfiguriert (Shared Buffers, WAL-Kompression), Redis mit AOF- und RDB-Persistenz sowie ein geplanter B

Ein KI-Agent in Ihrem Cluster ist eine neue Art von Principal, und das Modell, das ihn ausführt, ist keine Sicherheitsgrenze. Dieser Guide ist die Referenzarchitektur, um ihn trotzdem einzuschließen.

Was das ist

LLM-Agenten lesen Telemetrie, rufen Tools auf, schreiben und führen Code aus und verändern den Clusterzustand. Damit kollabiert eine Grenze, auf die Cloud-Native-Sicherheit aufbaut: die Grenze zwischen Daten und Kontrolle. Eine Log-Zeile aus einer kompromittierten Workload, ein Annotation auf einer Ressource, ein Feld in einem Ticket oder eine Tool-Beschreibung von einem fremden MCP-Server ist Inhalt, den der Agent lediglich liest — und daraus kann ein Befehl werden, den der Agent mit eigenen Credentials ausführt.

Die nützliche Konsequenz ist eine Designregel: Gehen Sie davon aus, dass der Agent durch Prompt-Injection vollständig kompromittiert ist, und bauen Sie jede Zusicherung so, dass sie trotzdem hält. Ein Deployment-Guide mit funktionierenden Beispielen — kein herunterladbares Produkt. Die Manifeste unten sind die Referenzarchitektur, gekürzt auf die Teile, auf die es ankommt. Das Framework folgt dem arXiv-Paper "Containing the Autonomous Operator", das für das Threat Model eine Lektüre wert ist.

Deployment-Beispiel

RBAC beantwortet, welche Verben auf welchen Ressourcen in welchem Namespace. Es kann aber keine Bedingungen auf Objektinhalt ausdrücken — es kann Skalierung auf Null nicht verbieten, während Skalierung erlaubt ist, und Änderungen in Control-Plane-Namespaces nicht verbieten, während Änderungen anderswo erlaubt sind. Eine ValidatingAdmissionPolicy schließt diese Lücke mit In-Process-CEL, per matchConditions auf Agent-Identitäten eingeschränkt.

Weil der API-Server sie durchsetzt, gilt diese Policy auch dann, wenn der Agent das Gateway umgeht und den API-Server direkt mit einem gestohlenen Token anspricht. Genau diese Eigenschaft kann ein reiner Tool-Layer nicht liefern.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: agent-guardrails
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: ["apps"]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE", "DELETE"]
        resources: ["deployments", "deployments/scale", "statefulsets", "statefulsets/scale"]
  matchConditions:
    - name: only-agent-identities
      expression: "request.userInfo.username.startsWith('system:serviceaccount:agents:')"
  validations:
    - expression: "!request.namespace.startsWith('kube-') && request.namespace != 'agents'"
      message: "agents may not modify control-plane or agent namespaces"
    - expression: "request.operation != 'DELETE'"
      message: "agents may not delete workloads; open a GitOps PR instead"
    - expression: "request.operation == 'DELETE' || !has(object.spec.replicas) || object.spec.replicas > 0"
      message: "agents may not scale workloads to zero"
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: agent-guardrails-binding
spec:
  policyName: agent-guardrails
  validationActions: ["Deny", "Audit"]

Wesentliche Konfiguration

Zwei weitere Artefakte tragen den Großteil der verbleibenden Last. Egress: Agent-Namespaces starten von Default-Deny, und weil externe Dienste über Namen statt über Adressen adressiert werden, reicht eine IP-basierte NetworkPolicy nicht — Sie brauchen FQDN-fähige Policy. Sandboxes: Generierter Code läuft in kernel-isolierten Pods ohne gemountetes Token und ganz ohne Egress.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: agent-egress
  namespace: agents
spec:
  endpointSelector:
    matchLabels: { app.kubernetes.io/component: agent }
  egress:
    - toEndpoints:
        - matchLabels:
            k8s:io.kubernetes.pod.namespace: kube-system
            k8s-app: kube-dns
      toPorts:
        - ports: [{ port: "53", protocol: ANY }]
          rules:
            dns: [{ matchPattern: "*" }]
    - toFQDNs:
        - matchName: bedrock-runtime.us-west-2.amazonaws.com
      toPorts:
        - ports: [{ port: "443", protocol: TCP }]

apiVersion: agents.x-k8s.io/v1alpha1
kind: Sandbox
metadata:
  name: session-7f3a
  namespace: agent-sandboxes
spec:
  podTemplate:
    spec:
      runtimeClassName: gvisor
      automountServiceAccountToken: false
      securityContext:
        runAsNonRoot: true
        seccompProfile: { type: RuntimeDefault }
      containers:
        - name: runtime
          image: registry.internal/sandbox/python@sha256:...
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities: { drop: ["ALL"] }
          resources:
            limits: { cpu: "1", memory: 1Gi, ephemeral-storage: 512Mi }

Produktions-Checkliste

• Jeder Agent und jeder Tool-Server läuft unter einer eigenen ServiceAccount — der Default-Account wird nie verwendet
• automountServiceAccountToken: false auf jedem Pod, der den Kubernetes-API-Server nicht anspricht
• Agents erhalten namespaced Roles, niemals ClusterRoles mit Write-Verben
• pods/exec, secrets, serviceaccounts/token und RBAC-Objekte sind von Agent-Rollen ausgeschlossen
• Agent- und Sandbox-Namespaces erzwingen den restricted Pod Security Standard
• Egress ist Default-Deny, und die FQDN-Allowlist nennt nur den Modell-Endpunkt
• Das Gateway vermittelt jeden Tool-Aufruf — es gibt keinen unmittelbaren Weg vom Agenten zum API-Server
• Secrets werden serverseitig von den Tool-Servern geholt und nie in Tool-Output zurückgegeben
• Ein geübter Kill-Switch existiert: Identität widerrufen, auf Null skalieren, isolieren, Sessions invalidieren
• Budgets pro Agent für Tool-Aufrufe, Mutationen, Modell-Tokens und Kosten

Die sieben Schichten

• L1 Identität — ServiceAccount pro Agent, audience-gebundene kurzlebige Tokens, Cloud Workload Identity statt statischer Keys
• L2 Autorisierung und Admission — gescopte RBAC, ValidatingAdmissionPolicy, Pod Security Standards
• L3 Ausführungsisolation — das SIG-Apps-Agent-Sandbox-Projekt, gVisor oder Kata über RuntimeClass, ephemer pro Session
• L4 Netzwerk — Default-Deny für Ingress und Egress, FQDN-Allowlist, mTLS zwischen Gateway, Tool-Servern und Agenten
• L5 Tool-Mediation — das Agent-Gateway, Policy über Tool und Argumente, signierte Tool-Registry, Rate Limits
• L6 Daten und Secrets — serverseitiges Secret-Fetching, Redaction an der Quelle, Memory-Provenance
• L7 Runtime-Erkennung und Reaktion — eBPF-Enforcement, Audit-Log-Analytik, Kill-Switch

Schicht G liegt quer darüber: menschliche Freigabe, graduierte Autonomie, Budgets und Circuit Breaker. Die Reihenfolge zählt — das Gateway kann früher und mit reichhaltigerem Kontext blockieren, aber nur Admission Control und das CNI lassen sich von einem kompromittierten Agenten nicht umgehen.

Die tödliche Kombination

Ernsthafter Schaden braucht drei Eigenschaften zugleich: Kontakt mit unvertrauten Input, Zugriff auf sensible Daten oder privilegierte Aktionen und die Fähigkeit, nach außen zu kommunizieren oder Zustand zu verändern. Entfernen Sie eine davon für eine Session, ist der Schaden einer gelungenen Injection scharf begrenzt.

Kubernetes ist ungewöhnlich gut darin, das strukturell durchzusetzen, denn jede Eigenschaft lässt sich auf eine steuerbare Ressource abbilden — Inhaltsquellen auf Tool-Autorisierung, sensibler Zugriff auf RBAC und Secret-Platzierung, externe Kommunikation auf Egress-Policy. Die stärkste Variante trennt die Komponente, die unvertraute Daten liest, von der Komponente, die privilegierte Aktionen plant: ein isolierter Reader-Agent mit Read-only-Tools und ohne Egress, und ein Planner-Agent, der niemals rohe, unvertraute Inhalte aufnimmt.

Autonomie-Stufen

Tool tier            Dev        Staging    Production
Observe (read)       auto       auto       auto
Propose (PR, dry-run)auto       auto       auto (human merges)
Act (mutate)         auto       notify     approval
Destructive (delete) approval   approval   denied by L2

Eine Freigabe ist an genau einen Aufruf gebunden, per Hash aus Tool und Argumenten, und läuft ab — sie lässt sich also nicht für eine andere Aktion wiederverwenden. Wo eine Mutation erlaubt ist, leiten Sie sie bevorzugt über einen GitOps-Pull-Request: Argo CD appliziert sie mit Historie und Rollback, und ein Mensch liest den Diff.

FAQ

Warum reicht es nicht, sich auf das Modell zu verlassen? Weil Alignment, System-Prompts und Input-Klassifikatoren die Wahrscheinlichkeit für Fehlverhalten senken, aber keine Garantie bieten — und ihre Fehlermuster adversariell auffindbar sind. Das Modell ist keine Sicherheitsgrenze, deshalb hält jede Kontrolle hier auch dann, wenn der Agent durch Prompt-Injection vollständig kompromittiert ist. Das Modell ist Hygiene, die Schichten sind die Grenze.

Brauche ich alle sieben Schichten, oder kann ich mit Admission Control starten? Admission Control im API-Server ist die wertvollste einzelne Schicht, weil sie auch dann greift, wenn der Agent das Gateway mit einem gestohlenen Token umgeht. Sie begrenzt aber nur den Objektinhalt. Beginnen Sie dort, ergänzen Sie Workload Identity, damit Anfragen zuordenbar bleiben, dann Default-Deny-Egress, dann Tool-Mediation. Lassen Sie nichts aus, das entscheidet, was der Agent erreichen darf.

Warum reicht eine IP-basierte NetworkPolicy für Egress-Control nicht? Externe Dienste werden über Namen adressiert, und ihre Adressen ändern sich. Eine IP-Allowlist bricht also still, sobald ein Anbieter einen Endpunkt verschiebt. FQDN-fähige Policies sind nötig: Cilium auf selbst verwalteten Clustern, FQDNNetworkPolicy auf GKE mit Dataplane V2, ACNS-FQDN-Filtering auf AKS mit Azure CNI. Auf EKS ist VPC CNI nicht FQDN-fähig — dort brauchen Sie Cilium oder einen erzwungenen Egress-Proxy.

Was bricht zuerst, wenn ein Agent in Produktion Störungen behebt? Endlosschleifen, keine Angriffe. Ein Agent, der ein Deployment neu startet, dessen Fehler von einer downstream-Datenbank kommen, startet es immer wieder neu und verschlimmert die Störung. Deshalb braucht Governance Budgets pro Objekt, einen Circuit Breaker, der nach wiederholt fehlgeschlagenen Behebungen eskaliert, und freigabepflichtige Mutationen in Produktion. Der Kill-Switch muss geübt sein, bevor Sie ihn brauchen.

Für den Cluster, in dem das läuft, beginnen Sie mit dem k3s-Produktionsstack und dem Observability-Stack — Audit-Log-Baselines in Schicht 7 brauchen zuerst Metriken. Wenn der Agent außerdem einen Modell-Endpunkt aufruft, ist der Self-hosted-AI-Stack der Ort, an dem sich die FQDN-Allowlist bezahlt macht.

Ein Guide, kein Produkt. Diese Seite ist Deployment-Dokumentation mit funktionierenden Beispielen — es gibt kein Zip, keinen Download, keinen Support-Vertrag. Sie passen die Muster an Ihre Umgebung an, und das Ergebnis liegt in Ihrer Verantwortung.

Wenn Sie das produktionsreif in Ihrer eigenen Infrastruktur betreiben wollen, vermittle ich das als zweitägigen Kubernetes-in-Production-Workshop — Details auf der Consulting-Seite.