DE112021003864T5

DE112021003864T5 - Durchsetzung von signaturen für die konfiguration von softwarebereitstellung

Info

Publication number: DE112021003864T5
Application number: DE112021003864.8T
Authority: DE
Inventors: Michael McKay; Jacob Andrew Kitchener; Richard Adam King; Alexander Lewitt
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2020-07-20
Filing date: 2021-06-18
Publication date: 2023-06-07
Also published as: WO2022018539A1; JP2023535886A; US11507355B2; GB2611736A; CN116158055A; US20220019418A1

Abstract

Bei einem Ansatz fängt ein Verfahren eine Bereitstellungsressource ab, die zu Software gehört, bevor die Software an einem Knoten bereitgestellt wird, wobei die Bereitstellungsressource konfiguriert, wie die Software bereitgestellt wird und arbeitet. Ein Prozessor verifiziert eine Authentizität einer in der Bereitstellungsressource vorhandenen digitalen Signatur. Ein Prozessor stellt als Reaktion auf die Verifizierung der Authentizität der digitalen Signatur die Software gemäß der Bereitstellungsressource an dem Knoten bereit.

Description

HINTERGRUND
Die vorliegende Erfindung betrifft allgemein das Gebiet der Softwarebereitstellung und insbesondere die Durchsetzung von Signaturen von Softwarebereitstellungs-Konfigurationsdaten.
Softwarebereitstellung umfasst alle Aktivitäten, die ein Softwaresystem zur Nutzung verfügbar machen. In der Regel sind Inhalt und Konfiguration zwei notwendige Elemente der Softwarebereitstellung. Konfiguration betrifft Daten, die die Art und Weise konfigurieren, wie eine Anwendung bereitgestellt wird und wie die Anwendung nach ihrer Bereitstellung arbeitet. Konfigurationsdateien werden verwendet, um die Parameter und Anfangseinstellungen für eine Anwendung oder einen Container zu konfigurieren. Beispiele für Konfigurationsdateien sind Kubernetes^® YAML („YAML Ain't Markup Language“) und Ansible^® Playbooks. Ansible^® ist eine Marke bzw. eingetragene Marke von Red Hat, Inc. oder deren Tochtergesellschaften in den Vereinigten Staaten und anderen Ländern.
Kryptografische Signiertechniken wie beispielsweise digitale Signaturen sind mathematische Verfahren zur Verifikation der Authentizität digitaler Nachrichten oder Dokumente. Eine gültige digitale Signatur liefert einen starken Grund für die Annahme, dass das Dokument vom Signierer erstellt oder bearbeitet wurde und dass die Nachricht während der Übertragung nicht geändert wurde. Digitale Signaturen verwenden asymmetrische Kryptografie und können für Nachrichten oder Dokumente, die über unsichere Kanäle gesendet werden, eine Validierungs- und Sicherheitsebene bieten. Üblicherweise sind bei einem digitalen Signierverfahren drei Algorithmen beteiligt. Ein Schlüsselerzeugungsalgorithmus erzeugt eine Signatur, nachdem er einen privaten Schlüssel zusammen mit dessen zugehörigem öffentlichen Schlüssel erhalten hat. Ein Signieralgorithmus erzeugt nach Erhalt eines privaten Schlüssels und einer zu signierenden Nachricht oder von zu signierenden Daten eine Signatur. Ein Verifizierungsalgorithmus überprüft die Authentizität der Nachricht, indem er die Nachricht zusammen mit der Signatur und dem öffentlichen Schlüssel verifiziert.
KURZDARSTELLUNG
Aspekte einer Ausführungsform der vorliegenden Erfindung offenbaren ein Verfahren, ein Computerprogrammprodukt und ein Computersystem. Ein Prozessor fängt eine Bereitstellungsressource ab, die zu einer Software gehört, bevor die Software an einem Knoten bereitgestellt wird, wobei die Bereitstellungsressource konfiguriert, wie die Software bereitgestellt und betrieben wird. Ein Prozessor verifiziert die Authentizität einer in der Bereitstellungsressource vorhandenen digitalen Signatur. Ein Prozessor stellt, als Reaktion auf die Verifizierung der Authentizität der digitalen Signatur, die Software gemäß der Bereitstellungsressource an dem Knoten bereit.
Figurenliste
Ausführungsformen der Erfindung werden nun nur beispielhaft mit Bezug auf die begleitenden Zeichnungen beschrieben, bei denen:

1 einen Cloud-Computing-Knoten gemäß einer Ausführungsform der vorliegenden Erfindung zeigt.
2 zeigt eine Cloud-Computing-Umgebung gemäß einer Ausführungsform der vorliegenden Erfindung.
3 zeigt Abstraktionsmodellschichten gemäß einer Ausführungsform der vorliegenden Erfindung.
4 zeigt ein Blockschema einer Datenverarbeitungsumgebung gemäß einer Ausführungsform der vorliegenden Erfindung.
5 ist ein Flussdiagramm, das Betriebsschritte zum Erstellen digitaler Signaturen in einer Bereitstellungsressource gemäß einer Ausführungsform der vorliegenden Erfindung zeigt.
6 ist ein Flussdiagramm, das Betriebsschritte zum Verifizieren digitaler Signaturen in einer Bereitstellungsressource gemäß einer Ausführungsform der vorliegenden Erfindung zeigt.
7 ist eine beispielhafte Zulassungsrichtlinie gemäß einer Ausführungsform der vorliegenden Erfindung.
8 ist eine beispielhafte Bereitstellungsressource gemäß einer Ausführungsform der vorliegenden Erfindung.
9 ist eine weitere beispielhafte Bereitstellungsressource gemäß einer Ausführungsform der vorliegenden Erfindung.

DETAILLIERTE BESCHREIBUNG
Softwarebereitstellung umfasst die bereitzustellende Software (d.h. deren Inhalt) sowie Konfigurationsdaten. Die Konfigurationsdaten und zugehörigen Bereitstellungs-Metadaten, die hier gemeinsam als Bereitstellungsressourcen bezeichnet werden, können vertrauliche Daten umfassen, die die Art und Weise konfigurieren, wie eine Anwendung bereitgestellt wird und wie die Anwendung arbeitet, nachdem die Anwendung bereitgestellt wurde. Ausführungsformen der vorliegenden Erfindung berücksichtigen, dass es bei der Softwarebereitstellung derzeit keine Möglichkeiten gibt, den Ursprung und die Integrität von Konfigurationsdaten und zugehörigen Bereitstellungs-Metadaten zu verifizieren. Ausführungsformen der vorliegenden Erfindung berücksichtigen ferner, dass die Verifizierung sowohl des Inhalts als auch der Bereitstellungsressourcen für die Sicherheit einer Softwareplattform kritisch ist. Ausführungsformen der vorliegenden Erfindung sehen einen Ansatz zur Verwendung kryptografischer Signiertechniken zum Signieren von Softwarebereitstellungskonfigurationen und/oder Metadaten-Bereitstellungsressourcen vor. Systeme können sich dann auf die kryptografischen Signaturtechniken verlassen, um den Ursprung und die Integrität der Bereitstellungsressourcen zu prüfen und festzustellen, ob die Signaturen einer Zulassungsrichtlinie entsprechen. Nachfolgend kann eine solche Prüfung verwendet werden, um zu ermitteln, ob Software gemäß den zur Verfügung gestellten Bereitstellungsressourcen bereitgestellt werden soll oder nicht.
Es sei von vornherein klargestellt, dass das Umsetzen der hierin angeführten Lehren nicht auf eine Cloud-Computing-Umgebung beschränkt ist, obwohl diese Offenbarung eine ausführliche Beschreibung von Cloud-Computing umfasst. Vielmehr können Ausführungsformen der vorliegenden Erfindung gemeinsam mit jeder beliebigen Art von jetzt bekannter oder später erfundener Datenverarbeitungsumgebung umgesetzt werden.
Cloud-Computing ist ein Servicebereitstellungsmodell zum Ermöglichen eines problemlosen bedarfsgesteuerten Netzwerkzugriffs auf einen gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen (z.B. Netzwerke, Netzwerkbandbreite, Server, Verarbeitung, Hauptspeicher, Speicher, Anwendungen, virtuelle Maschinen und Dienste), die mit minimalem Verwaltungsaufwand bzw. minimaler Interaktion mit einem Anbieter des Service schnell bereitgestellt und freigegeben werden können. Dieses Cloud-Modell kann mindestens fünf Eigenschaften umfassen, mindestens drei Dienstmodelle und mindestens vier Implementierungsmodelle.
Bei den Eigenschaften handelt es sich um die Folgenden:

On-Demand Self-Service: Ein Cloud-Nutzer kann einseitig automatisch nach Bedarf für Datenverarbeitungsfunktionen wie Serverzeit und Netzwerkspeicher sorgen, ohne dass eine menschliche Interaktion mit dem Anbieter der Dienste erforderlich ist.
Broad Network Access: Es sind Funktionen über ein Netzwerk verfügbar, auf die durch Standardmechanismen zugegriffen wird, welche die Verwendung durch heterogene Thin- oder Thick-Client-Plattformen (z.B. Mobiltelefone, Laptops und PDAs) unterstützen.
Resource-Pooling: Die Datenverarbeitungsressourcen des Anbieters werden zusammengeschlossen, um mehreren Nutzern unter Verwendung eines Multi-Tenant-Modells zu dienen, wobei verschiedene physische und virtuelle Ressourcen dynamisch nach Bedarf zugewiesen und neu zugewiesen werden. Es gibt eine gefühlte Standortunabhängigkeit, da der Nutzer allgemein keine Kontrolle bzw. Kenntnis über den genauen Standort der bereitgestellten Ressourcen hat, aber in der Lage sein kann, einen Standort auf einer höheren Abstraktionsebene festzulegen (z.B. Land, Staat oder Rechenzentrum).
Rapid Elasticity: Funktionen können für eine schnelle horizontale Skalierung (scale out) schnell und elastisch bereitgestellt werden, in einigen Fällen auch automatisch, und für ein schnelles Scale-in schnell freigegeben werden. Für den Nutzer erscheinen die für das Bereitstellen verfügbaren Funktionen häufig unbegrenzt und sie können jederzeit in jeder beliebigen Menge gekauft werden.
Measured Service: Cloud-Systeme steuern und optimieren die Verwendung von Ressourcen automatisch, indem sie eine Messfunktion auf einer gewissen Abstraktionsebene nutzen, die für die Art von Dienst geeignet ist (z.B. Speicher, Verarbeitung, Bandbreite sowie aktive Benutzerkonten). Die Nutzung von Ressourcen kann überwacht, gesteuert und gemeldet werden, wodurch sowohl für den Anbieter als auch für den Nutzer des verwendeten Dienstes Transparenz geschaffen wird.

Bei den Dienstmodellen handelt es sich um die Folgenden:

Software as a Service (SaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, die in einer Cloud-Infrastruktur laufenden Anwendungen des Anbieters zu verwenden. Die Anwendungen sind über eine Thin-Client-Schnittstelle wie einen Web-Browser (z.B. auf dem Web beruhende E-Mail) von verschiedenen Client-Einheiten her zugänglich. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter das Netzwerk, Server, Betriebssysteme, Speicher bzw. sogar einzelne Anwendungsfunktionen, mit der möglichen Ausnahme von eingeschränkten benutzerspezifischen Anwendungskonfigurationseinstellungen.
Platform as a Service (PaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, durch einen Nutzer erstellte bzw. erhaltene Anwendungen, die unter Verwendung von durch den Anbieter unterstützten Programmiersprachen und Tools erstellt wurden, in der Cloud-Infrastruktur einzusetzen. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter Netzwerke, Server, Betriebssysteme bzw. Speicher, hat aber die Kontrolle über die eingesetzten Anwendungen und möglicherweise über Konfigurationen des Application Hosting Environment.
Infrastructure as a Service (laaS): Die dem Nutzer bereitgestellte Funktion besteht darin, das Verarbeiten, Speicher, Netzwerke und andere grundlegende Datenverarbeitungsressourcen bereitzustellen, wobei der Nutzer in der Lage ist, beliebige Software einzusetzen und auszuführen, zu der Betriebssysteme und Anwendungen gehören können. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, hat aber die Kontrolle über Betriebssysteme, Speicher, eingesetzte Anwendungen und möglicherweise eine eingeschränkte Kontrolle über ausgewählte Netzwerkkomponenten (z.B. Host-Firewalls).

Bei den Einsatzmodellen handelt es sich um die Folgenden:

Private Cloud: Die Cloud-Infrastruktur wird einzig und allein für eine Organisation betrieben. Sie kann durch die Organisation oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder in fremden Räumen befinden.
Community Cloud: Die Cloud-Infrastruktur wird von mehreren Organisationen gemeinsam genutzt und unterstützt eine spezielle Benutzergemeinschaft, die gemeinsame Angelegenheiten hat (z.B. Mission, Sicherheitsanforderungen, Richtlinien sowie Überlegungen bezüglich der Einhaltung von Vorschriften). Sie kann durch die Organisationen oder einen Dritten verwaltet werden und kann in den eigenen Räumen oder fremden Räumen stehen.
Public Cloud: Die Cloud-Infrastruktur wird der allgemeinen Öffentlichkeit oder einer großen Industriegruppe zur Verfügung gestellt und sie gehört einer Cloud-Dienste verkaufenden Organisation.
Hybrid Cloud: Die Cloud-Infrastruktur ist eine Zusammensetzung aus zwei oder mehreren Clouds (privat, Benutzergemeinschaft oder öffentlich), die zwar einzelne Einheiten bleiben, aber durch eine standardisierte oder proprietäre Technologie miteinander verbunden sind, die Daten- und Anwendungsportierbarkeit ermöglicht (z.B. Cloud-Zielgruppenverteilung für den Lastenausgleich zwischen Clouds).

Eine Cloud-Computing-Umgebung ist dienstorientiert mit Fokus auf Statusunabhängigkeit, geringer Kopplung, Modularität und semantischer Interoperabilität. Im Herzen von Cloud-Computing liegt eine Infrastruktur, die ein Netz aus zusammengeschalteten Knoten umfasst.
Unter Bezugnahme auf 1 ist ein Schema eines Beispiels eines Cloud-Computing-Knotens gezeigt. Der Cloud-Computing-Knoten 10 ist nur ein Beispiel eines geeigneten Cloud-Computing-Systems und soll keine Einschränkung hinsichtlich des Umfangs der Verwendung oder Wirkungsweise der hierin beschriebenen Ausführungsformen der Erfindung darstellen. Unabhängig davon kann der Cloud-Computing-Knoten 10 jede der Funktionen umsetzen und/oder ausführen, die oben dargelegt sind.
Im Cloud-Computing-Knoten 10 gibt es ein Computersystem/einen Server 12, der mit zahlreichen anderen Allzweck- oder Spezial-Rechensystemumgebungen oder -konfigurationen betriebsfähig ist. Beispiele für bekannte Datenverarbeitungssysteme, -umgebungen und/oder -konfigurationen, die zur Verwendung mit dem Computersystem/Server 12 geeignet sein können, umfassen ohne Einschränkung Personal-Computer-Systeme, Server-Computersysteme, Thin Clients, Thick Clients, Handheld- oder Laptopeinheiten, Multiprozessorsysteme, mikroprozessorgestützte Systeme, Set-Top-Boxen, programmierbare Unterhaltungselektronik, Netzwerkcomputer, Minicomputersysteme, Mainframe-Computersysteme und verteilte Cloud-Computing-Umgebungen, die beliebige der oben genannten Systeme oder Einheiten umfassen, und dergleichen.
Das Computersystem/der Server 12 kann im allgemeinen Kontext von durch ein Computersystem ausführbaren Anweisungen beschrieben werden, beispielsweise Programmmodulen, die von einem Computersystem ausgeführt werden. Im Allgemeinen können die Programmmodule Routinen, Programme, Objekte, Komponenten, Logik, Datenstrukturen usw. umfassen, die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Das Computersystem/der Server 12 kann in verteilten Cloud-Computing-Umgebungen betrieben werden, bei denen Aufgaben von Fernverarbeitungseinheiten ausgeführt werden, die über ein Datenübertragungsnetzwerk verbunden sind. In einer verteilten Cloud-Computing-Umgebung können sich Programmmodule sowohl auf lokalen als auch auf entfernt angeordneten Computersystem-Speichermedien wie beispielsweise Speichereinheiten befinden.
Wie in 1 gezeigt, ist das Computersystem/der Server 12 im Cloud-Computing-Knoten 10 in Form einer Allzweck-Datenverarbeitungseinheit gezeigt. Die Komponenten des Computersystems/Servers 12 können, ohne darauf beschränkt zu sein, einen oder mehrere Prozessoren oder Verarbeitungseinheiten 16, Systemspeicher 28 und einen Bus 18 umfassen, der verschiedene Systemkomponenten wie beispielsweise den Systemspeicher 28 mit dem Prozessor 16 verbindet.
Der Bus 18 stellt eine oder mehrere von mehreren Arten von Busstrukturen dar, beispielsweise eines Speicherbusses bzw. eines Speichercontrollers, eines Peripheriebusses, eines Accelerated Graphics Port und eines Prozessor- bzw. lokalen Busses, unter Verwendung einer Vielfalt von Busarchitekturen. Beispielsweise und ohne Einschränkung umfassen solche Architekturen ISA-Busse („Industry Standard Architecture“), MCA-Busse („Micro Channel Architecture“), EISA-Busse („Enhanced ISA“), lokale VESA-Busse („Video Electronics Standards Association“) und PCI-Busse („Peripheral Component Interconnects“).
Das Computersystem/der Server 12 umfasst üblicherweise eine Vielfalt von von einem Computersystem lesbaren Medien. Solche Medien können aus allen verfügbaren Medien bestehen, auf die das Computersystem/der Server 12 zugreifen kann, und sie umfassen sowohl flüchtige als auch nichtflüchtige Medien, austauschbare und nicht austauschbare Medien.
Der Systemspeicher 28 kann vom Computersystem lesbare Medien in Form von flüchtigem Speicher umfassen, beispielsweise Direktzugriffsspeicher (RAM) 30 und/oder Cache-Speicher 32. Das Computersystem/der Server 12 kann ferner weitere austauschbare/nicht austauschbare, flüchtige/nichtflüchtige Speichermedien des Computersystems umfassen. Nur beispielhaft kann das Speichersystem 34 zum Lesen von und Schreiben auf einem nicht austauschbaren, nichtflüchtigen magnetischen Medium (nicht gezeigt und üblicherweise als „Festplatte“ bezeichnet) eingerichtet sein. Obwohl nicht gezeigt, können ein Magnetplattenlaufwerk zum Lesen von und Schreiben auf einer austauschbaren, nichtflüchtigen Magnetplatte (z.B. einer „Diskette“) und ein Laufwerk für optische Platten zum Lesen von oder Schreiben auf einer austauschbaren, nichtflüchtigen optischen Platte wie einer CD-ROM, DVD-ROM oder einem anderen optischen Medium vorgesehen sein. In solchen Fällen können diese jeweils über eine oder mehrere Medien-Datenschnittstellen mit dem Bus 18 verbunden sein. Wie nachstehend weiter gezeigt und beschrieben, kann der Speicher 28 mindestens ein Programmprodukt mit einem Satz von Programmmodulen (z.B. mindestens einem) enthalten, die zum Ausführen der Funktionen von Ausführungsformen der Erfindung konfiguriert sind.
Als Beispiel und nicht einschränkend können ein Programm/Dienst 40 mit einem Satz (mindestens einem) von Programmmodulen 42 ebenso wie ein Betriebssystem, ein oder mehrere Anwendungsprogramme, weitere Programmmodule und Programmdaten im Speicher 28 gespeichert sein. Das Betriebssystem, das eine oder die mehreren Anwendungsprogramme, die weiteren Programmmodule und Programmdaten oder eine Kombination davon können eine Umsetzung einer Netzwerkumgebung umfassen. Die Programmmodule 42 führen im Allgemeinen die Funktionen und/oder Verfahren von Ausführungsformen der Erfindung wie hierin beschrieben aus.
Das Computersystem/der Server 12 kann auch mit einer oder mehreren externen Einheiten 14 Daten austauschen, beispielsweise einer Tastatur, einer Zeigeeinheit, einer Anzeige 24 usw.; einer oder mehreren Einheiten, die es einem Benutzer erlauben, mit dem Computersystem/Server 12 zu interagieren; und/oder einer oder mehreren Einheiten (z.B. einer Netzwerkkarte, einem Modem usw.), die es dem Computersystem/Server 12 erlauben, mit einem oder mehreren anderen Recheneinheiten Daten auszutauschen. Ein solcher Datenaustausch kann über Eingabe/Ausgabe- (E/A) -Schnittstellen 22 erfolgen. Noch weiter kann das Computersystem/der Server 12 über einen Netzwerkadapter 20 mit einem oder mehreren Netzwerken wie einem lokalen Netzwerk (LAN), einem Weitverkehrsnetzwerk (WAN) und/oder einem öffentlichen Netzwerk (z.B. dem Internet) Daten austauschen. Wie gezeigt, tauscht der Netzwerkadapter 20 mit den anderen Komponenten des Computersystems/Servers 12 über den Bus 18 Daten aus. Es versteht sich, dass andere Hardware- und/oder Softwarekomponenten, obwohl nicht gezeigt, in Verbindung mit dem Computersystem/Server 12 verwendet werden könnten. Beispiele hierfür sind unter anderem: Mikrocode, Einheitentreiber, redundante Verarbeitungseinheiten, externe Festplattenarrays, RAID-Systeme, Bandlaufwerke und Datenarchivierungsspeichersysteme usw.
Unter Bezugnahme auf 2 ist eine beispielhafte Cloud-Computing-Umgebung 50 gezeigt. Wie gezeigt, weist die Cloud-Computing-Umgebung 50 einen oder mehrere Cloud-Computing-Knoten 10 auf, mit denen von Cloud-Nutzern verwendete lokale Datenverarbeitungseinheiten wie der elektronische Assistent (PDA, personal digital assistant) oder das Mobiltelefon 54A, der Desktop-Computer 54B, der Laptop-Computer 54C und/oder das Automobil-Computer-System 54N Daten austauschen können. Die Knoten 10 können miteinander Daten austauschen. Sie können physisch oder virtuell in ein oder mehrere Netzwerke wie private, Benutzergemeinschafts-, öffentliche oder hybride Clouds gruppiert werden (nicht gezeigt), wie vorstehend beschrieben wurde, oder in eine Kombination daraus. Dies ermöglicht es der Cloud-Computing-Umgebung 50, Infrastruktur, Plattformen und/oder Software as a Service anzubieten, für die ein Cloud-Nutzer keine Ressourcen auf einer lokalen Datenverarbeitungseinheit vorhalten muss. Es sei darauf hingewiesen, dass die Arten von in 2 gezeigten Datenverarbeitungseinheiten 54A bis N lediglich beispielhaft sein sollen und dass die Datenverarbeitungsknoten 10 und die Cloud-Computing-Umgebung 50 über eine beliebige Art Netzwerk und/oder über eine beliebige Art von über ein Netzwerk aufrufbarer Verbindung (z.B. unter Verwendung eines Web-Browsers) mit einer beliebigen Art von computergestützter Einheit Daten austauschen können.
Unter Bezugnahme auf 3 wird ein Satz von funktionalen Abstraktionsschichten gezeigt, die durch die Cloud-Computing-Umgebung 50 (2) bereitgestellt werden. Es sollte von vornherein klar sein, dass die in 3 gezeigten Komponenten, Schichten und Funktionen lediglich beispielhaft sein sollen und Ausführungsformen der Erfindung nicht darauf beschränkt sind. Wie abgebildet ist, werden die folgenden Schichten und entsprechenden Funktionen bereitgestellt:
Eine Hardware- und Software-Schicht 60 umfasst Hardware- und SoftwareKomponenten. Zu Beispielen für Hardware-Komponenten gehören: Mainframe-Computer 61; auf der RISC- (Reduced Instruction Set Computer) Architektur beruhende Server 62; Server 63; Blade-Server 64; Speichereinheiten 65; und Netzwerke sowie Netzwerkkomponenten 66. In einigen Ausführungsformen umfassen die SoftwareKomponenten eine Netzwerk-Anwendungsserver-Software 67 und eine Datenbank-Software 68.
Eine Virtualisierungsschicht 70 stellt eine Abstraktionsschicht bereit, aus der die folgenden Beispiele für virtuelle Einheiten bereitgestellt werden können: virtuelle Server 71, virtueller Speicher 72, virtuelle Netzwerke 73, darunter virtuelle private Netzwerke, virtuelle Anwendungen und Betriebssysteme 74; und virtuelle Clients 75.
In einem Beispiel kann eine Verwaltungsschicht 80 die nachfolgend beschriebenen Funktionen bereitstellen. Eine Ressourcen-Bereitstellung 81 stellt die dynamische Beschaffung von Datenverarbeitungsressourcen sowie anderen Ressourcen bereit, die zum Durchführen von Aufgaben innerhalb der Cloud-Computing-Umgebung verwendet werden. Ein Messen und eine Preisfindung 82 stellen die Kostenverfolgung beim Verwenden von Ressourcen innerhalb der Cloud-Computing-Umgebung sowie die Abrechnung bzw. Rechnungsstellung für den Verbrauch dieser Ressourcen bereit. In einem Beispiel können diese Ressourcen Anwendungs-Software-Lizenzen umfassen. Die Sicherheit stellt die Identitätsüberprüfung für Cloud-Nutzer und Aufgaben sowie Schutz für Daten und andere Ressourcen bereit. Ein Benutzerportal 83 stellt Nutzern und Systemadministratoren den Zugang zu der Cloud-Computing-Umgebung bereit. Eine Verwaltung des Dienstumfangs 84 stellt die Zuordnung und Verwaltung von Cloud-Computing-Ressourcen bereit, so dass die benötigten Dienstziele erreicht werden. Ein Planen und Erfüllen von Vereinbarungen zum Dienstumfang (SLA, Service Level Agreement) 85 stellt die Anordnung vorab und die Beschaffung von Cloud-Computing-Ressourcen, für die eine zukünftige Anforderung vorausgesehen wird, gemäß einem SLA bereit.
Eine Arbeitslastschicht 90 stellt Beispiele für die Funktionalität bereit, für welche die Cloud-Computing-Umgebung verwendet werden kann. Zu Beispielen für Arbeitslasten und Funktionen, die von dieser Schicht bereitgestellt werden können, gehören: Abbildung und Navigation 91; Softwareentwicklung und Lebenszyklusverwaltung 92; Bereitstellung von Ausbildung in virtuellen Klassenzimmern 93; Datenanalytikverarbeitung 94; Transaktionsverarbeitung 95; und ein mobiler Desktop 96.
4 ist ein funktionales Blockschema, das eine allgemein mit 400 bezeichnete Datenverarbeitungsumgebung gemäß einer Ausführungsform der vorliegenden Erfindung zeigt. Die Datenverarbeitungsumgebung 400 ist eine Teildarstellung eines Beispiels einer Architektur der Cloud-Computing-Umgebung 50, wie unter Bezugnahme auf 2 beschrieben. 4 zeigt nur ein Beispiel einer Ausführungsform und impliziert keine Einschränkungen in Bezug auf die Umgebungen, in denen verschiedene Ausführungsformen umgesetzt werden können.
In der gezeigten Ausführungsform umfasst die Datenverarbeitungsumgebung 400 einen Server 420 und einen oder mehrere Knoten 480, die über ein Netzwerk 410 miteinander verbunden sind. Das Netzwerk 410 kann aus einem lokalen Netzwerk (LAN), einem Weitverkehrsnetzwerk (WAN) wie dem Internet, dem öffentlichen Telefonnetz (PSTN), einer beliebigen Kombination davon oder einer beliebigen Kombination von Verbindungen und Protokollen bestehen, die den Datenaustausch zwischen dem Server 420 und dem einen oder den mehreren Knoten 480 unterstützen. Das Netzwerk 410 kann verdrahtete, drahtlose oder faseroptische Verbindungen umfassen. Die Datenverarbeitungsumgebung 400 kann zusätzliche Server, Datenverarbeitungseinheiten oder andere nicht gezeigte Einheiten umfassen.
Der Server 420 kann aus einem Verwaltungsserver, einem Webserver oder einer beliebigen anderen elektronischen Einheit oder einem beliebigen anderen Datenverarbeitungssystem bestehen, die Daten empfangen und senden können. In einigen Ausführungsformen kann der Server 420 aus einem Laptop-Computer, einem Tablet-Computer, einem Personal-Computer (PC), einem Desktop-Computer oder einer beliebigen programmierbaren elektronischen Einheit bestehen, die mit dem/den Knoten 480 über das Netzwerk 410 Daten austauschen kann. In einer Ausführungsform stellt der Server 420 einen Knoten, etwa den Knoten 10, einer Cloud-Computing-Umgebung dar, etwa der Cloud-Computing-Umgebung 50 (siehe 2). In einigen Ausführungsformen kann der Server 420 ein Server-Datenverarbeitungssystem darstellen, das geclusterte Computer und Komponenten verwendet, um als einheitlicher Pool nahtloser Ressourcen zu fungieren. In der gezeigten Ausführungsform enthält der Server 420 zumindest ein Bereitstellungsprogramm 430, eine Signaturfunktion 440, eine Verifizierungsfunktion 450, Software 460 und eine Zulassungsrichtlinie 470.
Der eine oder die mehreren Knoten 480 können aus einem Verwaltungsserver, einem Webserver oder einer beliebigen anderen elektronischen Einheit oder einem beliebigen anderen Datenverarbeitungssystem bestehen, die Daten empfangen und senden können. In einigen Ausführungsformen können der eine oder die mehreren Knoten 480 aus einem Laptop-Computer, einem Tablet-Computer, einem Netbook-Computer, einem Personal-Computer (PC), einem Desktop-Computer oder einer beliebigen programmierbaren elektronischen Einheit bestehen, die über das Netzwerk 410 mit dem Server 420 Daten austauschen kann. In einer Ausführungsform ist der Knoten 480 ein Beispiel für eine Datenverarbeitungseinheit, wie beispielsweise die Datenverarbeitungseinheiten 54A bis 54N, die verwendet wird, um auf die Cloud-Computing-Umgebung 50 zuzugreifen und/oder mit ihr Daten auszutauschen. In einer weiteren Ausführungsform stellt der Knoten 480 einen Knoten, etwa den Knoten 10, einer Cloud-Computing-Umgebung dar, etwa der Cloud-Computing-Umgebung 50 (siehe 2). In einigen Ausführungsformen kann der Knoten 480 ein Server-Datenverarbeitungssystem darstellen, das mehrere Computer als ein Serversystem, etwa in einer Cloud-Computing-Umgebung, verwendet. In einigen Ausführungsformen stellt der Knoten 480 ein Datenverarbeitungssystem dar, das geclusterte Computer und Komponenten verwendet, um als einheitlicher Pool von nahtlosen Ressourcen zu fungieren. In der abgebildeten Ausführungsform umfasst der Knoten 480 Software 490. Obwohl als Mehrzahl von Knoten gezeigt, können der eine oder die mehreren Knoten 480 in verschiedenen Ausführungsformen einen oder eine beliebige andere Anzahl von Knoten darstellen.
In einer Ausführungsform sind der Server 420 und der/die Knoten 480 Teil einer Kubernetes^®-Umgebung, wobei der Server 420 einen Master-Knoten darstellt und der eine oder die mehreren Knoten 480 einen oder mehrere Arbeiter-Knoten darstellen. In einer solchen Ausführungsform kann die Verifizierungsfunktion 450 einen Teil eines API-Servers (Programmierschnittstellen-Servers) innerhalb des Master-Knotens bilden.
Das Bereitstellungsprogramm 430 wird auf dem Server 420 ausgeführt. Das Bereitstellungsprogramm 430 kann aus einem dedizierten Bereitstellungsprogramm, einer Funktion, die in ein anderes Programm wie beispielsweise ein Orchestrierungs- oder Softwarebereitstellungsprogramm integriert ist, oder einem beliebigen anderen Programm oder einer beliebigen anderen Funktion bestehen, die mit den Knoten 480 Daten austauschen und eine Benutzerschnittstelle zum Interagieren mit Bereitstellungsressourcen und zum Erstellen/Durchsetzen kryptografischer Signaturen von Bereitstellungsressourcen bieten kann. In weiteren Ausführungsformen kann sich das Bereitstellungsprogramm 430 auf anderen Einheiten befinden, vorausgesetzt, dass das Bereitstellungsprogramm 430 mit der Software 460, der Zulassungsrichtlinie 470 und dem einen oder den mehreren Knoten 480 Daten austauschen kann. Das Bereitstellungsprogramm 430 kann die Signaturfunktion 440 und die Verifizierungsfunktion 450 enthalten.
Die Signaturfunktion 440 arbeitet so, dass sie eine Auswahl von einem oder mehreren zu signierenden Abschnitten einer Bereitstellungsressource empfängt, ausgewählte Abschnitte verschlüsselt und eine Signatur an die Bereitstellungsressource anhängt. Die Signaturfunktion 440 kann aus einer Funktion des Bereitstellungsprogramms 430 oder einem eigenständigen Programm bestehen. In einer Ausführungsform liegt die Signaturfunktion 440 auf dem Server 420. In weiteren Ausführungsformen kann sich die Signaturfunktion auf einem anderen Server oder einer anderen Datenverarbeitungseinheit befinden, vorausgesetzt, dass die Signaturfunktion 440 für das Bereitstellungsprogramm 430 zugänglich ist und Zugriff auf die Software 460 und/oder die Zulassungsrichtlinie 270 hat.
Die Verifizierungsfunktion 450 dient zum Abfangen von Bereitstellungsressourcen vor der Bereitstellung von Software und zum Überprüfen, ob Signaturen, die in den Bereitstellungsressourcen vorhanden sind, einer Zulassungsrichtlinie entsprechen. Die Verifizierungsfunktion 450 kann aus einer Funktion des Bereitstellungsprogramms 430 oder einem eigenständigen Programm bestehen. In einer Kubernetes^®-Umgebung kann die Verifizierungsfunktion 450 als Admission Controller (Zulassungssteuerung) umgesetzt sein. Ein Admission Controller ist ein Stück Code, das Anfragen an den Kubernetes^®-API-Server abfängt. In einer Ausführungsform liegt die Verifizierungsfunktion 450 auf dem Server 420. In weiteren Ausführungsformen kann sich die Verifizierungsfunktion 450 auf einem anderen Server oder einer anderen Datenverarbeitungseinheit befinden, vorausgesetzt, dass der Verifizierungsserver für das Bereitstellungsprogramm 430 zugänglich ist und Zugriff auf die Software 460 und die Zulassungsrichtlinie 470 hat.
Die Software 460 kann ein Repository sein, das durch das Bereitstellungsprogramm 430 und die Signaturfunktion 440 beschrieben und gelesen werden kann und für die Verifizierungsfunktion 450 zugänglich sein kann. Die Software 460 kann beispielsweise Software- und Bereitstellungsressourcen wie Konfigurationsdateien (z.B. YAML, Ansible^® Playbooks) und zugehörige Metadaten umfassen. Die Software kann zum Beispiel Virtuelle-Maschinen- und Container-Abbilder umfassen. Im Allgemeinen kann die Software 460 eine beliebige Kombination aus Inhalt und Konfigurationsdaten umfassen, die an dem einen oder den mehreren Knoten 480 bereitgestellt werden können. Die Software 460 kann beispielsweise aus einer Datenbank bestehen.
Die Zulassungsrichtlinie 470 kann ein Repository sein, das durch das Bereitstellungsprogramm 430 beschrieben und gelesen werden kann und das für die Signaturfunktion 440 und/oder die Verifizierungsfunktion 450 zugänglich ist. Die Zulassungsrichtlinie 470 kann eine oder mehrere Zulassungsrichtlinien für die Bereitstellung von Softwareressourcen umfassen. Im Allgemeinen legt die Zulassungsrichtlinie Signaturanforderungen für bestimmte Abschnitte oder eine gesamte Konfigurationsdatei fest, die erfüllt werden müssen, um die Software bereitzustellen. Insbesondere kann die Zulassungsrichtlinie 470 bestimmte Abschnitte von Konfigurationsdateien und erforderliche Signaturen für jeden der bestimmten Abschnitte angeben. Eine beispielhafte Zulassungsrichtlinie ist in 7 gezeigt. Jede Zulassungsrichtlinie kann eine oder mehrere Personen über einige Identifikationsmittel angeben, beispielsweise eine E-Mail-Adresse oder eine Benutzerkennung. Die Zulassungsrichtlinie gibt ferner einen bestimmten Pfad an, der den Abschnitt einer Konfigurationsdatei kennzeichnet, der von der erkannten Person signiert werden muss. Die Zulassungsrichtlinie kann eine beliebige Anzahl bestimmter Personen angeben, die einen Abschnitt signieren müssen, muss aber alternativ keine Personen angeben, wenn beispielsweise keine Signatur erforderlich ist. Wenn mehrere Benutzer aufgelistet sind, muss in einigen Ausführungsformen jede aufgelistete Person den Abschnitt signieren. Wenn in weiteren Ausführungsformen mehrere Benutzer aufgelistet sind, muss mindestens eine der aufgelisteten Personen den Abschnitt signieren. Die anwendbare Zulassungsrichtlinie kann je nach Faktoren wie Client, Zielknoten oder Softwareart schwanken. In einigen Ausführungsformen wird die Zulassungsrichtlinie manuell eingegeben, aber ein Client oder eine Entität sorgt für die Bereitstellung.
Die Software 490 kann Software sein, die durch das Bereitstellungsprogramm 430 bereitgestellt wurde, nachdem sie anwendbare Anforderungen von Zulassungsrichtlinien erfüllt hat, die durch die Verifizierungsfunktion 450 verifiziert wurden. Die Software 490 kann zum Beispiel ein Container, eine virtuelle Maschine, eine Anwendung oder jede andere Software sein, die bereitgestellt werden kann.
5 zeigt ein Flussdiagramm 500 der Schritte einer Signierfunktion gemäß einer Ausführungsform der vorliegenden Erfindung, die in der Datenverarbeitungsumgebung der 1 bis 4 ausgeführt wird, um digitale Signaturen zu Bereitstellungsressourcen wie Konfigurationsdateien hinzuzufügen.
In einer Ausführungsform erstellt oder bearbeitet ein administrativer Nutzer anfänglich Bereitstellungsressourcen wie beispielsweise Konfigurationsdateien, die zu der bereitzustellenden Software gehören, etwa Software, die bei Software 460 gespeichert ist. Beispiele für solche Konfigurationsdateien sind in den 8 und 9 gezeigt. Eine Konfigurationsdatei kann beispielsweise aus einer YAML-Datei bestehen. Im Allgemeinen werden Konfigurationsdateien verwendet, um die Parameter und Anfangseinstellungen für bereitzustellende Software zu konfigurieren. Ausführungsformen der vorliegenden Erfindung berücksichtigen die Wichtigkeit des Bereitstellens kryptografischer Signiertechniken für Bereitstellungsressourcen wie beispielsweise Konfigurationsdateien, da solche Bereitstellungsressourcen vertrauliche Daten enthalten können, die die Art und Weise konfigurieren, wie eine Anwendung oder andere Software bereitgestellt wird und nach der Bereitstellung arbeitet. Eine Konfigurationsdatei kann mehrere Abschnitte und eine Organisationsstruktur umfassen, die es einem administrativen Benutzer erlauben kann, bestimmte Abschnitte innerhalb der Konfigurationsdatei auszuwählen.
Bei Schritt 510 empfängt die Signaturfunktion 440 eine Auswahl eines oder mehrerer Abschnitte der Bereitstellungsressource zum Signieren. In einigen Fällen kann der signierende Benutzer alle Abschnitte auswählen oder angeben, dass die gesamte Datei signiert werden soll. In anderen Fällen kann der signierende Benutzer jedoch einen oder mehrere Abschnitte der Bereitstellungsressource auswählen. Die ausgewählten Abschnitte stellen Abschnitte der Bereitstellungsressource dar, die der signierende Benutzer verifizieren möchte, d.h. er möchte für das Arbeitsprodukt bürgen, das im Inhalt jedes ausgewählten Abschnitts enthalten ist. In einigen Fällen können die ausgewählten Abschnitte Abschnitten entsprechen, die der Benutzer bearbeitet oder erstellt hat. In anderen Fällen können die ausgewählten Abschnitte Abschnitten entsprechen, die der Benutzer geprüft hat. Die ausgewählten Abschnitte können durch Punktnotation, Schrägstrichnotation oder auf eine andere Weise gekennzeichnet sein. In einigen Ausführungsformen bietet die Signaturfunktion 440 Texteingabeoptionen, um eine solche Notation anzugeben. In weiteren Ausführungsformen kann die Signaturfunktion 440 einem Benutzer ermöglichen, den einen oder die mehreren Abschnitte der Bereitstellungsressource unter Verwendung einer grafischen Benutzeroberfläche und beispielsweise eines Cursors hervorzuheben bzw. auszuwählen.
Bei Schritt 520 verschlüsselt die Signaturfunktion 440 die ausgewählten Abschnitte als eine oder mehrere Hashwerte und/oder verschlüsselte Nachrichten. In einigen Ausführungsformen wird eine Einweg-Hashfunktion verwendet, um einen Message Digest für jeden der ausgewählten Abschnitte zu erstellen. Ein Message Digest ist eine numerische Darstellung des Inhalts einer Nachricht mit fester Größe, die von einer Hashfunktion errechnet wird. Ein Message Digest kann verschlüsselt werden, wodurch eine digitale Signatur erzeugt wird. Als solches werden in weiteren Ausführungsformen der eine oder die mehreren erstellten Message Digests mit einem privaten Schlüssel verschlüsselt, um eine digitale Signatur zu erstellen. Der zugehörige öffentliche Schlüssel (i) wurde in solchen Ausführungsformen entweder der Verifizierungsfunktion 450 bereits zugänglich gemacht oder (ii) wird der Verifizierungsfunktion 450 zugänglich gemacht, bevor die Bereitstellungsressource verifiziert wird. In einigen Ausführungsformen ist der zugehörige öffentliche Schlüssel in der Zulassungsrichtlinie 470 gespeichert.
Bei Schritt 530 hängt die Signaturfunktion 440 die digitale Signatur an die Bereitstellungsressource an. Es sollte beachtet werden, dass in Ausführungsformen, die nur einen Message Digest verlangen, der Message Digest und nicht die digitale Signatur an die Ressource angehängt wird. In Ausführungsformen, die eine digitale Signatur verlangen, wird die digitale Signatur an die Bereitstellungsressource angehängt. In einigen Ausführungsformen wird die digitale Signatur als Kommentar in der obersten Ebene der Metadaten der Bereitstellungsressource angehängt. Ausführungsformen der vorliegenden Erfindung berücksichtigen jedoch, dass die digitale Signatur an jeder Stelle der Bereitstellungsressource angehängt werden kann. Zusammen mit der digitalen Signatur kann die Signaturfunktion 440 auch eine Beschreibung davon einbeziehen, welche Abschnitte und/oder Attribute in der Signatur enthalten sind. Anders ausgedrückt bürgt die digitale Signatur für die Verifizierung bestimmter Abschnitte. Die Beschreibung der Abschnitte, die in der Signatur einbezogen sind, kann ein beliebiges Format annehmen, beispielsweise Punktnotation oder Schrägstrichnotation, ist aber nicht darauf beschränkt. Wenn die Konfigurationsdatei beispielsweise eine YAML-Datei ist, kann Punktnotation verwendet werden, um den Pfad zum Abschnitt der YAML-Datei zu beschreiben, die der Signatur zugeordnet ist.
Die angehängte digitale Signatur dient als Möglichkeit zum Sichern und Verifizieren des Ursprungs und der Integrität der Konfigurations- und Bereitstellungs-Metadaten und kann von der Verifizierungsfunktion 450 verwendet werden, um das Vorhandensein und die Authentizität von Signaturen einer oder mehrerer erforderlicher Parteien oder Personen zu verifizieren.
6 zeigt ein Flussdiagramm 600 der Schritte der Verifizierungsfunktion 450 gemäß einer Ausführungsform der vorliegenden Erfindung, die in der Datenverarbeitungsumgebung der 1 bis 4 ausgeführt wird, zum Verifizieren von Signaturen von Bereitstellungsressourcen, etwa Konfigurationsdateien, anhand einer Zulassungsrichtlinie vor der Softwarebereitstellung.
In einer Ausführungsform soll anfänglich Software der Software 460 auf einem oder mehreren Knoten bereitgestellt werden. Eine Zulassungsrichtlinie wurde erstellt und in der Zulassungsrichtlinie 470 gespeichert, wobei die Zulassungsrichtlinie Signaturanforderungen für einen oder mehrere Abschnitte (oder ganze Konfigurationsdateien) angibt, die zu der Softwarebereitstellung gehören. Wenn digitale Signaturen verwendet werden, können außerdem ein oder mehrere öffentliche Schlüssel, die den von der Zulassungsrichtlinie angeforderten Personen zugeordnet sind, für die Verifizierungsfunktion 450 zugänglich sein, und in einigen Ausführungsformen werden solche öffentlichen Schlüssel auch am Aufbewahrungsort der Zulassungsrichtlinie 470 oder in einer anderen Datenbank/einem anderen Repository gespeichert, auf die die Verifizierungsfunktion 450 zugreifen kann.
Bei Schritt 610 fängt die Verifizierungsfunktion 450 Bereitstellungsressourcen ab, bevor die zugehörige Software bereitgestellt wird. In einigen Ausführungsformen ist die Verifizierungsfunktion 450 ein Kubernetes^® Admission Controller. Ein Admission Controller ist ein Stück Code, das Anfragen an einen Kubernetes^®-API-Server abfängt, bevor das Objekt persistent ist, aber nachdem die Anfrage authentifiziert und autorisiert wurde. In Ausführungsformen der vorliegenden Erfindung würde die Verifizierungsfunktion 450 als Validierungssteuerung arbeiten. Validierungssteuerungen können die Objekte, die sie zulassen, nicht ändern. In weiteren Umgebungen kann die Verifizierungsfunktion 450 durch eine beliebige Funktion des Bereitstellungsprogramms 430 gebildet werden, die so arbeitet, dass sie Bereitstellungsressourcen vor der Bereitstellung der entsprechenden Software abfängt.
Bei Schritt 620 erkennt die Verifizierungsfunktion 450 Signaturen, die für die Bereitstellung erforderlich sind. Die Verifizierungsfunktion 450 kann auf eine zuvor gespeicherte Zulassungsrichtlinie zugreifen, beispielsweise eine zuvor gespeicherte Zulassungsrichtlinie, die bei der Zulassungsrichtlinie 470 gespeichert ist. Wie zuvor beschrieben, ist die Zulassungsrichtlinie der spezifischen Software, dem Client, der zu dem einen oder den mehreren Knoten 480 gehört, auf denen die Software bereitgestellt werden soll, dem Entwicklungs-/Bereitstellungsteam oder anderen Faktoren zugeordnet, die vor Beginn der Bereitstellung in der Zulassungsrichtlinie festgelegt und gespeichert wurden. Die Verifizierungsfunktion 450 kann aus der zugehörigen Zulassungsrichtlinie eine oder mehrere erforderliche Signaturen und alle zugeordneten Abschnitte extrahieren, die diesen Signaturen zugeordnet sind.
In Entscheidung 630 ermittelt die Verifizierungsfunktion 450, ob die Signaturen in den abgefangenen Bereitstellungsressourcen vorhanden sind und verifiziert wurden. Die Verifizierungsfunktion 450 vergleicht die in der Konfigurationsdatei oder einer anderen Bereitstellungsressource vorhandenen Signaturen und ermittelt, ob die erforderlichen Signaturen vorhanden sind. Weiter verwendet die Verifizierungsfunktion 450 Hashalgorithmen und/oder öffentliche Schlüssel, die zu jeder der Signaturen gehören, um zu erkennen, ob die Signaturen gültig sind. Die Prüfung der Signaturen erfolgt durch Anwenden einer Hashfunktion auf die Daten und Entschlüsseln der Signatur unter Verwendung des öffentlichen Schlüssels des Signierers. Wenn die resultierenden Hashes gleich sind, kann die Signatur als gültig bestätigt werden. Wie unter Bezugnahme auf die Signaturfunktion 440 beschrieben, ermittelt die Verifizierungsfunktion 450 auf Grundlage des angehängten Pfads oder einer anderen Beschreibung des einen oder der mehreren Abschnitte, welche Abschnitte einer Signatur zugeordnet sind. In einigen Ausführungsformen kann die Zulassungsrichtlinie festlegen, dass mehrere Signaturen für einen Abschnitt erforderlich sein können. In weiteren Ausführungsformen kann die Zulassungsrichtlinie festlegen, dass mindestens eine der folgenden Signaturen für einen bestimmten Abschnitt erforderlich ist. Nicht alle Abschnitte müssen Signaturverifizierungen erfordern.
Wenn die Verifizierungsfunktion 450 feststellt, dass alle erforderlichen Signaturen vorhanden sind und verifiziert wurden (Entscheidung 630, Ja-Zweig), erlaubt die Verifizierungsfunktion 450 die Bereitstellung der Software an dem einen oder den mehreren Knoten 480 (Schritt 640) gemäß den Konfigurations- und Bereitstellungsparametern, was zur Folge hat, dass die Software 490 auf dem einen oder den mehreren zugehörigen Knoten 480 arbeitet.
Wenn die Verifizierungsfunktion 450 feststellt, dass nicht alle erforderlichen Signaturen vorhanden sind und/oder nicht alle erforderlichen Signaturen als authentisch verifiziert werden konnten (Entscheidung 630, Nein-Zweig), verhindert die Verifizierungsfunktion die Bereitstellung der Software an dem einen oder den mehreren Knoten 480. In einigen Ausführungsformen kann die Verifizierungsfunktion 450 zusätzlich zum Verhindern der Durchführung der Bereitstellung einen Fehler oder andere Benachrichtigung erzeugen. Ein derartiger Fehler bzw. eine derartige Mitteilung kann an administrative Benutzer, die der Bereitstellung zugeordnet sind, an Benutzer, die dem einen oder den mehreren Knoten 480 zugeordnet sind und die die Bereitstellung der Software erwartet haben, und/oder an andere Benutzer übermittelt werden. In einigen Ausführungsformen kann die Benachrichtigung Einzelheiten zu den Gründen enthalten, warum die Software nicht bereitgestellt werden konnte. Beispielsweise kann die Verifizierungsfunktion 450 die erforderlichen Signaturen, die in der Bereitstellungsressource fehlten, und/oder Signaturen angeben, die nicht authentifiziert bzw. verifiziert werden konnten. Ein Fehler beim Authentifizieren bzw. Verifizieren einer Signatur kann bedeuten, dass nach dem Erstellen der Signatur durch den Signierer, der eine oder die mehreren Abschnitte geändert wurden, die der Signatur zugeordnet sind. Solche Benachrichtigungen können den einen oder die mehreren administrativen Benutzer, die für die Bereitstellung der Software verantwortlich sind, mit Details versorgen, die es ihnen ermöglichen, etwaige Probleme mit der Bereitstellungsressource zu korrigieren, verschiedene Abschnitte nach Bedarf zurückzuziehen und zu versuchen, die Software erneut bereitzustellen.
7 zeigt eine beispielhafte Zulassungsrichtlinie 700, die verwendet wird, um Signaturanforderungen für die in den 8 und 9 gezeigten Bereitstellungsressourcen durchzusetzen.
Die Zulassungsrichtlinie 700 weist fünf Abschnitte auf, die Signaturanforderungen enthalten. Insbesondere sind dies „spec.replicas“, „spec.template.metadata.*“, „spec.template.spec.containers.image“, „spec.template.spec.containers.ports“ und „spec.template.spec.containers.env.*“. Die Pfade, die die Abschnitte angeben, sind in Punktnotation geschrieben, aber Ausführungsformen der vorliegenden Erfindung berücksichtigen, dass andere Notationsarten oder Beschreibungsmittel zum Kennzeichnen des einen oder der mehreren Abschnitte verwendet werden können. Das „*“ fungiert als Platzhalter und gibt an, dass beispielsweise alle Unterabschnitte des Metadaten-Headers zu signieren sind. Jeder Abschnitt enthält auch eine Signaturanforderung für den Abschnitt, die nach dem Doppelpunkt erscheint. Wie gezeigt, erfordern manche Abschnitte eine einzelne Signatur und andere Abschnitte erfordern mindestens eine Signatur von mehreren aufgelisteten Signaturen (wobei das „oder“ als „| |“ dargestellt ist). Obwohl nicht gezeigt, können bei der Zulassungsrichtlinie 700 andere Zulassungsrichtlinien mehrere Signaturen für einen bestimmten Abschnitt auflisten und erfordern, dass alle aufgelisteten Signaturen vor der Bereitstellung der Software erhalten werden. Obwohl nicht in der Zulassungsrichtlinie 700 enthalten, könnte eine Richtlinie, die mehrere Signaturen erfordert, beispielsweise „spec.template.spec.containers.ports: bobsmith@foo.com&&alicejones@foo.com“ lauten (wobei das „und“ als „&&“ dargestellt ist).
8 zeigt eine beispielhafte Konfigurationsdatei bzw. Bereitstellungsressource, die hierin als Bereitstellungsressource 800 bezeichnet wird. Wie gezeigt, entspricht die Bereitstellungsressource 800 der Zulassungsrichtlinie 700 und ist ein Beispiel einer Bereitstellungsressource, die die Verifizierung durch die Verifizierungsfunktion 450 besteht.
Die Bereitstellungsressource 800 enthält einen Signaturabschnitt 810, der an die Bereitstellungsressource 800 als Kommentar angehängt ist, und der Signaturabschnitt 810 enthält digitale Signaturen und Pfade, die den Anforderungen der Zulassungsrichtlinie 700 entsprechen. Jede Signatur enthält (i) einen Pfad, der den signierten Abschnitt angibt, ein Signierer-Identifikationskennzeichen (in dem gezeigten Beispiel ist das Signierer-Identifikationskennzeichen eine E-Mail-Adresse) und eine verschlüsselte Signatur, die als lange Zeichenkette gezeigt ist. Wie oben beschrieben, wird die verschlüsselte Signatur unter Verwendung eines Hashalgorithmus und/oder eines privaten Schlüssels des Signierers erzeugt. Die Signaturen wurden durch die Signaturfunktion 440 an die Bereitstellungsressource 800 angehängt und können von der Verifizierungsfunktion 450 durch die Zugriffs-Zulassungsrichtlinie 700 der Repository-Zulassungsrichtlinie 470 verifiziert werden. Die Verifizierungsfunktion 450 kann öffentliche Schlüssel verwenden, die zu den Signierern gehören, um zu verifizieren, dass die verschlüsselte Signatur legitim ist und dass die Daten in dem zugeordneten Abschnitt nicht geändert wurden.
Beim Vergleich der Bereitstellungsressource 800 mit der Zulassungsrichtlinie 700 sind alle durch die Zulassungsrichtlinie 700 festgelegten Signaturanforderungen vorhanden. Vorausgesetzt, die Verifizierungsfunktion 450 kann die Integrität der Signaturen verifizieren, kann die Bereitstellungsressource 800 beim Konfigurieren der Software während des Softwarebereitstellungsprozesses verwendet werden.
Im Gegensatz dazu zeigt 9 eine Bereitstellungsressource 900, die die Anforderungen der Zulassungsrichtlinie 700 nicht erfüllt. Beim Prüfen des Signaturabschnitts 910 gibt die Signatur 920 „bobsmith@foo.com“ an, wohingegen die Zulassungsrichtlinie 700 für den Abschnitt „spec.template.metadata.*“ eine Signatur von „chrisbuck@foo.com“ erfordert. Dementsprechend stellt die Verifizierungsfunktion 450 fest, dass eine erforderliche Signatur der Zulassungsrichtlinie 700 fehlt, und verhindert, dass die Bereitstellungsressource 900 zur Konfiguration der entsprechenden Software verwendet wird, die für die Bereitstellung an dem einen oder den mehreren Knoten 480 vorgesehen ist. Obwohl nicht gezeigt, kann die Bereitstellungsressource 900 zusätzlich auch durch eine Signatur behindert werden, die nicht verifiziert werden kann. Wenn beispielsweise eine erforderliche Signatur hinzugefügt wurde, und dann nach dem Hinzufügen der Signatur Daten aus dem zugeordneten Abschnitt geändert werden, wäre die Signatur nicht mehr gültig, da die Änderung des Inhalts des Abschnitts zu einer Fehlanpassung während des Verifizierungsverfahrens führen würde. In einer solchen Situation würde die Verifizierungsfunktion 450 wiederum feststellen, dass die Bereitstellungsressource aufgrund einer ungültigen Signatur nicht für die Softwarebereitstellung verarbeitet werden kann.
Wie zuvor beschrieben, kann die Verifizierungsfunktion 450 einen Fehler bzw. eine Benachrichtigung erzeugen, die die Mängel in der Bereitstellungsressource 900 beschreibt. In diesem speziellen Beispiel kann die Verifizierungsfunktion 450 eine Benachrichtigung erzeugen, die anzeigt, dass „bobsmith@foo.com“ den Abschnitt „spec.template.metadata.*“ der Bereitstellungsressource 900 signiert hat und dass die Zulassungsrichtlinie 700 eine digitale Signatur von „chrisbuck@foo.com“ erfordert. Ferner vorausgesetzt, eine weitere Signatur würde von der Verifizierungsfunktion 450 als ungültig bestimmt, würde die Verifizierungsfunktion 450 veranlassen, dass die Benachrichtigung die ungültige Signatur anzeigt. Solche Informationen könnten von administrativen Benutzern verwendet werden, um die Mängel zu beheben und die Bereitstellungsressource 900 so zu aktualisieren, dass sie die Signaturanforderungen der Zulassungsrichtlinie 700 erfüllt.
Während die 8 und 9 als YAML-Konfigurationsdateien gezeigt sind, sollte angemerkt werden, dass jede Art von Bereitstellungsressource oder Konfigurationsdatei von verschiedenen Ausführungsformen der vorliegenden Erfindung verwendet werden kann.
Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt auf jeder möglichen technischen Integrationsstufe handeln. Das Computerprogrammprodukt kann ein durch einen Computer lesbares Speichermedium (oder -medien) mit durch einen Computer lesbaren Programmanweisungen darauf umfassen, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.
Bei dem durch einen Computer lesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen zur Verwendung durch ein System zur Ausführung von Anweisungen aufbewahren und speichern kann. Bei dem durch einen Computer lesbaren Speichermedium kann es sich zum Beispiel um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder jede geeignete Kombination daraus handeln, ohne auf diese beschränkt zu sein. Zu einer nicht erschöpfenden Liste spezifischerer Beispiele des durch einen Computer lesbaren Speichermediums gehören die Folgenden: eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (SRAM), ein tragbarer Kompaktspeicherplatte-Nur-Lese-Speicher (CD-ROM), eine DVD (digital versatile disc), ein Speicher-Stick, eine Diskette, eine mechanisch codierte Einheit wie zum Beispiel Lochkarten oder erhabene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und jede geeignete Kombination daraus. Ein durch einen Computer lesbares Speichermedium soll in der Verwendung hierin nicht als flüchtige Signale an sich aufgefasst werden, wie zum Beispiel Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder ein anderes Übertragungsmedium ausbreiten (z.B. Lichtwellenleiterkabel durchlaufende Lichtimpulse) oder durch einen Draht übertragene elektrische Signale.
Hierin beschriebene, durch einen Computer lesbare Programmanweisungen können von einem durch einen Computer lesbaren Speichermedium auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetz und/oder ein drahtloses Netzwerk auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, drahtlose Übertragung, Leitwegrechner, Firewalls, Vermittlungseinheiten, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt durch einen Computer lesbare Programmanweisungen aus dem Netzwerk und leitet die durch einen Computer lesbaren Programmanweisungen zur Speicherung in einem durch einen Computer lesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.
Bei durch einen Computer lesbaren Programmanweisungen zum Ausführen von Arbeitsschritten der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, ISA-Anweisungen (Instruction-Set-Architecture), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, zustandssetzende Daten, Konfigurationsdaten für integrierte Schaltungen oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter objektorientierte Programmiersprachen wie Smalltalk, C++ o.ä. sowie prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die durch einen Computer lesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem fernen Computer oder vollständig auf dem fernen Computer oder Server ausgeführt werden. In letzterem Fall kann der fern angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). In einigen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, vor Ort programmierbare Gatter-Anordnungen (FPGA, field programmable gate arrays) oder programmierbare Logikanordnungen (PLA, programmable logic arrays) die durch einen Computer lesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der durch einen Computer lesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.
Aspekte der vorliegenden Erfindung sind hierin unter Bezugnahme auf Ablaufpläne und/oder Blockschaltbilder bzw. Schaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es wird darauf hingewiesen, dass jeder Block der Ablaufpläne und/oder der Blockschaubilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaubildern mittels durch einen Computer lesbare Programmanweisungen ausgeführt werden können.
Diese durch einen Computer lesbaren Programmanweisungen können einem Prozessor eines Computers oder einer anderen programmierbaren Datenverarbeitungseinheit bereitgestellt werden, um eine Maschine zu erzeugen, so dass die über den Prozessor des Computers bzw. der anderen programmierbaren Datenverarbeitungseinheit ausgeführten Anweisungen Mittel zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte erzeugen. Diese durch einen Computer lesbaren Programmanweisungen können auch auf einem durch einen Computer lesbaren Speichermedium gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, so dass das durch einen Computer lesbare Speichermedium, auf dem Anweisungen gespeichert sind, ein Herstellungsprodukt aufweist, darunter Anweisungen, welche Aspekte der/des in dem Block bzw. den Blöcken des Ablaufplans und/oder der Blockschaltbilder bzw. Schaubilder angegebenen Funktion/Schritts umsetzen.
Die durch einen Computer lesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Prozessschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen auf einem Computer ausgeführten Prozess zu erzeugen, so dass die auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit ausgeführten Anweisungen die in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaubilder festgelegten Funktionen/Schritte umsetzen.
Die Ablaufpläne und die Blockschaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaltbildern bzw. Schaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, die eine oder mehrere ausführbare Anweisungen zur Ausführung der bestimmten logischen Funktion(en) aufweisen. In einigen alternativen Ausführungen können die in den Blöcken angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt stattfinden. Zwei nacheinander gezeigte Blöcke können zum Beispiel in Wirklichkeit im Wesentlichen als ein Schritt gleichzeitig, im Wesentlichen gleichzeitig oder in einer teilweise oder vollständig zeitlich überlappenden Weise ausgeführt werden, oder die Blöcke können manchmal je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist ferner anzumerken, dass jeder Block der Blockschaubilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaubildern und/oder den Ablaufplänen durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, welche die festgelegten Funktionen oder Schritte durchführen, oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.
Die Beschreibungen der verschiedenen Ausführungsformen der vorliegenden Erfindung wurden zu Zwecken der Veranschaulichung angegeben, sind aber nicht als erschöpfend oder auf die offenbarten Ausführungsformen beschränkt anzusehen. Viele Modifikationen und Varianten sind für Fachleute offensichtlich, ohne von dem Umfang und dem Geist der Erfindung abzuweichen. Die hierin verwendete Terminologie wurde ausgewählt, um die Grundsätze der Ausführungsform, die praktische Anwendung oder die technische Verbesserung gegenüber Technologien, die am Markt vorhanden sind, am besten zu beschreiben oder anderen Fachleuten zu ermöglichen, die hierin offenbarten Ausführungsformen zu verstehen.

Claims

Von einem Computer umgesetztes Verfahren, aufweisend: Abfangen, durch einen oder mehrere Prozessoren, einer Bereitstellungsressource, die zu Software gehört, bevor die Software an einem Knoten bereitgestellt wird, wobei die Bereitstellungsressource konfiguriert, wie die Software bereitgestellt wird und arbeitet; Verifizieren, durch einen oder mehrere Prozessoren, einer Authentizität einer digitalen Signatur, die in der Bereitstellungsressource vorhanden ist; als Reaktion auf das Verifizieren der Authentizität der digitalen Signatur, Bereitstellen der Software an dem Knoten gemäß der Bereitstellungsressource.
Von einem Computer umgesetztes Verfahren nach Anspruch 1, wobei das Verifizieren der Authentizität der digitalen Signatur ferner aufweist: Abrufen, durch einen oder mehrere Prozessoren, einer Zulassungsrichtlinie, wobei die Zulassungsrichtlinie eine oder mehrere Signaturen angibt, die für die Bereitstellung der Software erforderlich sind; und Verifizieren, durch einen oder mehrere Prozessoren, dass die erforderliche eine oder mehreren Signaturen in der Bereitstellungsressource vorhanden sind.
Von einem Computer umgesetztes Verfahren nach Anspruch 1, ferner aufweisend: Empfangen, durch einen oder mehrere Prozessoren, einer Auswahl eines Abschnitts in der Bereitstellungsressource zum Signieren; Verschlüsseln, durch einen oder mehrere Prozessoren, des ausgewählten Abschnitts mit einer Hashfunktion und einem privaten Schlüssel; und Anhängen, durch einen oder mehrere Prozessoren, einer digitalen Signatur und einer Kennzeichnung des Abschnitts in der Bereitstellungsressource.
Von einem Computer umgesetztes Verfahren nach Anspruch 3, wobei das Verifizieren der Authentizität der digitalen Signatur aufweist: Entschlüsseln, durch einen oder mehrere Prozessoren, der digitalen Signatur; und Vergleichen, durch einen oder mehrere Prozessoren, einer resultierenden Hashfunktion mit einer Hashfunktion, die Daten in dem Abschnitt zugeordnet ist.
Von einem Computer umgesetztes Verfahren nach Anspruch 2, wobei die Zulassungsrichtlinie ferner eine Mehrzahl von Abschnitten der Bereitstellungsressource und eine entsprechende Signatur angibt, die für jeden Abschnitt erforderlich ist.
Von einem Computer umgesetztes Verfahren nach Anspruch 1, wobei die Bereitstellungsressource eine Kubernetes-YAML-Datei ist.
Von einem Computer umgesetztes Verfahren nach Anspruch 3, wobei die digitale Signatur und die Kennzeichnung des Abschnitts in der Bereitstellungsressource an einen Kommentar in Metadaten der obersten Ebene der Bereitstellungsressource angehängt werden.
Computerprogrammprodukt, aufweisend: ein oder mehrere von einem Computer lesbare Speichermedien und Programmanweisungen, die insgesamt auf dem einen oder den mehreren von einem Computer lesbaren Speichermedien gespeichert sind, wobei die Programmanweisungen aufweisen: Programmanweisungen zum Abfangen einer Bereitstellungsressource, die zu Software gehört, bevor die Software an einem Knoten bereitgestellt wird, wobei die Bereitstellungsressource konfiguriert, wie die Software bereitgestellt wird und arbeitet; Programmanweisungen zum Verifizieren einer Authentizität einer digitalen Signatur, die in der Bereitstellungsressource vorhanden ist; Programmanweisungen zum Bereitstellen, als Reaktion auf das Verifizieren der Authentizität der digitalen Signatur, der Software an dem Knoten gemäß der Bereitstellungsressource.
Computerprogrammprodukt nach Anspruch 8, wobei die Programmanweisungen zum Verifizieren der Authentizität der digitalen Signatur ferner aufweisen: Programmanweisungen, die insgesamt auf dem einen oder den mehreren von einem Computer lesbaren Speichermedien gespeichert sind, zum Abrufen einer Zulassungsrichtlinie, wobei die Zulassungsrichtlinie eine oder mehrere Signaturen angibt, die für die Bereitstellung der Software erforderlich sind; und Programmanweisungen, die insgesamt auf dem einen oder den mehreren von einem Computer lesbaren Speichermedien gespeichert sind, zum Verifizieren, dass die erforderliche eine oder mehreren Signaturen in der Bereitstellungsressource vorhanden sind.
Computerprogrammprodukt nach Anspruch 8, ferner aufweisend: Programmanweisungen, die insgesamt auf dem einen oder den mehreren von einem Computer lesbaren Speichermedien gespeichert sind, zum Empfangen einer Auswahl eines Abschnitts in der Bereitstellungsressource zum Signieren; Programmanweisungen, die insgesamt auf dem einen oder den mehreren von einem Computer lesbaren Speichermedien gespeichert sind, zum Verschlüsseln des ausgewählten Abschnitts mit einer Hashfunktion und einem privaten Schlüssel; und Programmanweisungen, die insgesamt auf dem einen oder den mehreren von einem Computer lesbaren Speichermedien gespeichert sind, zum Anhängen einer digitalen Signatur und einer Kennzeichnung des Abschnitts in der Bereitstellungsressource.
Computerprogrammprodukt nach Anspruch 10, wobei die Programmanweisungen zum Verifizieren der Authentizität der digitalen Signatur aufweisen: Programmanweisungen zum Entschlüsseln der digitalen Signatur; und Programmanweisungen zum Vergleichen einer resultierenden Hashfunktion mit einer Hashfunktion, die Daten in dem Abschnitt zugeordnet ist.
Computerprogrammprodukt nach Anspruch 9, wobei die Zulassungsrichtlinie ferner eine Mehrzahl von Abschnitten der Bereitstellungsressource und eine entsprechende Signatur angibt, die für jeden Abschnitt erforderlich ist.
Computerprogrammprodukt nach Anspruch 8, wobei die Bereitstellungsressource eine Kubernetes-YAML-Datei ist.
Computerprogrammprodukt nach Anspruch 10, wobei die digitale Signatur und die Kennzeichnung des Abschnitts in der Bereitstellungsressource an einen Kommentar in Metadaten der obersten Ebene der Bereitstellungsressource angehängt werden.
Computersystem, aufweisend: einen oder mehrere Computerprozessoren, ein oder mehrere von einem Computer lesbare Speichermedien und Programmanweisungen, die insgesamt auf dem einen oder den mehreren von einem Computer lesbaren Speichermedien zur Ausführung durch mindestens einen des einen oder der mehreren Computerprozessoren gespeichert sind, die Programmanweisungen aufweisend: Programmanweisungen zum Abfangen einer Bereitstellungsressource, die Software zugeordnet ist, bevor die Software an einem Knoten bereitgestellt wird, wobei die Bereitstellungsressource konfiguriert, wie die Software bereitgestellt wird und arbeitet; Programmanweisungen zum Verifizieren einer Authentizität einer digitalen Signatur, die in der Bereitstellungsressource vorhanden ist; Programmanweisungen zum Bereitstellen, als Reaktion auf das Verifizieren der Authentizität der digitalen Signatur, der Software an dem Knoten gemäß der Bereitstellungsressource.
Computersystem nach Anspruch 15, wobei die Programmanweisungen zum Verifizieren der Authentizität der digitalen Signatur ferner aufweisen: Programmanweisungen, die insgesamt auf dem einen oder den mehreren von einem Computer lesbaren Speichermedien zur Ausführung durch mindestens einen des einen oder der mehreren Computerprozessoren gespeichert sind, zum Abrufen einer Zulassungsrichtlinie, wobei die Zulassungsrichtlinie eine oder mehrere Signaturen angibt, die für die Bereitstellung der Software erforderlich sind; und Programmanweisungen, die insgesamt auf dem einen oder den mehreren von einem Computer lesbaren Speichermedien zur Ausführung durch mindestens einen des einen oder der mehreren Computerprozessoren gespeichert sind, zum Verifizieren, dass die erforderliche eine oder mehreren Signaturen in der Bereitstellungsressource vorhanden sind.
Computersystem nach Anspruch 15, ferner aufweisend: Programmanweisungen, die insgesamt auf dem einen oder den mehreren von einem Computer lesbaren Speichermedien zur Ausführung durch mindestens einen des einen oder der mehreren Computerprozessoren gespeichert sind, zum Empfangen einer Auswahl eines Abschnitts in der Bereitstellungsressource zum Signieren; Programmanweisungen, die insgesamt auf dem einen oder den mehreren von einem Computer lesbaren Speichermedien zur Ausführung durch mindestens einen des einen oder der mehreren Computerprozessoren gespeichert sind, zum Verschlüsseln des ausgewählten Abschnitts mit einer Hashfunktion und einem privaten Schlüssel; und Programmanweisungen, die insgesamt auf dem einen oder den mehreren von einem Computer lesbaren Speichermedien zur Ausführung durch mindestens einen des einen oder der mehreren Computerprozessoren gespeichert sind, zum Anhängen einer digitalen Signatur und einer Kennzeichnung des Abschnitts in der Bereitstellungsressource.
Computersystem nach Anspruch 17, wobei die Programmanweisungen zum Verifizieren der Authentizität der digitalen Signatur aufweisen: Programmanweisungen zum Entschlüsseln der digitalen Signatur; und Programmanweisungen zum Vergleichen einer resultierenden Hashfunktion mit einer Hashfunktion, die Daten in dem Abschnitt zugeordnet ist.
Computersystem nach Anspruch 16, wobei die Zulassungsrichtlinie ferner eine Mehrzahl von Abschnitten der Bereitstellungsressource und eine entsprechende Signatur angibt, die für jeden Abschnitt erforderlich ist.
Computersystem nach Anspruch 15, wobei die Bereitstellungsressource eine Kubernetes-YAML-Datei ist.