Beobachtetes Signal · 4. Mai 2026 · Technical Guide · Quelle: DEV Community · Relevanz: 2/5 · Sentiment: Positiv
Kubernetes-Image-Provenienz mit Cosign und Kyverno absichern
Ein Entwicklerexperiment demonstriert die Durchsetzung der Image-Provenienz in Kubernetes, damit das Cluster ausschließlich kryptografisch signierte Container-Images ausführt. Der Workflow nutzt GitLab CI/CD als Build- und Vertrauensursprung, Cosign und Sigstore zum Signieren sowie Veröffentlichen von OCI-Image-Signaturen, eine OCI-Registry zum Speichern von Images und Signaturen sowie Kyverno als Kubernetes Admission Controller zur Signaturverarbeitung und Richtliniendurchsetzung. Der Autor testete den Ansatz auf einem lokalen MicroK8s-Cluster und veröffentlichte beispielhafte GitLab-Pipeline-Snippets sowie eine Kyverno ClusterPolicy, die Image-Digests auflöst, Cosign-Signaturen aus der Registry abruft und die Pod-Erstellung basierend auf der Verifizierung zulässt oder ablehnt. Ein Referenz-GitHub-Repository mit vollständigem Code und Konfigurationen steht zur Verfügung.
Praxisnahe Anleitung zur durchgängigen Durchsetzung der Container-Image-Provenienz für Kubernetes-Cluster; relevant für Infrastruktur- und Supply-Chain-Security, stellt jedoch keine fundamentale Plattform-Richtlinienänderung dar.
Marktsignale zu GitHub in Echtzeit verfolgen
Polaris7 erfasst behördliche Registrierungen, Primärquellen, Führungswechsel und Deal-Aktivitäten rund um die Uhr. Erstellen Sie Ihren kostenlosen Explorer-Workspace, um automatisierte Executive Briefings zu erhalten.
Wichtigste Kernpunkte & Evidenz
- GitLab CI/CD wird verwendet, um Container-Images zu erstellen, an eine OCI-Registry zu pushen und in der Pipeline zu signieren.
- Cosign (Teil des Sigstore-Projekts) fügt OCI-Images kryptografische Signaturen hinzu und speichert diese als Registry-Artefakte.
- Kyverno erzwingt eine ClusterPolicy zum Zeitpunkt der Admission, um Cosign-Signaturen zu verifizieren, Image-Digests aufzulösen und die Pod-Erstellung zu erlauben oder zu verweigern.
- MicroK8s diente als schlanke, lokale Kubernetes-Umgebung zum Testen des End-to-End-Workflows.
- Eine Referenzimplementierung und Konfigurationen sind unter https://github.com/trottomv/microk8s-cosign-kyverno verfügbar.
Verknüpfte Unternehmen
1 verknüpfte UnternehmenOntologie & Marktkonzepte
Verwandte Marktsignale & Trends
Aktuelle verifizierte Unternehmensentwicklungen und Deal-Aktivitäten in diesem Marktsegment.
CI-Pipelines führten nicht autorisierten Code aus: cilock bietet signierte Provenance
Der Artikel beleuchtet aktuelle Supply-Chain-Vorfälle, bei denen CI-Pipelines kompromittierten Code ausführten – etwa durch einen Force-Push von Git-Tags bei aquasecurity/trivy-action sowie bösartige .pth-Dateien in PyPI-Releases von litellm. Bestehende CI-Workflow-YAMLs können jedoch nicht nachweisen, welcher Code tatsächlich ausgeführt wurde. Als Lösung wird CI/Lock (cilock) vorgestellt, eine Tooling-Schicht, die den Build-Prozess via ptrace oder eBPF überwacht, gelesene Dateien, Umgebungsvariablen sowie Artefakte protokolliert und eine über in-toto/DSSE signierte Attestation generiert. Diese Attestation ermöglicht in Kombination mit signierten Policies eine lückenlose Verifizierung der Build-Ausführung. Dies verbessert die Software-Provenance und mindert Supply-Chain-Risiken in CI-Umgebungen massiv. Veröffentlichungsdatum: 30. Juni 2026.
Automatisierung des Kubernetes-Image-Schwachstellenscans
Diese technische Anleitung zeigt, wie sich die Überprüfung von Container-Image-Schwachstellen in Kubernetes mithilfe des ImagePolicyWebhook Admission Plugins erzwingen lässt. Der Leitfaden erklärt die Konfiguration des Admission Controllers (admission-control.conf) für den Aufruf eines externen Scanners (im Beispiel Trivy), das Erstellen einer Kubeconfig, die den API-Server auf den Scanner-Endpunkt verweist (https://acg.trivy.k8s.webhook:8090/scan), sowie die Aktivierung des ImagePolicyWebhook im Manifest des kube-apiserver. Der Artikel demonstriert den Testvorgang durch die Bereitstellung eines sicheren Pods (der zugelassen wird) und eines Pods mit bekannten Schwachstellen (der vom Webhook abgelehnt wird). Dieser Ansatz erzwingt eine Fail-Closed-Sicherheitsstrategie, sodass unüberprüfte Container-Images nicht in Kubernetes-Cluster aufgenommen werden können.
Eigenständig entwickelte Produktions-GitOps-Plattform auf AWS EKS
Ein Infrastructure Engineer hat die Entwicklung einer produktionsreifen GitOps-Plattform auf AWS EKS anhand der Spring PetClinic-Microservices (7 Dienste) dokumentiert. Die Plattform wird vollständig über Terraform provisioniert und nutzt GitHub Actions mit OIDC für den Build von Docker-Images und den Upload nach Amazon ECR. Eine CI-Pipeline aktualisiert Image-Tags in einem Helm-Chart; Argo CD synchronisiert das Cluster, wobei Git als Single Source of Truth dient. Die Autoscaling-Implementierung erfolgt zweistufig über HPA für Pods und Karpenter für Nodes. Die Observability wird durch Prometheus, Grafana und Zipkin sichergestellt. Das Projekt ist über ein Makefile reproduzierbar. Der Autor beschreibt zudem gelöste Produktionsprobleme wie Tracing-Fehlkonfigurationen, CI-Tag-Konflikte, Argo-CD-HPA-Widersprüche sowie Karpenter-IAM-Richtliniengrößen und stellt Repositories sowie eine Live-Demo bereit.
Marktsignale & Strategische Shifts in Echtzeit verfolgen
Erstellen Sie benutzerdefinierte Watchlists, um automatisierte, evidenzbasierte Executive Briefings zu erhalten, sobald wesentliche Signale oder Marktverschiebungen auftreten.