DE112019001481T5

DE112019001481T5 - Selektives bereitstellen gegenseitiger transportschichtsicherheit mittels alternativer servernamen

Info

Publication number: DE112019001481T5
Application number: DE112019001481.1T
Authority: DE
Inventors: Etai Lev-Ran; Shriram Rajagopalan; Zvi Cahana; Idan Zach
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2018-05-21
Filing date: 2019-05-09
Publication date: 2021-01-07
Also published as: JP2021524090A; JP7203444B2; CN112119374B; WO2019224645A1; US10841336B2; GB2586767A; US20190356693A1; GB202019652D0; CN112119374A; GB2586767B

Abstract

Vorliegend werden Beispiele für Methoden zum selektiven Bereitstellen von mTLS mittels alternativer Servernamen beschrieben. Ein beispielhaftes System umfasst einen Prozessor, um in Reaktion auf Erkennen eines Legacy-Indikators einen alternativen Servernamen zu erzeugen. Der Prozessor ist zudem dafür vorgesehen, den alternativen Servernamen einer Adresse eines Pods zuzuordnen. Der Prozessor ist ferner dafür vorgesehen, einen dem Pod zugehörigen Proxy so zu konfigurieren, dass dieser auf Grundlage des alternativen Servernamens selektiv gegenseitige Transportschichtsicherheit (mTLS) bereitstellt.

Description

HINTERGRUND
Die vorliegenden Methoden betreffen gegenseitige Transportschichtsicherheit (mTLS, mutual transport layer security). Konkret betreffen die Methoden selektives Bereitstellen von mTLS mittels alternativer Servernamen.
KU RZDARSTELLU NG
Gemäß einer vorliegend beschriebenen Ausführungsform kann ein System einen Prozessor enthalten, um in Reaktion auf Erkennen eines Legacy-Indikators einen alternativen Servernamen zu erzeugen und den alternativen Servernamen einer Adresse eines Pods zuzuordnen. Der Prozessor kann zudem ferner einen dem Pod zugeordneten Proxy so konfigurieren, dass dieser auf Grundlage des alternativen Servernamens selektiv gegenseitige Transportschichtsicherheit (mTLS) bereitstellt.
Gemäß einer weiteren vorliegend beschriebenen Ausführungsform kann ein Verfahren Erkennen eines Legacy-Indikators über einen Prozessor umfassen. Das Verfahren kann ferner Modifizieren einer Uniform Resource Location (URL) eines Pods über den Prozessor umfassen, um einen alternativen Servernamen zu verwenden. Das Verfahren kann zudem ferner Konfigurieren eines dem Pod zugehörigen Proxys umfassen, um in Reaktion auf Empfangen des alternativen Servernamens die gegenseitige Transportschichtsicherheit (mTLS) zu deaktivieren.
Gemäß einer weiteren vorliegend beschriebenen Ausführungsform kann ein Computerprogrammprodukt zum selektiven Bereitstellen gegenseitiger Transportschichtsicherheit (mTLS) ein durch einen Computer lesbares Speichermedium mit darauf enthaltenem Programmcode umfassen. Bei dem durch einen Computer lesbaren Speichermedium handelt es sich nicht um ein vorübergehendes Signal an sich. Der Programmcode ist durch einen Prozessor ausführbar, um den Prozessor zu veranlassen, eine Mehrzahl von Manifesten auf eine Mehrzahl von Legacy-Indikatoren hin zu überwachen. Der Programmcode kann zudem den Prozessor veranlassen, in mindestens einem der Mehrzahl von Manifesten einen mindestens einem Legacy-Client zugehörigen Legacy-Indikator zu erkennen. Der Programmcode kann zudem den Prozessor veranlassen, in Reaktion auf Erkennen des Legacy-Indikators einen alternativen Servernamen zu erzeugen. Der Programmcode kann zudem den Prozessor veranlassen, den alternativen Servernamen einer Adresse eines Pods zuzuordnen. Der Programmcode kann zudem den Prozessor veranlassen, einen dem Pod zugehörigen Proxy so zu konfigurieren, dass dieser in Reaktion auf Empfangen eines den alternativen Servernamen enthaltenden Servernamenindikators von einem Legacy-Client einen Dienst deaktiviert.
Figurenliste
Ausführungsformen der Erfindung werden nun lediglich beispielhaft unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben, wobei:

1 ein Blockschaubild eines beispielhaften Systems zum selektiven Bereitstellen von mTLS mittels alternativer Servernamen ist;
2 ein Blockschaubild eines beispielhaften Verfahrens ist, das mittels alternativer Servernamen selektiv mTLS bereitstellen kann;
3 ein Blockschaltbild einer beispielhaften Datenverarbeitungseinheit ist, die mittels alternativer Servernamen selektiv mTLS bereitstellen kann;
4 ein Prozessablaufplan einer beispielhaften Cloud-Computing-Umgebung gemäß vorliegend beschriebenen Ausführungsformen ist;
5 ein Prozessablaufplan beispielhafter Abstraktionsmodellschichten gemäß vorliegend beschriebenen Ausführungsformen ist; und
6 ein Beispiel eines materiellen, nichttransienten, durch einen Computer lesbaren Mediums ist, das mittels alternativer Servernamen selektiv mTLS bereitstellen kann.

