Code Signing und Kubernetes-Sicherheits-Workflows: Was Sie wissen müssen

Da CI/CD heute Standard ist, müssen moderne Anwendungen nicht mehr als Monolithen entwickelt und ausgeliefert werden. Vorbei sind die Zeiten der "Release Days" und massiver Produktaktualisierungen mit langen Vorlaufzeiten und isolierten Entwicklungsbemühungen. Die steigende Popularität und Bedeutung von containerisierten Anwendungen führte zum Wachstum von Orchestrierungsplattformen wie Kubernetes, deren Sicherheit inzwischen für viele moderne Anwendungen von entscheidender Bedeutung geworden ist.

But how do you prove that what you run in Kubernetes is what you built and intended to deploy? Container orchestration platforms greatly benefit from code signing.

Code Signing ist ein wichtiges Sicherheitselement in einer Shift-Links-Entwicklungsstrategie, bei der Sicherheitsmaßnahmen als Funktionen in das Produkt eingebaut werden, bevor es ausgeliefert wird.

Code Signing erhöht die Sicherheit und das Vertrauen in software , indem es software an die Identität bindet und ihre Integrität mit kryptografischen Signaturen bestätigt. Die Zertifikats- und Identitätsstrategie ist nicht länger ein Vorrecht von TLS und Geräteidentitäten. Die Ausweitung auf Entwickler- und Build-Identitäten in Kubernetes ist eine wichtige Möglichkeit, das digitale Vertrauen in Ihrer Organisation zu stärken.

Development with Kubernetes has many advantages, but also pitfalls that code signing can help address. Read on for a discussion of potential gaps in Kubernetes security, how code signing and PKI can help bridge these gaps, and the best practices for signed container security workflows.

Lücken in der Kubernetes-Sicherheit 

Public key infrastructure (PKI) is a necessary part of application development and delivery. Kubernetes certainly already relies on PKI for its many components. Control plane, kubelets, client certificates, and more all use X.509 certificates and certificate signing requests (CSRs) natively.

However, the scope of typical PKI implementation is often limited to infrastructure, leaving software artifacts running in pods and containers exposed and potentially at risk if their integrity isn’t verified in other ways. A Software Bill of Materials (SBOM) can fill part of that visibility gap by providing a complete inventory of components and dependencies within container images, while code signing verifies that these images come from trusted sources.

As teams adopt more fluid and automated CI/CD pipelines and make use of container registries and Kubernetes clusters, unsigned or compromised images can slip past scanning tools to run in production. Best-case scenario: an honest mistake. Worst-case scenario: compromised assets, broken processes, and expensive fallout from the damage. Mutable image tags deepen the risk, as someone could re-push to the same tag, bypassing native checks. This is why many architecture guides emphasize the necessity of cryptographic signing and signature verification in the cluster.

In der Praxis kann es natürlich vorkommen, dass sich Entwickler gegen die Reibung sträuben, die Signierverfahren in den Ablauf einbringen, oder dass sie auf Ad-hoc-Skripte außerhalb der Governance zurückgreifen.

This leads to signing key sprawl and weak signing practices, where code signing scripts malfunction or the signing isn’t done at all. The challenges don’t stop there: smart key management in tune with scaling processes demands not only higher security for private key storage (ideally, in HSMs or key vaults), but also automated certificate lifecycle management for cross-cluster consistency.

Die Durchsetzung von Richtlinien zur Laufzeit ist ebenfalls eine Voraussetzung für einen sichereren Kubernetes-Betrieb. Sobald ein Image signiert ist, sollten Admission Controller oder Policy Engines überprüfen, dass die Kubernetes-Umgebung nur Images mit gültigen und überprüfbaren Signaturen ausführt. Darüber hinaus muss die betreffende Signierungsinfrastruktur flexibel genug sein, um mit der sich schnell entwickelnden Cybersicherheitslandschaft und den Fortschritten in der Kryptografie Schritt zu halten. Der Aufbau einer agilen Infrastruktur, die die Ressourcen des Unternehmens bei der Weiterentwicklung nicht übermäßig belastet, ist eine der wichtigsten Herausforderungen von DevOps.