AUSFÜHRLICHE BESCHREIBUNG
Auf Mikrodiensten beruhende Anwendungen können sich aus mehreren vorliegend als Mikrodienste bezeichneten Diensten zusammensetzen, die mittels eines Netzwerkprotokolls interagieren. Das Netzwerkprotokoll kann beispielsweise Hyper Text Transfer Protocol (HTTP) oder Hyper Text Transfer Protocol Secure (HTTPS) sein oder auf einem „Remote Procedure Call“- (RPC-) System beruhen. In einigen Beispielen kann ein Mikrodienstsystem ein Dienstnetz einsetzen. Ein Dienstnetz kann Komponenten enthalten, die mittels zwischengeschalteter Proxys mittelbar Daten austauschen. Diese Proxys können verwendet werden, um die Handhabung von Datenaustausch zu vereinfachen, und können zudem Stabilität und Sicherheit von Datenaustausch verbessern. Solange der Datenaustausch zwischen den Diensten einer auf Mikrodiensten beruhenden Anwendung die Proxys verwendet, können die Proxys alle Voraussetzungen erfüllen, ohne den Mikrodienst-Code direkt zu beeinflussen. Bei einer beispielhaften Voraussetzung kann es sich um einen Handshake im Rahmen gegenseitiger Transportschichtsicherheit (mTLS) handeln. Gegenseitige („mutual“) TLS, oder mTLS, bezeichnet vorliegend eine Methode zum Durchführen gegenseitiger Berechtigungsprüfung zwischen Clients und Servern. Beispielsweise kann ein Server eine Berechtigungsprüfung seiner selbst gegenüber einem Client beginnen, indem er dem Client ein Zertifikat sendet. Das Zertifikat kann durch die vertrauenswürdige Zertifizierungsstelle signiert sein und den Namen eines Servers enthalten. Der Name kann einen normalen Namen und einen Alternativnamen umfassen. Das Zertifikat 108 kann zudem einen öffentlichen Schlüssel enthalten. Der öffentliche Schlüssel kann von Clients verwendet werden, um einen Zufallswert zu verschlüsseln, der anschließend von einem Server mittels eines dem öffentlichen Schlüssel entsprechenden privaten Schlüssels entschlüsselt und als Beweis der Identität des Servers an den Client zurückgesendet wird. Der Client kann dann in ähnlicher Weise seine Berechtigung gegenüber dem Server nachweisen, indem er eine ähnliche Entschlüsselung eines von dem Server empfangenen Werts durchführt, der mittels eines einem privaten Schlüssel des Clients entsprechenden öffentlichen Schlüssels verschlüsselt ist.
In Dienstnetzumgebungen können auch Anfragen, die nicht durch einen Proxy initiiert wurden, wie beispielsweise Anfragen von einem Legacy-Client, abgefangen und an einen Proxy umgeleitet werden. Die Bezeichnung „Legacy-Client“ bezeichnet vorliegend Clients, die nicht für die Verwendung einer bestimmten Voraussetzung wie beispielsweise mTLS konfiguriert sind. Von Legacy-Clients initiierte Anfragen können Anfragen in Bezug auf Zustandsprüfungen, Zugriff auf Metriken, Status, Introspektion und Daten-Debugging umfassen. Eine Zustandsprüfung kann eine Aktivitätsprüfung oder eine Bereitschaftsprüfung umfassen. Da der Proxy möglicherweise die Identität des Clients nicht kennt, kann der Proxy einen mTLS-Austausch initiieren. Die resultierende Client-Zertifikat-Anfrage zum Beginnen der Berechtigungsprüfung des Clients kann jedoch für den Legacy-Client unerwartet sein, so dass die Verbindung möglicherweise beendet wird. In einigen Beispielen kann ein Legacy-Client eine Zustandsprüfung wie beispielsweise eine Aktivitätsprüfung oder eine Bereitschaftsprüfung durchführen. Beispielsweise kann der Legacy-Client verwendet werden, um die Aktivität oder Bereitschaft einer Anwendungsinstanz in einem Pod zu prüfen. Aktivität bezieht sich vorliegend darauf, ob eine Anwendungsinstanz aktiv ist. Wenn beispielsweise eine Aktivitätsprüfung feststellt, dass eine Anwendungsinstanz inaktiv ist, kann ein Orchestrator die Anwendungsinstanz neu starten. Ein Orchestrator bezeichnet vorliegend ein Container-Verwaltungswerkzeug, das die Bereitstellung einer containerisierten Infrastruktur automatisiert und einen Lastausgleich für die Dienste bereitstellt, die mit Containern erstellt werden. Bereitschaft bezieht sich vorliegend darauf, ob eine Anwendungsinstanz bereit ist, Datenverkehr zu bedienen. Beispielsweise ist eine Anwendungsinstanz möglicherweise zwar aktiv, jedoch nicht bereit, Datenverkehr zu bedienen, weil eine oder mehrere Abhängigkeiten nicht bereit sind. Ein Pod bezeichnet vorliegend eine Gruppe aus einem oder mehreren Prozessen, die möglicherweise in einer containerisierten Umgebung laufen, mit einem gemeinsamen Speicher und Netzwerk und einer Vorgabe für den Betrieb des einen oder der mehreren Container. Ein Pod kann somit dafür verwendet werden, einen anwendungsspezifischen logischen Host zu modellieren. Beispielsweise können der eine oder die mehreren Container in dem Pod eine IP-Adresse und einen Portraum gemeinsam nutzen und einander über localhost finden. Jedem Port kann eine separate IP-Adresse zugewiesen werden, damit Anwendungsinstanzen Ports ohne Konflikte verwenden können. Ein Pod kann verwendet werden, um einen Datenträger wie beispielsweise ein lokales Plattenverzeichnis oder eine Netzwerkplatte zu definieren und den Datenträger gegenüber einem oder mehreren Containern in dem Pod offenzulegen. Anwendungen innerhalb eines Pods können Zugriff auf gemeinsam verwendete Datenträger haben, die als Teil des Pods definiert sein können und zur Einbindung in das Dateisystem jeder Anwendung verfügbar gemacht werden können. Pods können manuell über einen Orchestrator oder über eine Steuereinheit wie beispielsweise eine Zulassungssteuereinheit verwaltet werden.
Gemäß Ausführungsformen der vorliegenden Offenbarung kann ein System mittels alternativer Servernamen selektiv mTLS bereitstellen. Das System kann einen Alternativnamengenerator enthalten, um in Reaktion auf Erkennen eines Legacy-Clients einen alternativen Servernamen zu erzeugen und den alternativen Servernamen einer Adresse eines Pods zuzuordnen. Das System kann zudem einen Proxy-Konfigurator enthalten, um einen dem Pod zugehörigen Proxy so zu konfigurieren, dass dieser in Reaktion auf Empfangen eines den alternativen Servernamen enthaltenden Servernamenindikators einen Dienst deaktiviert.
Die vorliegend beschriebenen Methoden können somit den Einsatz von Legacy-Clients in Dienstnetzsystemen ermöglichen, die mTLS verwenden. Darüber hinaus sind die vorliegend beschriebenen Methoden transparent für Anwendungsinstanzen und erfordern keine Code-Änderungen in Anwendungen oder Clients. Die Methoden können verwendet werden, um mTLS- und Nicht-mTLS-Clients in verschiedene logische Server zu trennen, ohne Client-Code zu beeinflussen oder zu ändern.
In einigen Szenarien können die vorliegend beschriebenen Methoden in einer Cloud-Computing-Umgebung implementiert werden. Wie nachstehend unter Bezugnahme auf zumindest die 3 bis 5 ausführlicher behandelt wird, kann eine Datenverarbeitungseinheit, die so konfiguriert ist, dass sie mittels alternativer Servernamen selektiv mTLS bereitstellt, in einer Cloud-Computing-Umgebung implementiert werden. Es wird vorab angemerkt, dass, auch wenn diese Offenbarung eine Beschreibung über Cloud-Computing enthalten kann, Umsetzungen der hierin dargelegten Lehre nicht auf eine Cloud-Computing-Umgebung begrenzt sind. Stattdessen können Ausführungsformen der vorliegenden Erfindung gemeinsam mit jeder beliebigen Art von jetzt bekannter oder später erfundener Datenverarbeitungsumgebung implementiert werden.
Cloud-Computing ist ein Dienstbereitstellungsmodell 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 Dienstes schnell bereitgestellt und freigegeben werden können. Dieses Cloud-Modell kann mindestens fünf Eigenschaften enthalten, 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 des Dienstes 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 Inanspruchnahme 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 von verschiedenen Client-Einheiten über eine Thin-Client-Schnittstelle wie einen Webbrowser (z.B. webbasierte eMail) 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 Zentrum des Cloud-Computing steht eine Infrastruktur, die ein Netzwerk aus untereinander verbundenen Knoten enthält.
Gemäß 1 zeigt nun ein Blockschaubild ein beispielhaftes System zum selektiven Bereitstellen von mTLS mittels alternativer Servernamen. Das beispielhafte System ist allgemein mit dem Bezugszeichen 100 bezeichnet. Bei dem System 100 kann es sich beispielsweise um ein Dienstnetzsystem handeln. Das System 100 aus 1 umfasst einen mit einem Orchestrator 104 in Datenübertragungsverbindung stehenden Client 102. Bei dem Client kann es sich beispielsweise um einen Nutzer, ein Programm oder einen automatisierten Agenten wie beispielsweise eine automatisierte Bereitstellungspipeline handeln. Bei einem Orchestrator handelt es sich vorliegend um ein System für Workload-Planung oder -Orchestrierung. Das System 100 umfasst zudem einen mit dem Orchestrator 104 in Datenübertragungsverbindung stehenden Registrierungsagenten 106. Das System 100 umfasst eine Alternativnamenregistrierung (HC-APP_B) 108, die vom Registrierungsagenten 106 bei einem Dienstregister 110 registriert werden kann. Dementsprechend steht der Registrierungsagent 106 auch mit dem Dienstregister 110 in Datenübertragungsverbindung. Das Dienstregister 110 steht ferner mit einer ersten Anwendungsinstanz 112 in Datenübertragungsverbindung. Die erste Anwendungsinstanz 112 steht mit einem entsprechenden ersten Sidecar-Proxy 114 in Datenübertragungsverbindung. Ein Sidecar-Proxy bezeichnet vorliegend einen Proxy, der einer bestimmten Anwendungsinstanz zugehörig ist, um der Anwendungsinstanz einen oder mehrere Dienste eines Dienstnetzes bereitzustellen. Der erste Sidecar-Proxy 114 steht mit einem zweiten Sidecar-Proxy 116 in Datenübertragungsverbindung. Das Dienstregister 110 und der zweite Sidecar-Proxy 116 stehen mit einem Transportschichtsicherheit (TLS) verwendenden Agenten 118 in Datenübertragungsverbindung. TLS bezeichnet vorliegend eine Methode für einen Client, eine Berechtigungsprüfung bei einem Server durchzuführen, mit dem er in Datenaustausch steht. Der Agent 118 kann beispielsweise zu einem Orchestrator gehören und kann sicherstellen, dass ein für einen bestimmten Endpunkt oder Knoten geplanter Workload einwandfrei ist. Beispielsweise kann der Agent den Zustand verschiedener gerade laufender Anwendungsinstanzen und Dienste prüfen, indem er deren Zustandsendpunkte anpingt. Bei dem Agenten 118 kann es sich um einen Legacy-Client handeln, der nicht dafür konfiguriert ist, mTLS durchzuführen. Der zweite Sidecar-Proxy 116 steht ferner mit einer dem zweiten Sidecar-Proxy 116 entsprechenden zweiten Anwendungsinstanz 120 in Datenübertragungsverbindung. In einigen Beispielen können die Sidecar-Proxys 114 und 116 dafür konfiguriert sein, mTLS durchzuführen. Die Sidecar-Proxys 114 und 116 können zusammen ein Dienstnetz bilden. Den Sidecar-Proxys 114 und 116 können daher eine oder mehrere Funktionen der Anwendungsinstanzen 112 bzw. 120 übertragen werden. Neben anderen Funktionen wie beispielsweise Berichterstellung und Protokollierung können die Sidecar-Proxys 114 und 116 beispielsweise ermitteln, wie bei Anfragen ein Lastausgleich erfolgen soll, wie mit Ausfällen umgegangen werden soll und wie Metriken zu Anfragen auf konsistente Weise offengelegt werden sollen. Die Sidecar-Proxys 114 und 116 umfassen entsprechende Endpunkte 122 und 124. Bei den Endpunkten 122 und 124 kann es sich beispielsweise um HTTP- oder HTTPS-Endpunkte handeln. Jeder der Endpunkte 122 und 124 kann einen oder mehrere Namen oder Identitäten besitzen. Jeder Endpunkt 122 oder 124 kann mehrere Identitäten besitzen, die mit unterschiedlichen Zwecken verbunden sind. Beispielsweise kann ein Name mit Aktivitätsprüfungen und ein anderer Name mit Bereitschaftsprüfungen verbunden sein. Wie nachstehend noch ausführlicher beschrieben wird, kann es sich bei einem der Namen um einen alternativen Servernamen handeln, der verwendet werden kann, um während einer Zustandsprüfung mTLS zu umgehen. Die Endpunkte 122 und 124 können auch einen Beweis für die Namen oder Identitäten in Form eines zur Berechtigungsprüfung zu verwendenden Zertifikats besitzen.
In dem Beispiel der 1 kann ein Client 102 eine Anfrage an den Orchestrator 104 senden, um eine zweite Anwendungsinstanz 120 bereitzustellen, wie durch einen Pfeil 126 gezeigt ist. In einigen Beispielen kann die Anfrage in Form eines Manifests erfolgen. Bei einem Manifest handelt es sich vorliegend um eine Datei, die neben anderen Informationen einen Namen, zu öffnende Ports, zu verwendende Bezeichnungen, auszuführendes Anwendungsabbild und eine Anzahl auszuführender Instanzen angeben kann. Das Manifest kann vom Orchestrator 104 verwendet werden, um eine oder mehrere Instanzen einer Anwendung zu planen, auszuführen und zu verwalten. Ein Manifest kann von einem Nutzer für jeden zu verwaltenden Workload konfiguriert werden. In einigen Beispielen kann das Manifest zudem Informationen darüber enthalten, wie Zustandsprüfungen für einen Workload auszuführen sind. Beispielsweise kann das Manifest vorgeben, Aktivitätsprüfungen und Bereitschaftsprüfungen mittels alternativer Servernamen gemäß dem nachstehenden beispielhaften Verfahren aus 2 auszuführen. Der Orchestrator 104 kann einen Satz Bereitstellungsbenachrichtigungen an den Registrierungsagenten 106 senden, wie durch einen Pfeil 128 gezeigt ist. Der Registrierungsagent 106 kann einen einer Zustandsprüfung (HC, health check) für die zweite Anwendungsinstanz 120 entsprechenden alternativen Servernamen 108 an das Dienstregister 110 senden, wie durch die Pfeile 130 und 132 angegeben. Beispielsweise kann der Registrierungsagent 106 den alternativen Servernamen erzeugen und den alternativen Servernamen auf Grundlage eines Manifests registrieren, das den alternativen Servernamen vorgibt, der für einen bestimmten Dienst registriert werden soll. In dem Beispiel aus 1 handelt es sich bei dem für eine Zustandsprüfung der zweiten Anwendungsinstanz 120 erzeugten alternativen Servernamen um HC-APP_B. In einigen Beispielen kann der Registrierungsagent 106 die Alternativnamenregistrierung 130 in Reaktion auf eine Anfrage von einem Erweiterungsanbindungspunkt vornehmen. Bei dem Erweiterungsanbindungspunkt kann es sich beispielsweise um eine Zulassungssteuereinheit, eine Erweiterungs-API oder einen Regelkreis handeln.
Weiterhin gemäß 1 kann die erste Anwendungsinstanz 112 einen der Anwendungsinstanz 120 entsprechenden Servernamen APP_B an das Dienstregister 110 senden, wie durch einen Pfeil 134 gezeigt ist. Die erste Anwendungsinstanz 112 kann dann in Reaktion hierauf eine IP-Adresse IPB empfangen. Der erste Sidecar-Proxy 114 kann eine Anfrage nach der IP-Adresse des Servers mit dem Namen APP_B der zweiten Anwendungsinstanz 120 senden, wie durch einen Pfeil 138 angegeben. Der erste Sidecar-Proxy 114 kann dann in Reaktion hierauf die IP-Adresse empfangen, wie durch einen Pfeil 140 gezeigt ist. Der Sidecar-Proxy 114 kann dann mit dem zweiten Sidecar-Proxy 116 mittels der IP-Adresse IPB Daten austauschen. Beispielsweise kann die IP-Adresse dem Endpunkt 124 des der zweiten Anwendungsinstanz 120 zugehörigen zweiten Sidecars 116 entsprechen. Der Sidecar-Proxy 114 kann eine Servernamenanzeige- (SNI, server name indication) Nachricht von APP_B senden, um dem zweiten Sidecar 116 anzuzeigen, dass zwischen dem ersten Sidecar-Proxy 114 und dem zweiten Sidecar-Proxy 116 ein normaler Datenaustausch mittels mTLS erfolgen soll. Bei einer SNI handelt es sich vorliegend um eine Erweiterung des TLS-Computernetzwerkprotokolls, mit der ein Client zu Beginn eines Handshaking-Prozesses anzeigt, mit welchem Hostnamen er sich zu verbinden versucht. Die Verwendung einer SNI ermöglicht es einem Server, mehrere Zertifikate unter der gleichen IP-Adresse und TCP-PortNummer zu präsentieren, so dass mehrere sichere (HTTPS-) Webseiten (oder jeder andere Dienst über TLS) durch die gleiche IP-Adresse bereitgestellt werden können, ohne dass alle diese Seiten das gleiche Zertifikat verwenden müssen. Wenn somit der zweite Sidecar-Proxy 116 die SNI von APP_B empfängt, kann der zweite Sidecar-Proxy 116 so konfiguriert sein, dass er mit dem ersten Sidecar-Proxy 114 eine Berechtigungsprüfung mittels gegenseitiger TLS durchführt. Beispielsweise kann der zweite Sidecar-Proxy 116 ein der jeweiligen SNI entsprechendes Zertifikat verwenden.
Im Gegensatz hierzu erfolgt der Datenaustausch zwischen dem Agenten 118 und dem zweiten Sidecar-Proxy 116 gegebenenfalls nicht mittels mTLS. Der Agent 118 kann stattdessen TLS verwenden, um an der zweiten Anwendungsinstanz 120 eine Zustandsprüfung durchzuführen. In einigen Beispielen kann es sich bei der Zustandsprüfung um eine Aktivitätsprüfung handeln, die verwendet wird, um zu ermitteln, ob eine Anwendungsinstanz neu gestartet werden muss. Beispielsweise kann sich die Anwendungsinstanz in einem Deadlock befinden, in dem die Anwendungsinstanz zwar läuft, jedoch nicht vorankommt, und somit neu gestartet werden muss. In einigen Beispielen läuft die Anwendungsinstanz möglicherweise nicht und muss daher neu gestartet werden. Bei der Zustandsprüfung kann es sich auch um eine Bereitschaftsprüfung handeln, um zu ermitteln, ob eine Anwendungsinstanz bereit ist, einen Workload zu bedienen. Der Agent 118 kann somit eine Anfrage nach einer IP der zweiten Anwendungsinstanz 120 senden und die zugehörige IP-Adresse empfangen, wie durch einen Doppelpfeil 144 angezeigt ist. Beispielsweise kann der Agent das Dienstregister 110 aufrufen, um den Namen HC-APP_B aufzulösen, und in Reaktion hierauf eine IP-Adresse IPB empfangen. Anschließend kann der Agent 118 eine SNI-Nachricht von HC-APP_B senden, um anzuzeigen, dass mTLS im Datenaustausch mit dem zweiten Sidecar-Proxy 116 nicht verwendet werden soll, wie durch einen Pfeil 146 angezeigt ist. Beispielsweise kann der Alternativname als Zustandsprüfungsendpunkt in einem YAML-Bereitstellungsdeskriptor eines Manifests vorgegeben worden sein. Die SNI-Nachricht kann in Klartextform gesendet werden. In Reaktion auf Empfangen der SNI von HC-APP_B kann der zweite Sidecar-Proxy 116 so konfiguriert werden, dass er mit dem Agenten 118 anstelle einer mTLS-Berechtigungsprüfung nur eine TLS-Berechtigungsprüfung durchführt. In einigen Beispielen kann der zweite Sidecar-Proxy 116 seine Berechtigung gegenüber dem Agenten 118 mittels TLS nachweisen und dem Agenten 118 entweder einen Aktivitätsstatus oder einen Bereitschaftsstatus liefern. Somit muss keine Client-Zertifikat-Anfrage an den Agenten 118 gesendet werden, und ein Verbindungsabbruch kann vermieden werden.
Es ist zu beachten, dass das Blockschaubild aus 1 nicht andeuten soll, dass das System 100 sämtliche in 1 gezeigten Komponenten enthalten soll. Vielmehr kann das System 100 weniger oder auch zusätzliche Komponenten enthalten, die nicht in 1 veranschaulicht sind (z.B. zusätzliche Client-Einheiten, Anwendungen, Anwendungsinstanzen, Proxys, Agenten, Register, Arten von Prüfungen usw.). Beispielsweise kann der Orchestrator alternativ eine Zulassungssteuereinheit (nicht gezeigt) aufrufen, die verwendet werden kann, um einen Bereitstellungsdeskriptor umzuschreiben und den ursprünglichen Namen gegebenenfalls durch den Alternativnamen auszutauschen. Beispielsweise kann die Zulassungssteuerung verwendet werden, um Namen in Alternativnamen für Aktivitätssonden oder Bereitschaftssonden in einem Pod zu ändern. Die Zulassungssteuereinheit kann Anfragen an einen API-Server eines Orchestrators abfangen, bevor ein Objekt persistiert, aber nachdem die Anfrage auf Berechtigung geprüft und autorisiert wurde. Anschließend kann die Zulassungssteuereinheit ein empfangenes Manifest prüfen. Die Zulassungssteuereinheit kann einen oder mehrere Dienste wie beispielsweise Zustandsprüfungen in dem Manifest erkennen. Die Zulassungssteuereinheit kann dann eine einer Zustandsprüfung zugehörige URL so ändern, dass sie einen alternativen Servernamen verwendet. Beispielsweise kann die Zulassungssteuereinheit einen oder mehrere Zulassungssteuerungs-Webhooks aufrufen, die der Anfrage entsprechen. Ein Webhook bezeichnet vorliegend jeden Callback- oder Callout-Mechanismus, beispielsweise einen nutzerdefinierten Hypertext-Transfer-Protocol- (HTTP-) Callback. In einigen Beispielen kann ein Erweiterungs-API (nicht gezeigt) verwendet werden, um einen Webhook aufzurufen. Der Webhook kann verwendet werden, um den Bereitstellungsdeskriptor im Manifest so umzuschreiben, dass er für Aktivitätssonden und Bereitschaftssonden den ursprünglichen Namen in einen Alternativnamen ändert. Die Zulassungssteuereinheit kann dann den aktualisierten Bereitstellungsdeskriptor an den Orchestrator zurücksenden, um Pods mit Zustandsprüfungsendpunkten zu erstellen, die dem alternativen Servernamen zugehörig sind. In einigen Beispielen kann das Manifest offline modifiziert werden. Beispielsweise kann das Manifest geprüft und alternative Servernamen in das Manifest eingefügt werden, bevor das Manifest an den Orchestrator 104 gesendet wird. In einigen Beispielen kann es sich bei einem Regelkreis (nicht gezeigt) um ein Programm handeln, das auf Änderungsbenachrichtigungen in interessierenden Objekten überwacht und in Reaktion auf Erkennen der Änderungsbenachrichtigungen Objekte umschreibt. Beispielsweise kann der Regelkreis den gemeinsamen Zustand eines Clusters über einen Anwendungsprogrammierschnittstellen- (API-) Server eines Orchestrators überwachen und Änderungen vornehmen, um den aktuellen Zustand in einen gewünschten Zustand zu ändern. Der API-Server kann über Änderungen wie beispielsweise Erstellung und Löschung verschiedener Objekte benachrichtigen, die durch einen Orchestrator verwaltet werden. Im Unterschied zur Zulassungssteuereinheit, die durch den Orchestrator aufgerufen werden kann, kann ein Regelkreis reaktiv sein und Ereignisse als Benachrichtigungen verarbeiten.
2 ist ein Prozessablaufplan eines beispielhaften Verfahrens, das mittels alternativer Servernamen selektiv mTLS bereitstellen kann. Das Verfahren 200 kann mit jeder geeigneten Datenverarbeitungseinheit wie beispielsweise der Datenverarbeitungseinheit 300 aus 3 umgesetzt werden und wird unter Bezugnahme auf die Systeme 100 aus 1 beschrieben. Beispielsweise können die nachstehend beschriebenen Verfahren durch den Prozessor 302 der Datenverarbeitungseinheit 300 aus 3 umgesetzt werden.
In Block 202 wird ein Legacy-Indikator erkannt. Ein Legacy-Indikator bezeichnet vorliegend einen Indikator, dass eine bestimmte Verbindung nicht mTLS verwenden soll. In einigen Beispielen kann der Legacy-Indikator in Form eines bestimmten Attributs in einem Bereitstellungsmanifest vorliegen. Beispielsweise kann das Manifest einen oder mehrere bereitzustellende Workloads vorgeben. Ein Workload kann jeden Dienst umfassen, der durch eine Anwendungsinstanz oder einen Dienst bereitgestellt werden kann, darunter Webanwendungen bis zu komplexeren, verteilten Backoffice-Verarbeitungssystemen. In einigen Beispielen kann der Legacy-Indikator während der Bereitstellung einer Anwendung erkannt werden. In einigen Beispielen kann eine Bereitstellung verschiedene Objekttypen umfassen, darunter beispielsweise „ReplicaSet“, „Bereitstellung“, „Pod“ usw. Wie vorstehend beschrieben wurde, kann es sich bei einem Pod-Objekt um einen oder mehrere Container handeln, die eine Funktion erfüllen. In einigen Beispielen können Pods direkt erstellt werden. Ein ReplicaSet-Objekt kann verwendet werden, um dynamisch eine Anzahl an Pods einzustellen, die in einem Cluster laufen. Beispielsweise kann die Anzahl an Pods auf Grundlage einer gemeinsamen Vorgabe eingestellt werden, beispielsweise eines auszuführenden Abbilds, einer Konfiguration, offener Ports usw. Ein Orchestrator kann verwendet werden, um sicherzustellen, dass die Objektinstanzen laufen, und behandelt Ausfälle. Bereitstellungsobjekte können verwendet werden, um mehr Funktionalität hinzuzufügen. Beispielsweise können Bereitstellungsobjekte verwendet werden, um laufende Aktualisierungen usw. zu ermöglichen. Beispielsweise kann der Legacy-Indikator während der Bereitstellung eines Pods durch eine Zulassungssteuereinheit erkannt werden. In einigen Beispielen kann der Legacy-Indikator über eine Erweiterungs-Anwendungsprogrammierschnittstelle (API) erkannt werden. Beispielsweise kann eine Zulassungssteuereinheit verwendet werden, um einen Webhook aufzurufen und das Manifest an den Webhook zu senden, um ein Manifest zu prüfen und umzuschreiben, wie nachstehend beschrieben wird. In einigen Beispielen kann der Legacy-Indikator über einen Regelkreis erkannt werden. Beispielsweise kann der Regelkreis Änderungsbenachrichtigungen abonnieren, und in Reaktion auf Erkennen eines neuen Workloads kann der Regelkreis einen Bereitstellungsdeskriptor des neuen Workloads auf Grundlage erkannter Legacy-Indikatoren so modifizieren, dass er einem gewünschten Zustand der Verwendung des alternativen Servernamens entspricht. In einigen Beispielen kann der Legacy-Indikator die Form einer URL in einer expliziten globalen Bereitstellungskonfiguration annehmen, die Containeridentität und jeweilige Legacy-URLs liefert. Beispielsweise kann die Containeridentität einen Abbildnamen und Bezeichnungen umfassen. In einigen Beispielen kann der Legacy-Indikator in Form explizit hinzugefügter Pod-spezifischer Metadaten in Bezeichnungen oder Annotationen vorliegen. In einigen Beispielen kann der Legacy-Indikator erkannt werden, indem ein Abbild einer Bereitstellung in einer Sandbox-Umgebung ausgeführt und auf Vorhandensein bestimmter URL-Muster einschließlich Legacy-Indikatoren getestet wird. In einigen Beispielen kann der Legacy-Indikator erkannt werden, indem verfügbare API-Vorgaben für einen Legacy-Mikrodienst analysiert werden. In diesem Fall kann der Legacy-Indikator in Form eines vorgegebenen spezifischen Legacy-Mikrodienstes vorliegen.
In Block 204 wird ein Uniform Resource Locator (URL) eines Pods so modifiziert, dass er einen alternativen Servernamen verwendet. Beispielsweise kann eine Zulassungssteuereinheit verwendet werden, um die URL des Pods in dem empfangenen Manifest in den alternativen Servernamen zu ändern. Die Zulassungssteuereinheit kann einen Zulassungs-Webhook aufrufen und das neu zu konfigurierende Manifest senden. Die Zulassungssteuereinheit kann ein Manifest mit aktualisierten URLs empfangen, die für Dienste wie beispielsweise Zustandsprüfungen alternative Servernamen verwenden. In einigen Beispielen kann eine Zuordnung des alternativen Servernamens zu dem Pod in einem Dienstregister gespeichert werden. In einigen Beispielen kann eine Sammlung von Pods in einen Dienst mit einem auflösbaren DNS-Namen gruppiert werden. Wenn über den Legacy-Indikator Pods erkannt werden, die Nicht-mTLS-Verbindungen verwenden, kann das System eine alternative Namenzuordnung zu der gleichen Gruppe von Pods erstellen. Beispielsweise kann für den Alternativnamen irgendein beliebiger Name verwendet werden. In einigen Beispielen kann ein Dienstname mit einem anderen DNS-Auflösungsbereich verwendet werden. Beispielsweise kann ein Zustandsprüfungs-Namensraum erstellt werden, und unter dem Zustandsprüfungs-Namensraum kann ein Alternativname mit einem expliziten Verweis auf den ursprünglichen Dienstendpunkt erstellt werden. In einigen Beispielen kann ein spezialisierter DNS-Server so konfiguriert sein, dass er speziell formatierte Alternativnamen wie zustandsprüfung.<ursprünglicher_dienstname> oder kein-mtls.<ursprünglicher_dienstname> auflöst, wobei <ursprünglicher_dienstname> der durch den speziell formatierten Alternativnamen zu ersetzende ursprüngliche Name des Dienstes ist. Somit können, wie vorstehend beschrieben, die URLs automatisch umgeschrieben und im Manifest angegeben werden, was eine völlig transparente Systemmodifikation ohne jegliche Nutzerbeteiligung ermöglicht.
In Block 206 wird ein dem Pod zugehöriger Proxy so konfiguriert, dass er in Reaktion auf Empfangen des alternativen Servernamens die gegenseitige Transportschichtsicherheit (mTLS) deaktiviert. Bei dem Proxy kann es sich beispielsweise um einen Sidecar-Proxy handeln. Der Proxy kann so konfiguriert werden, dass er einigen Servernamen mTLS bereitstellt, in Reaktion auf Empfangen einer den alternativen Servernamen enthaltenden SNI jedoch mTLS deaktiviert und stattdessen TLS verwendet. Der Proxy kann somit abhängig vom empfangenen Servernamen unterschiedliche Unterstützungsdienste für eine Anwendungsinstanz ausführen. Beispielsweise kann somit ein Legacy-Client mittels des alternativen Servernamens eine Zustandsprüfung durchführen. Bei der Zustandsprüfung kann es sich beispielsweise um eine Aktivitätsprüfung oder eine Bereitschaftsprüfung handeln. Der Legacy-Client kann den alternativen Servernamen an einen Proxy senden, der so konfiguriert ist, dass er in Reaktion auf Empfangen des alternativen Servernamens TLS bereitstellt. Beispielsweise kann der Legacy-Client einen den alternativen Servernamen enthaltenden Servernamenindikator an den Proxy senden.
Der Prozessablaufplan der 2 soll nicht andeuten, dass die Arbeitsschritte des Verfahrens 200 in einer bestimmten Reihenfolge ausgeführt werden müssen oder dass in jedem Fall alle Arbeitsschritte des Verfahrens 200 enthalten sein müssen. Zudem kann das Verfahren 200 jede geeignete Anzahl zusätzlicher Arbeitsschritte umfassen. Beispielsweise können andere Formen von Legacy-Indikatoren verwendet werden. Des Weiteren kann in einigen Fällen der Proxy so konfiguriert werden, dass er für Nicht-mTLS-Verbindungen eine andere, nicht standardmäßige Portnummer verwendet, wodurch Standard-Ports zur Verwendung durch mTLS-Verbindungen frei bleiben. Der Proxy kann verschiedene Listener erstellen und für jeden Port eine separate Verarbeitungspipeline anfragen. Zudem wird zwar vorstehend beschrieben, dass die Modifikation von URLs, um alternative Servernamen zu enthalten, automatisch ohne jede Nutzereingabe durchgeführt wird, jedoch kann in einigen Beispielen das System alternativ den Alternativnamen als Attribut offenlegen, um Nutzern zu ermöglichen, andere Systeme so zu konfigurieren, dass sie den Alternativnamen verwenden. Bei dem anderen System kann es sich beispielsweise um ein zentralisiertes Überwachungssystem handeln. Darüber hinaus kann in einigen Beispielen der Alternativname verwendet werden, um andere Systemkomponenten automatisch neu zu konfigurieren. Wenn beispielsweise ein ursprünglicher Dienstname durch eine Ingress-Ressource offengelegt wird, kann das System eine zusätzliche Ingress-Definition erstellen, die die Zustandsprüfungs-URL dem alternativen Dienstnamen zuordnet. Die Ingress-Ressource kann spezifisch für die Zustandsprüfungs-URL und den ursprünglichen Dienstnamen gemacht werden, wodurch nur diese Zuordnung auf den alternativen internen Dienstnamen geändert wird und die anderen URLs dem ursprünglichen internen Dienstnamen zugeordnet bleiben.
3 ist ein Blockschaltbild einer beispielhaften Datenverarbeitungseinheit, die mittels alternativer Servernamen selektiv mTLS bereitstellen kann. Bei der Datenverarbeitungseinheit 300 kann es sich beispielsweise um einen Server, einen Desktop-Computer, einen Laptop-Computer, einen Tablet-Computer oder ein Smartphone handeln. In einigen Beispielen kann es sich bei der Datenverarbeitungseinheit 300 um einen Cloud-Computing-Knoten handeln. Die Datenverarbeitungseinheit 300 kann im allgemeinen Kontext durch ein Computersystem ausführbarer Anweisungen beschrieben werden, beispielsweise Programmmodule, die durch ein Computersystem ausgeführt werden. Allgemein enthalten Programmmodule Routinen, Programme, Objekte, Komponenten, Logik, Datenstrukturen und so weiter, die bestimmte Aufgaben erfüllen oder bestimmte abstrakte Datentypen implementieren. Die Datenverarbeitungseinheit 300 kann in verteilten Cloud-Computing-Umgebungen betrieben werden, in denen Aufgaben durch entfernt angeordnete Verarbeitungseinheiten ausgeführt werden, die durch ein Kommunikationsnetzwerk verbunden sind. In einer verteilten Cloud-Computing-Umgebung können sich Programmmodule sowohl in lokalen als auch in entfernt angeordneten Speichermedien des Computersystems einschließlich Kurzzeit-Speichereinheiten befinden.
Die Datenverarbeitungseinheit 300 kann einen Prozessor 302, der dafür vorgesehen ist, gespeicherte Anweisungen auszuführen, und eine Speichereinheit 304 enthalten, um temporären Speicherplatz für Arbeitsschritte der Anweisungen während des Betriebs bereitzustellen. Bei dem Prozessor kann es sich um einen Einkernprozessor, einen Mehrkernprozessor, ein Datenverarbeitungscluster oder eine beliebige Anzahl weiterer Konfigurationen handeln. Der Speicher 304 kann einen Direktzugriffsspeicher (RAM), einen Nur-Lese-Speicher, einen Flashspeicher oder beliebige andere geeignete Speichersysteme enthalten.
Der Prozessor 302 kann durch eine Systemverbindung 306 (z.B. PCI^®, PCI-Express^® usw.) mit einer Schnittstelle 308 für Eingabe/Ausgabe- (E/A-) Einheiten verbunden sein, die dafür eingerichtet ist, die Datenverarbeitungseinheit 300 mit einer oder mehreren E/A-Einheiten 310 zu verbinden. Zu den E/A-Einheiten 310 können beispielsweise eine Tastatur und eine Zeigeeinheit zählen, wobei die Zeigeeinheit unter anderem ein Touchpad oder einen berührungsempfindlichen Bildschirm umfassen kann. Bei den E/A-Einheiten 310 kann es sich um eingebaute Komponenten der Datenverarbeitungseinheit 300 oder um Einheiten handeln, die extern an die Datenverarbeitungseinheit 300 angeschlossen sind.
Der Prozessor 302 kann durch die Systemverbindung 306 zudem mit einer Anzeigenschnittstelle 312 verbunden sein, die dafür eingerichtet ist, die Datenverbindungseinheit 300 mit einer Anzeigeeinheit 314 zu verbinden. Die Anzeigeeinheit 314 kann einen Anzeigeschirm umfassen, bei dem es sich um eine eingebaute Komponente der Datenverarbeitungseinheit 300 handelt. Die Anzeigeeinheit 314 kann zudem unter anderem einen Computermonitor, Fernseher oder Projektor umfassen, der extern an die Datenverarbeitungseinheit 300 angeschlossen ist. Zudem kann eine Netzwerkschnittstellensteuereinheit (NIC, network interface controller) 316 dafür eingerichtet sein, die Datenverarbeitungseinheit 300 durch die Systemverbindung 306 mit dem Netzwerk 318 zu verbinden. In einigen Ausführungsformen kann die NIC 316 Daten mittels jeder geeigneten Schnittstelle oder jedes geeigneten Protokolls übertragen, unter anderem beispielsweise Internet Small Computer System Interface. Bei dem Netzwerk 318 kann es sich unter anderem um ein Zellennetz, ein Funknetz, ein Weitverkehrsnetz (WAN), ein lokales Netz (LAN) oder das Internet handeln. Eine externe Datenverarbeitungseinheit 320 kann durch das Netzwerk 318 mit der Datenverarbeitungseinheit 300 verbunden sein. In einigen Beispielen kann es sich bei der externen Datenverarbeitungseinheit 320 um einen externen Webserver 320 handeln. In einigen Beispielen kann es sich bei der externen Datenverarbeitungseinheit 320 um einen Cloud-Computing-Knoten handeln.
Der Prozessor 302 kann durch die Systemverbindung 306 zudem mit einer Speichereinheit 322 verbunden sein, die ein Festplattenlaufwerk, ein optisches Laufwerk, einen USB-Flashspeicher, eine Anordnung von Laufwerken oder beliebige Kombinationen aus diesen umfassen kann. In einigen Beispielen kann die Speichereinheit ein Indikatorerkennungsmodul 324, ein Alternativnamengeneratormodul 326 und ein Proxy-Konfiguratormodul 328 umfassen. Das Indikatorerkennungsmodul 324 kann einen Legacy-Indikator erkennen. Beispielsweise kann das Indikatorerkennungsmodul 324 ein Manifest empfangen und einen Legacy-Indikator in dem Manifest erkennen. Bei dem Legacy-Indikator kann es sich um ein bestimmtes Attribut in einem Manifest, Pod-spezifische Metadaten, ein bestimmtes URL-Muster, das durch Ausführen eines Abbilds einer Bereitstellung erzeugt wird, oder einen Legacy-Mikrodienst in einer Anwendungsprogrammierschnittstellen- (API-) Vorgabe handeln, wie vorstehend erörtert wurde. Der Legacy-Indikator kann den möglichen Zugriff eines Legacy-Clients anzeigen. Bei dem Legacy-Client kann es sich beispielsweise um einen Agenten handeln, der Transportschichtsicherheit (TLS) verwendet, um eine Zustandsprüfung oder einen beliebigen anderen Dienst auszuführen. Das Alternativnamengeneratormodul 326 kann in Reaktion auf Erkennen eines Legacy-Clients einen alternativen Servernamen erzeugen. Das Alternativnamengeneratormodul 326 kann zudem den alternativen Servernamen einer Adresse eines Pods zuordnen. Der Pod kann beispielsweise einen Endpunkt eines Sidecar-Proxys umfassen. In einigen Beispielen kann das Alternativnamengeneratormodul 326 eine URL des Pods auf Grundlage des alternativen Servernamens modifizieren. Das Alternativnamengeneratormodul 326 kann über eine Zulassungssteuereinheit, eine Erweiterungs-API oder einen Regelkreis implementiert werden. Das Proxy-Konfiguratormodul 328 kann einen dem Pod zugehörigen Proxy so konfigurieren, dass dieser auf Grundlage des alternativen Servernamens selektiv einen Dienst bereitstellt. Beispielsweise kann das Konfiguratormodul 328 den dem Pod zugehörigen Proxy so konfigurieren, dass dieser in Reaktion auf Empfangen eines den alternativen Servernamen enthaltenden Servernamenindikators selektiv einen Dienst deaktiviert. Beispielsweise kann es sich bei dem deaktivierten Dienst um mTLS handeln. Der Prozessor 302 kann Daten für eine Anwendungsinstanz oder einen Dienst mittels des konfigurierten Proxys übertragen. In einigen Beispielen kann der Prozessor 302 Dienste für eine Anwendungsinstanz mittels des konfigurierten Proxys bereitstellen. Beispielsweise kann der Prozessor Berechtigungsnachweisdienste wie beispielsweise mTLS- oder TLS-Dienste mittels des konfigurierten Proxys bereitstellen.
Es ist zu beachten, dass das Blockschaubild aus 3 nicht andeuten soll, dass die Datenverarbeitungseinheit 300 sämtliche in 3 gezeigten Komponenten enthalten soll. Vielmehr kann die Datenverarbeitungseinheit 300 weniger oder zusätzliche Komponenten enthalten, die in 3 nicht veranschaulicht sind (z.B. zusätzliche Speicherkomponenten, eingebettete Steuereinheiten, Module, zusätzliche Netzwerkschnittstellen usw.). Des Weiteren kann jede der Funktionalitäten des Indikatorerkennungsmoduls 324, des Alternativnamengeneratormoduls 326 und des Proxy-Konfiguratormoduls 328 teilweise oder ganz in Hardware und/oder im Prozessor 302 implementiert werden. Beispielsweise kann die Funktionalität unter anderem mit einer anwendungsspezifischen integrierten Schaltung, in einer eingebetteten Steuereinheit implementierter Logik oder als in dem Prozessor 302 implementierte Logik implementiert werden. In einigen Ausführungsformen können die Funktionalitäten des Indikatorerkennungsmoduls 324, des Alternativnamengeneratormoduls 326 und des Proxy-Konfiguratormoduls 328 mit Logik implementiert werden, wobei die Logik vorliegend jede geeignete Hardware (unter anderem z.B. einen Prozessor), Software (unter anderem z.B. eine Anwendung), Firmware oder jede geeignete Kombination aus Hardware, Software und Firmware umfassen kann. Beispielsweise können die Funktionalitäten des Indikatorerkennungsmoduls 324, des Alternativnamengeneratormoduls 326 und des Proxy-Konfiguratormoduls 328 in einem Erweiterungsanbindungspunkt implementiert werden. Bei dem Erweiterungsanbindungspunkt kann es sich beispielsweise um eine Zulassungssteuereinheit, einen Erweiterungs-API-Server oder einen Regelkreis handeln. Eine Zulassungssteuereinheit kann ein Manifest prüfen und modifizieren, bevor der Pod erzeugt wird. Beispielsweise kann die Zulassungssteuereinheit einen oder mehrere Zulassungssteuerungs-Webhooks aufrufen, die der Anfrage entsprechen. Die Webhooks können den Bereitstellungsdeskriptor im Manifest so umschreiben, dass er für Aktivitätssonden und Bereitschaftssonden den ursprünglichen Namen in einen Alternativnamen ändert. Ein Erweiterungs-API-Server kann einen Zulassungsanbindungspunkt aufrufen. Beispielsweise kann der Erweiterungs-API-Server einen Workload empfangen, einen Erweiterungspunkt mit dem empfangenen Workload aufrufen und einen modifizierten Bereitstellungsdeskriptor empfangen, der mindestens einen Uniform Resource Locator (URL) enthält, der den alternativen Servernamen verwendet. Der Regelkreis kann den gemeinsamen Zustand eines Clusters über einen API-Server eines Orchestrators überwachen und Änderungen vornehmen, um den aktuellen Zustand in einen gewünschten Zustand zu ändern. Beispielsweise kann der Regelkreis Änderungsbenachrichtigungen abonnieren und in Reaktion auf Erkennen eines neuen Workloads einen Bereitstellungsdeskriptor des neuen Workloads so modifizieren, dass er einem gewünschten Zustand der Verwendung des alternativen Servernamens entspricht.
In 4 ist veranschaulichend eine Cloud-Computing-Umgebung 400 dargestellt. Wie gezeigt ist, weist die Cloud-Computing-Umgebung 400 einen oder mehrere Cloud-Computing-Knoten 402 auf, mit denen von Cloud-Nutzern verwendete lokale Datenverarbeitungseinheiten wie der elektronische Assistent (PDA, personal digital assistant) oder das Mobiltelefon 404A, der Desktop-Computer 404B, der Laptop-Computer 404C und/oder das Automobil-Computer-System 404N Daten austauschen können. Die Knoten 402 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 400, Infrastruktur, Plattformen und/oder Software als Dienste anzubieten, für die ein Cloud-Nutzer keine Ressourcen auf einer lokalen Datenverarbeitungseinheit vorhalten muss. Es wird angemerkt, dass die in 4 gezeigten Arten von Datenverarbeitungseinheiten 404A-N lediglich als beispielhaft zu verstehen sind und dass die Datenverarbeitungsknoten 402 und die Cloud-Computing-Umgebung 400 mit jedweder Art von Datenverarbeitungseinheit über jedwede Art von Netzwerk und/oder netzwerkadressierbarer Verbindung (z.B. unter Verwendung eines Webbrowsers) Daten austauschen können.
5 zeigt eine Gruppe von durch die Cloud-Computing-Umgebung 400 (4) bereitgestellten funktionellen Abstraktionsschichten. Es sei vorab angemerkt, dass die in 5 gezeigten Komponenten, Schichten und Funktionen als lediglich veranschaulichend zu verstehen sind und Ausführungsformen der Erfindung hierauf nicht beschränkt sind. Wie abgebildet ist, werden die folgenden Schichten und entsprechenden Funktionen bereitgestellt.
Eine Hardware- und Software-Schicht 500 enthält Hardware- und Software-Komponenten. Zu Beispielen für Hardware-Komponenten zählen Großrechner, in einem Beispiel zSeries^®-Systeme von IBM^®, Server mit RISC- (Reduced Instruction Set Computer, Computer mit reduziertem Befehlssatz) Architektur, in einem Beispiel pSeries^®-Systeme von IBM, xSeries^®-Systeme von IBM, BladeCenter^®-Systeme von IBM, Speichereinheiten, Netzwerke und Vernetzungskomponenten. Zu Beispielen für Software-Komponenten zählen Netzwerk-Anwendungsserversoftware, in einem Beispiel die Anwendungsserversoftware WebSphere^® von IBM, und Datenbank-Software, in einem Beispiel die Datenbank-Software DB2^® von IBM. (IBM, zSeries, pSeries, xSeries, BladeCenter, WebSphere und DB2 sind in vielen Rechtssystemen weltweit eingetragene Marken der International Business Machines Corporation.)
Die Virtualisierungsschicht 502 stellt eine Abstraktionsschicht bereit, von der aus folgende Beispiele virtueller Einheiten bereitgestellt werden können: virtuelle Server, virtueller Speicher, virtuelle Netzwerke, einschließlich virtueller privater Netzwerke, virtuelle Anwendungen und Betriebssysteme und virtuelle Clients. In einem Beispiel kann die Verwaltungsschicht 504 die nachstehend beschriebenen Funktionen bereitstellen. Ressourcenbereitstellung stellt dynamische Beschaffung von Datenverarbeitungsressourcen und anderen Ressourcen bereit, die verwendet werden, um innerhalb der Cloud-Computing-Umgebung Aufgaben auszuführen. Messung und Preisermittlung stellen Kostenüberwachung für innerhalb der Cloud-Computing-Umgebung genutzte Ressourcen sowie Abrechnung und Rechnungsstellung für die Inanspruchnahme dieser Ressourcen bereit. In einem Beispiel können diese Ressourcen Anwendungs-Software-Lizenzen aufweisen. Sicherung (nicht gezeigt) stellt Identitätsprüfung für Cloud-Kunden und Aufgaben sowie Schutz für Daten und andere Ressourcen bereit. Ein Nutzerportal stellt Zugang zur Cloud-Computing-Umgebung für Kunden und Systemadministratoren bereit. Dienstgüte-Verwaltung stellt eine Zuteilung und Verwaltung von Cloud-Computing-Ressourcen derart bereit, dass erforderliche Dienstgüten erfüllt werden. Ein Planen und Erfüllen von Vereinbarungen zum Dienstumfang (SLA, Service Level Agreement) (nicht gezeigt) stellt die Vorab-Anordnung und die Beschaffung von Cloud-Computing-Ressourcen, für die eine zukünftige Anforderung vorausgesehen wird, gemäß einem SLA bereit. Ein Dienstnetz stellt Infrastrukturdienste wie Routing, Sicherheit und Metriken bereit.
Eine Workload-Schicht 506 stellt Beispiele für die Funktionalität bereit, für welche die Cloud-Computing-Umgebung verwendet werden kann. Zu Beispielen für Workloads und Funktionen, die von dieser Schicht bereitgestellt werden können, gehören: Abbildung und Navigation; Software-Entwicklung und Lebenszyklusverwaltung; Bereitstellung von Ausbildung in virtuellen Klassenzimmern; Datenanalytikverarbeitung; Transaktionsverarbeitung; und mobiler Desktop.
Bei den vorliegenden Methoden kann es sich um ein System, ein Verfahren oder ein Computerprogrammprodukt handeln. Das Computerprogrammprodukt kann (ein) durch einen Computer lesbare(s) Speichermedium (oder -medien) umfassen, auf dem/denen durch einen Computer lesbare Programmanweisungen gespeichert ist/sind, 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 eine Einheit zur Ausführung von Anweisungen behalten 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 gehobene 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. ein 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 umfassen. 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 Methoden kann es sich um Assembler-Anweisungen, ISA-Anweisungen (Instruction-Set-Architecture), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, zustandssetzende Daten oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter eine objektorientierte Programmiersprache wie Smalltalk, C++ o.ä. sowie herkömmliche 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 entfernt 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 Methoden sind hierin unter Bezugnahme auf Ablaufpläne und/oder Blockschaltbilder bzw. Schaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Methoden beschrieben. Es wird darauf hingewiesen, dass jeder Block der Ablaufpläne und/oder der Blockschaltbilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaltbildern mittels durch einen Computer lesbarer Programmanweisungen ausgeführt werden können.
Diese durch einen Computer lesbaren Programmanweisungen können einem Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die über den Prozessor des Computers bzw. der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen ein Mittel zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder 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 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 Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte umsetzen.
6 zeigt ein Blockschaltbild eines beispielhaften physischen, nichttransienten, durch einen Computer lesbaren Mediums 600, das mittels alternativer Servernamen selektiv mTLS bereitstellen kann. Auf das physische, nichttransiente, durch einen Computer lesbare Medium 600 kann durch einen Prozessor 602 über eine Computerverbindung 604 zugegriffen werden. Des Weiteren kann das physische, nichttransiente, durch einen Computer lesbare Medium 600 Code enthalten, um den Prozessor 602 anzuweisen, die Arbeitsschritte des Verfahrens 200 aus vorstehender 2 durchzuführen.
Die verschiedenen vorliegend behandelten Software-Komponenten können auf dem physischen, nichttransienten, durch einen Computer lesbaren Medium 600 gespeichert sein, wie in 6 gezeigt ist. Beispielsweise enthält ein Indikatorerkennungsmodul 606 Code, um Manifeste auf Legacy-Indikatoren hin zu überwachen. Zudem enthält das Indikatorerkennungsmodul 606 Code, um einen einem Legacy-Client zugehörigen Legacy-Indikator in einem Manifest zu erkennen. In einigen Beispielen kann das Indikatorerkennungsmodul 606 zudem Code enthalten, um ein Manifest zu prüfen und zu modifizieren, bevor der Pod erzeugt wird. In einigen Beispielen kann das Indikatorerkennungsmodul 606 zudem Code enthalten, um den Legacy-Indikator während einer Bereitstellung einer Anwendung zu erkennen. Ein Alternativnamengeneratormodul 608 enthält Code, um in Reaktion auf Erkennen des Legacy-Indikators einen alternativen Servernamen zu erzeugen. Das Alternativnamengeneratormodul 608 enthält zudem Code, um den alternativen Servernamen einer Adresse eines Pods zuzuordnen. In einigen Beispielen enthält das Alternativnamengeneratormodul 608 zudem Code, um eine Zuordnung des alternativen Servernamens zu dem Pod in einem Dienstregister zu speichern. Ein Proxy-Konfiguratormodul 610 enthält Code, um einen dem Pod zugehörigen Proxy so zu konfigurieren, dass dieser in Reaktion auf Empfangen eines den alternativen Servernamen enthaltenden Servernamenindikators von dem Legacy-Client einen Dienst deaktiviert. Beispielsweise kann das Proxy-Konfiguratormodul 610 Code enthalten, um den Proxy so zu konfigurieren, dass dieser in Reaktion auf Empfangen des den alternativen Servernamen enthaltenden Servernamenindikators von einem Legacy-Client eine gegenseitige Transportschichtsicherheit (mTLS) deaktiviert. In einigen Beispielen kann das Proxy-Konfiguratormodul 610 Code enthalten, um den Proxy so zu konfigurieren, dass dieser in Reaktion auf Empfangen des den alternativen Servernamen aufweisenden Servernamenindikators von dem Legacy-Client einen alternativen Dienst bereitstellt. Beispielsweise kann das Proxy-Konfiguratormodul 610 Code enthalten, um den Proxy so zu konfigurieren, dass dieser in Reaktion auf Empfangen des den alternativen Servernamen enthaltenden Servernamenindikators von dem Legacy-Client TLS bereitstellt. In einigen Beispielen kann der Legacy-Client an einer dem Proxy zugehörigen Anwendungsinstanz mittels des alternativen Servernamens eine Zustandsprüfung durchführen. Bei der Zustandsprüfung kann es sich beispielsweise um eine Aktivitätsprüfung oder eine Bereitschaftsprüfung handeln. Es ist zu beachten, dass abhängig von der jeweiligen Anwendung eine beliebige Anzahl in 6 nicht gezeigter zusätzlicher Software-Komponenten in dem physischen, nichttransienten, durch einen Computer lesbaren Medium 600 umfasst sein kann.
Die Ablaufpläne und die Blockschaltbilder bzw. Schaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Implementierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Methoden. 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 dem Block 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 gleichzeitig 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 Blockschaltbilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaltbildern 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. Es ist zu beachten, dass abhängig von der konkreten Anwendung eine beliebige Anzahl in 6 nicht gezeigter zusätzlicher Software-Komponenten in dem physischen, nichttransienten, durch einen Computer lesbaren Medium 600 umfasst sein kann.
Die Beschreibungen der verschiedenen Ausführungsformen der vorliegenden Methoden wurden für Zwecke der Veranschaulichung dargelegt, sind jedoch nicht als abschließend oder auf die Ausführungsformen beschränkt zu verstehen. Für den Fachmann sind viele Abwandlungen und Variationen ersichtlich, ohne vom Umfang und Grundgedanken der beschriebenen Ausführungsformen abzuweichen. Die hierin verwendete Terminologie wurde gewählt, um bestmöglich die Grundgedanken der Ausführungsformen, der praktischen Anwendung oder technischen Verbesserung gegenüber den auf dem Markt erhältlichen Technologien zu erklären oder um dem Fachmann das Verständnis der hierin offenbarten Ausführungsformen zu ermöglichen.