Wie man die Vertrauenslücke bei Kubernetes überbrückt

Angesichts der Herausforderungen bei der Implementierung von Code Signing in Kubernetes ist es nicht verwunderlich, dass einige Umgebungen noch immer keinen Gebrauch davon machen, obwohl es eindeutig notwendig ist.

Der typische unsichere Arbeitsablauf sieht folgendermaßen aus: Der Entwickler überträgt den Code; CI/CD erstellt ein Container-Image; das Image wird an eine Registry übertragen; Kubernetes bringt es in Produktion. Probleme? Ein paar:

1. Es gibt keinen kryptografischen Beweis, der dieses Bild mit einem verifizierten Erstellungsprozess in Verbindung bringt.
2. Jeder, der Zugriff auf die Registry hat, könnte das Image ersetzen oder manipulieren, und Kubernetes würde es trotzdem bereitstellen, da es nur dem Tag vertraut.
3. Die resultierende Pipeline ist effizient, aber ist sie auch vertrauenswürdig? Sie ist definitiv nicht überprüfbar.

Es gibt zahlreiche Möglichkeiten, diesen Arbeitsablauf zu sichern, die sich nicht ausschließlich auf das Signieren von Code beschränken.

Schritt 1: Einführung einer verifizierten Identität in den Erstellungsprozess

Code signing makes application workflows verifiable and tied to an auditable identity. With a certificate management tool like Keyfactor Command, a code signing certificate is issued to the build system through the same PKI framework that secures TLS and devices. Each build that automatically signs its container image and related binaries becomes part of the secure CI/CD workflow. This signature is tied to a governed, auditable identity, instead of an unmanaged key sitting on a build server. Keys can be stored in integrated HSMs or cloud key vaults, rotated automatically, and revoked if compromised, in line with PKI best practices.

Schritt 2: Ausdehnung des Vertrauens auf die gesamte Lieferkette

Jedes signierte Image wird zusammen mit seiner digitalen Signatur in die Container-Registry übertragen. Command verwaltet den Vertrauensanker und die Zertifikats-Metadaten, sodass jeder Kubernetes-Cluster das Image anhand der vertrauenswürdigen Root des Unternehmens verifizieren kann. Vertrauensbündel werden automatisch über Umgebungen verteilt, unabhängig von der Einrichtung (vor Ort, in der Cloud, hybrid), so dass jeder Cluster eine einheitliche Überprüfungsrichtlinie hat, wodurch die manuelle Konfigurationsabweichung beseitigt wird, die häufig die Sicherheit mehrerer Cluster untergräbt.

Schritt 3: Verwandeln Sie Kubernetes in einen Durchsetzungspunkt

Mit der Code-Signierung können die Kubernetes-eigenen Funktionen die Sicherheit der gesamten Pipeline verbessern. Wenn ein Entwickler ein neues Image bereitstellt, überprüft ein Admission Controller oder eine Policy Engine die Signatur, bevor der Pod eingeplant wird. In gewissem Sinne "hofft" Kubernetes nicht mehr, dass das Image legitim ist, sondern verifiziert es anhand des kryptografischen Nachweises, der im Rahmen der PKI-Governance des Unternehmens ausgestellt wurde, als wahr. Wenn die Image-Signatur fehlt, abgelaufen ist oder nicht vertrauenswürdig ist, wird die Bereitstellung automatisch abgelehnt, ohne dass dadurch legitime Releases verlangsamt werden. Da eine solche Durchsetzung richtliniengesteuert ist und nicht auf Ad-hoc-Skripten beruht, ist sie von Natur aus skalierbar und über Cluster hinweg konsistent.

Schritt 4: Einführung eines umfassenden Lebenszyklusmanagements mit Keyfactor Command

Employing PKI tools such as Keyfactor Command for container security workflows has the advantages of total lifecycle management, automation, and elimination of human error. Code signing keys and certificates follow defined, automatable lifecycles from certificate creation, rotation, and renewal to certificate revocation and retirement. Automated certificate lifecycle management solutions enable organizations to easily adapt to evolving cryptographic standards.

Ein ausgereifter Kubernetes-Sicherheits-Workflow überprüft die folgenden Punkte:

• Jedes Artefakt hat eine überprüfbare Signatur, die mit einer hörbaren Identität verbunden ist.
• Sicherheitsteams können Signieraktivitäten, Zertifikatsstatus und die Durchsetzung von Richtlinien in allen Clustern über ein einziges, einheitliches Dashboard einsehen.
• Audit-Protokolle zeigen genau, welcher Schlüssel welches Build wann und mit wessen Befugnis signiert hat, was die Einhaltung von Vorschriften erleichtert.
• Abgelaufene oder verlorene Anmeldedaten werden rechtzeitig erkannt und korrigiert, so dass es zu keinen Ausfällen oder Sicherheitslücken kommt.

Bewährte Praktiken der Codesignierung für Kubernetes-Sicherheitsabläufe

Die Codesignierung in Kubernetes umfasst vier integrierte Ebenen: Erstellung und Signierung, Überprüfung und Durchsetzung, Registrierung und Speicherung sowie Vertrauensverteilung und Lebenszyklusmanagement.

Die Build- und Signierschicht umfasst CI/CD-Pipelines, die automatisch signierende Identitäten anfordern, wobei die richtlinienbasierte Ausgabe an die PKI des Unternehmens gebunden ist. Kubernetes-Zulassungssteuerungen validieren Signaturen anhand von verwalteten Vertrauensankern, sodass nur verifizierte Workloads ausgeführt werden können. Signierte Images und Metadaten werden gemeinsam gespeichert, so dass die Herkunft jedes Artefakts in den Registern nachvollziehbar ist. Erfolgreiche Automatisierung synchronisiert Vertrauensbündel, rotiert Schlüssel und aktualisiert kryptografische Standards, ohne Bereitstellungen zu unterbrechen.

Unter Berücksichtigung dieser vier Ebenen der Kubernetes-Sicherheit sollten Sie einige bewährte Verfahren implementieren:

• Bereitstellung von Bildern mit unveränderlichen Digests anstelle von veränderbaren Tags, um Substitutionsangriffe zu verhindern
• Definition von Richtlinien auf Clusterebene, damit nur von autorisierten Build-Systemen signierte Workloads zugelassen werden
• Speicherung von privaten Signierschlüsseln in HSMs oder integrierten Tresoren und Automatisierung ihrer Rotation
• Vollständige Prüfprotokolle der Unterzeichnungs- und Überprüfungsvorgänge zur Einhaltung der Vorschriften
• Planung für Krypto-Agilität, da sich Signieralgorithmen viel schneller entwickeln als die Lebenszyklen der Infrastruktur

Schlussfolgerung

Die Kubernetes-Sicherheit umfasst jetzt nicht nur den Schutz der Infrastruktur, sondern auch die Sicherung von software durch Code Signing. Die Integration von Code Signing in den Workflow wird zu einer Standardpraxis, um DevOps-Agilität und PKI-Sicherheit zu verbinden und sicherzustellen, dass jeder Workload authentifiziert und autorisiert ist.

Wenn auf Ihren Kubernetes-Clustern nur kryptografisch verifizierte software läuft, ist Sicherheit keine Annahme mehr, sondern wird zu einer Betriebsgarantie.

Dieser Prozess kann klein beginnen: Signieren Sie eine einzelne CI/CD-Pipeline, erzwingen Sie Signaturen in einem Cluster, und weiten Sie ihn dann auf das gesamte Unternehmen aus. 

Keyfactor Command bietet die Automatisierung und Transparenz, um es skalierbar zu machen, von der Ausstellung und Rotation von Zertifikaten bis zur Verwaltung von Vertrauensbündeln und der Integration mit CI/CD- und Kubernetes-Tools.

The future of container security is verifiable trust.  Get in touch with Keyfactor today to help build it. Have any questions? Our team is here to help!