Claims

System, das einen Prozessor aufweist, um: in Reaktion auf Erkennen eines Legacy-Indikators einen alternativen Servernamen zu erzeugen und den alternativen Servernamen einer Adresse eines Pods zuzuordnen; und einen dem Pod zugehörigen Proxy so zu konfigurieren, dass dieser auf Grundlage des alternativen Servernamens selektiv gegenseitige Transportschichtsicherheit (mTLS) bereitstellt.
System nach Anspruch 1, wobei das System eine Zulassungssteuereinheit aufweist, um ein Manifest zu prüfen und zu modifizieren, bevor der Pod erzeugt wird.
System nach Anspruch 1, wobei das System einen Erweiterungs-Anwendungsprogrammierschnittstellen- (API-) Server aufweist, um einen Workload zu empfangen, einen Erweiterungspunkt mit dem empfangenen Workload aufzurufen und einen modifizierten Bereitstellungsdeskriptor zu empfangen, der mindestens einen Uniform Resource Locator (URL) aufweist, der den alternativen Servernamen verwendet.
System nach Anspruch 1, wobei das System einen Regelkreis aufweist, um Änderungsbenachrichtigungen zu abonnieren und in Reaktion auf Erkennen eines neuen Workloads einen Bereitstellungsdeskriptor des neuen Workloads so zu modifizieren, dass er einem gewünschten Zustand der Verwendung des alternativen Servernamens entspricht.
System nach Anspruch 1, wobei der Legacy-Indikator ein bestimmtes Attribut in einem Manifest, Pod-spezifische Metadaten, ein bestimmtes URL-Muster, das durch Ausführen eines Abbilds einer Bereitstellung erzeugt wird, oder einen Legacy-Mikrodienst in einer Anwendungsprogrammierschnittstellen- (API-) Vorgabe aufweist.
System nach Anspruch 1, wobei ein dem erkannten Legacy-Client-Zugriff zugehöriger Legacy-Client einen Agenten aufweist, der Transportschichtsicherheit (TLS) verwendet, um eine Zustandsprüfung durchzuführen.
System nach Anspruch 1, wobei der Prozessor dafür vorgesehen ist, mittels des konfigurierten Proxys Dienste für eine Anwendungsinstanz in dem Pod bereitzustellen.
Durch einen Computer implementiertes Verfahren, umfassend: über einen Prozessor erfolgendes Erkennen eines Legacy-Indikators, durch den Prozessor erfolgendes Modifizieren einer Uniform Resource Location (URL) eines Pods, um einen alternativen Servernamen zu verwenden, und Konfigurieren eines dem Pod zugehörigen Proxys, um in Reaktion auf Empfangen des alternativen Servernamens die gegenseitige Transportschichtsicherheit (mTLS) zu deaktivieren.
Durch einen Computer implementiertes Verfahren nach Anspruch 8, wobei das Erkennen des Legacy-Indikators Empfangen eines Manifests und Senden des Manifests an einen Webhook zur Prüfung umfasst.
Durch einen Computer implementiertes Verfahren nach Anspruch 8, wobei das Erkennen des Legacy-Indikators Abonnieren von Änderungsbenachrichtigungen umfasst, die einen neuen Workload erkennen, der den Legacy-Indikator aufweist.
Durch einen Computer implementiertes Verfahren nach Anspruch 8, wobei das Erkennen des Legacy-Indikators Ausführen eines Abbilds einer Bereitstellung in einer Sandbox-Umgebung und Prüfen auf Vorhandensein eines bestimmten URL-Musters umfasst, das den Legacy-Indikator aufweist.
Durch einen Computer implementiertes Verfahren nach Anspruch 8, wobei das Modifizieren der URL Umschreiben eines Manifests über einen Webhook umfasst.
Durch einen Computer implementiertes Verfahren nach Anspruch 8, umfassend Offenlegen des Alternativnamens als Attribut, um andere Systeme so zu konfigurieren, dass sie den Alternativnamen verwenden.
Durch einen Computer implementiertes Verfahren nach Anspruch 8, umfassend automatisches Neukonfigurieren einer anderen Systemkomponente mittels des Alternativnamens.
Computerprogrammprodukt zum selektiven Bereitstellen gegenseitiger Transportschichtsicherheit (mTLS), wobei das Computerprogrammprodukt ein durch einen Computer lesbares Speichermedium mit darauf enthaltenem Programmcode aufweist, wobei das durch einen Computer lesbare Speichermedium kein transientes Signal an sich ist, wobei der Programmcode durch einen Prozessor ausführbar ist, um den Prozessor zu Folgendem zu veranlassen: eine Mehrzahl von Manifesten auf eine Mehrzahl von Legacy-Indikatoren hin zu überwachen, in mindestens einem der Mehrzahl von Manifesten einen mindestens einem Legacy-Client zugehörigen Legacy-Indikator zu erkennen, in Reaktion auf Erkennen des Legacy-Indikators einen alternativen Servernamen zu erzeugen, den alternativen Servernamen einer Adresse eines Pods zuzuordnen und einen dem Pod zugehörigen Proxy so zu konfigurieren, dass dieser in Reaktion auf Empfangen eines den alternativen Servernamen aufweisenden Servernamenindikators von einem Legacy-Client einen Dienst deaktiviert.
Computerprogrammprodukt nach Anspruch 15, das ferner Programmcode aufweist, der durch den Prozessor ausführbar ist, um ein Manifest zu prüfen und zu modifizieren, bevor der Pod erzeugt wird.
Computerprogrammprodukt nach Anspruch 15, das ferner Programmcode aufweist, der durch den Prozessor ausführbar ist, um den Legacy-Indikator während einer Bereitstellung einer Anwendung zu erkennen.
Computerprogrammprodukt nach Anspruch 15, das ferner Programmcode aufweist, der durch den Prozessor ausführbar ist, um eine Zuordnung des alternativen Servernamens zu dem Pod in einem Dienstregister zu speichern.
Computerprogrammprodukt nach Anspruch 15, das ferner Programmcode aufweist, der durch den Prozessor ausführbar ist, um den Proxy so zu konfigurieren, dass dieser in Reaktion auf Empfangen des den alternativen Servernamen aufweisenden Servernamenindikators von dem Legacy-Client Transportschichtsicherheit (TLS) bereitstellt.
Computerprogrammprodukt nach Anspruch 15, das ferner Programmcode aufweist, der durch den Prozessor ausführbar ist, um den Proxy so zu konfigurieren, dass dieser in Reaktion auf Empfangen des den alternativen Servernamen aufweisenden Servernamenindikators eine gegenseitige Transportschichtsicherheit (mTLS) deaktiviert.