DE202016008055U1 - Sichere Konfiguration von Cloud-Computerknoten - Google Patents

Sichere Konfiguration von Cloud-Computerknoten Download PDF

Info

Publication number
DE202016008055U1
DE202016008055U1 DE202016008055.6U DE202016008055U DE202016008055U1 DE 202016008055 U1 DE202016008055 U1 DE 202016008055U1 DE 202016008055 U DE202016008055 U DE 202016008055U DE 202016008055 U1 DE202016008055 U1 DE 202016008055U1
Authority
DE
Germany
Prior art keywords
configuration
node
information
network
computer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE202016008055.6U
Other languages
English (en)
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Google LLC
Original Assignee
Google LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Google LLC filed Critical Google LLC
Priority to DE202016008055.6U priority Critical patent/DE202016008055U1/de
Publication of DE202016008055U1 publication Critical patent/DE202016008055U1/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0866—Checking the configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

Nichtflüchtiges computerlesbares Medium, das Instruktionen speichert, deren Ausführung mindestens einen Prozessor zur Ausführung von Operationen veranlasst, umfassend: das Empfangen, über ein Netzwerk, einer Konfigurationsanforderung von einem bestimmten Knoten im Cloud-Computernetzwerk, wobei die Konfigurationsanforderung Knoteninformationen für den entsprechenden Knoten beinhaltet; das Verifizieren, dass der betroffene Knoten für die Konfiguration autorisiert ist, basierend zumindest zum Teil auf der Knoteninformation; als Antwort auf das Verifizieren, dass der entsprechende Knoten für die Konfiguration autorisiert wurde, das Identifizieren der Konfigurationsmaßnahmen am entsprechenden Knoten, basierend zumindest zum Teil auf der Knoteninformation; und das Senden, über das Netzwerk, eines Konfigurationsbefehls, der einer oder mehreren der identifizierten Konfigurationsmaßnahmen am jeweiligen Knoten entspricht, worin der bestimmte Knoten den Konfigurationsbefehl bei Erhalt ausführt, um die entsprechenden Konfigurationsmaßnahmen durchzuführen.

Description

  • HINTERGRUND
  • Diese Spezifikation bezieht sich im Allgemeinen auf die sicheren Konfigurationen von Knoten in einem Cloud-Computersystem. Unter Schutz gestellt werden und Gegenstand des Gebrauchsmusters sind, entsprechend den Vorschriften des Gebrauchsmustergesetzes, lediglich Vorrichtungen wie in den beigefügten Schutzansprüchen definiert, jedoch keine Verfahren. Soweit nachfolgend in der Beschreibung gegebenenfalls auf Verfahren Bezug genommen wird, dienen diese Bezugnahmen lediglich der beispielhaften Erläuterung der in den beigefügten Schutzansprüchen unter Schutz gestellten Vorrichtung oder Vorrichtungen.
  • In einem Cloud-Computernetzwerk können mehrere Computergeräte über ein Netzwerk verbunden werden und Computeraufgaben gemeinsam und/oder parallel zueinander ausführen. Große verteilte Systeme können hunderte oder sogar tausende von separaten Computergeräten umfassen. Die Computergeräte können homogen (mit der gleichen Konfiguration) oder heterogen (mit unterschiedlichen Konfigurationen) sein. Die Computergeräte können darüber hinaus als Host für virtuelle Umgebungen sein und gestatten, dass mehrere Computerknoten (d. h. virtuelle Maschineninstanzen, Containerinstanzen) auf einem einzigen physikalischen Computergerät gehostet werden.
  • KURZDARSTELLUNG
  • Im Allgemeinen kann ein Aspekt des in dieser Spezifikation beschriebenen Sachverhaltes als Ausführungsform in Systemen und Verfahren enthalten sein, die von Datenverarbeitungsapparaten durchgeführt werden und das Empfangen einer Konfigurationsanforderung von einem bestimmten Knoten im Cloud-Computernetzwerk über ein Netzwerk; diese Konfigurationsanforderung umfasst Knoteninformationen für den jeweiligen Knoten; die Verifizierung, dass der jeweilige Knoten für die Konfiguration autorisiert ist, basierend, zumindest teilweise, auf Knoteninformationen; als Antwort auf die Verifizierung, dass der jeweilige Knoten für die Konfiguration autorisiert ist, Identifizierung von Konfigurationsmaßnahmen, die am entsprechenden Knoten durchgeführt werden müssen, basierend zumindest teilweise auf der Knoteninformation; und das Senden, über das Netzwerk, eines Konfigurationsbefehls, der einer oder mehrerer der identifizierten Konfigurationsmaßnahmen am jeweiligen Knoten entspricht, worin der entsprechende Knoten den Konfigurationsbefehl bei Erhalt ausführt, um die entsprechenden Konfigurationsmaßnahmen durchzuführen.
  • Im Allgemeinen kann ein innovativer Aspekt dieses in dieser Spezifikation beschriebenen Sachverhalts als Ausführungsform in Verfahren vorkommen, die die Kontrolle von Softwarestarts durch einen Konfigurations-Controller umfasst, worin die Software von einem Konfigurationsmanager aus einer Gruppe von Konfigurationsmanagern an einen Knoten in einer Cloud-Computerumgebung gestartet wird. Eines dieser Verfahren umfasst die Anforderung vom Knoten an den Konfigurations-Controller, den Knoten zu konfigurieren; die Bestimmung durch den Konfigurations-Controller, welcher Konfigurationsmanager für die Konfiguration des Knotens verwendet werden soll; die Erzeugung, durch den Konfigurations-Controller, eines Vertrauensverhältnisses zwischen dem Knoten und dem Konfigurationsmanager; und eine Umsetzung der Software am Knoten unter Verwendung des Konfigurationsmanagers basierend auf dem erzeugten Vertrauensverhältnisses.
  • In einem weiteren Aspekt kann der Konfigurationsmanager von einem Administrator aus der Gruppe von Konfigurationsmanagern vorbestimmt werden.
  • In einigen Aspekten kann dieses Vertrauensverhältnis zwischen einem Client und einem Server des Konfigurationsmanagers erstellt werden, worin der Start der vom besagten Server bereitgestellten Software auf dem besagten Client stattfindet, und worin der besagte Client auf dem Knoten ausgeführt wird.
  • In einigen Aspekten pflegt der Konfiguration-Controller Informationen über den Knoten, den Status der Softwareumsetzung auf dem Knoten, und/oder eine oder mehrere Maßnahmen, die nach Empfang einer Konfiguration und nach der erfolgreichen Knotenkonfiguration oder beim Auftreten eines Fehlers ergriffen werden.
  • In einem weiteren Aspekt wird die auf dem Knoten auszuführende Software durch eine Konfiguration bestimmt, die vom Konfigurations-Controller festgelegt wird.
  • In einem weiteren Aspekt wird die Konfiguration vom Administrator für den Konfigurations-Controller bereitgestellt.
  • In einigen Aspekten werden die Schlüssel zum Zugriff auf die Cloud-Computerumgebung und/oder der Konfigurationsmanager vom Konfiguration-Controller gespeichert und geheim gehalten, und der Konfigurations-Controller verwendet diese besagten Schlüssel zur Erzeugung des Vertrauensverhältnisses.
  • In einem weiteren Aspekt werden Schlüssel zum Zugriff auf die Cloud-Computerumgebung und/oder auf den Konfigurationsmanager von einer Entität erstellt und gespeichert, die der Konfigurationsmanager kennt, worin die Entität die Cloud-Computerumgebung, der Konfigurationsmanager, oder ein vertrauenswürdiger Dritter sein kann, und der Konfigurations-Controller verwendet dieses besagte Wissen, um das Vertrauensverhältnis zu erzeugen. In einigen Fällen sind diese Schlüssel kryptographische Schlüssel.
  • In einigen Aspekten bedeutet die Erzeugung eines Vertrauensverhältnisses zwischen einer ersten und zweiten Partei die Bereitstellung eines Berechtigungsnachweises an die erste Partei, der verwendet werden kann, um der zweiten Partei Zugriff zu gewähren, oder die Bereitstellung von Berechtigungsnachweisen an beide Parteien, die verwendet werden können, um Zugriff auf die jeweilige andere Partei zu gewähren.
  • In einigen hier beschriebenen Implementierungen bietet der Prozess der Verifizierung, dass der jeweilige Knoten für die Konfiguration autorisiert ist bzw. für die Erzeugung eines Vertrauensverhältnisses zwischen einem Knoten und dem Konfigurationsmanager, eine Indirektionsschicht zur Erhöhung der Gesamtsicherheit des Systems und zur Vereinfachung einer sicheren Konfiguration. In einigen Fällen entfernt der Prozess die Fähigkeit eines individuellen Knotens, zu kontrollieren, wie er konfiguriert wird, was wiederum unautorisierte, unverifizierte oder kompromittierte Knoten auf eine ad-Hoc-Weise daran hindert, Konfigurationsressourcen anzufordern, welche vertrauliche Informationen enthalten können. Dies kann das Risiko reduzieren, dass unautorisierte, unverifizierte oder kompromittierte Knoten auf vertrauliche Konfigurationsinformationen zugreifen können.
  • Der Prozess kann auch Flexibilität bieten, indem er in verschiedene vorhandene Konfigurationsmanager integriert wird, was einem Administrator erlaubt, zu wählen, welcher Konfigurationsmanager zur Konfiguration eines bestimmten Knotens verwendet wird. Die Integration in unterschiedlichen Konfigurationsmanagern und Konfigurationstools kann ebenfalls erlauben, dass der Prozess unter Verwendung von mehreren Konfigurationsmanagern und Konfigurationstools in heterogene Cloud-Computernetzwerke implementiert wird. Der Prozess kann auch unter Verwendung von herkömmlichen Client-Server-Protokollen für die Kommunikation implementiert werden, was wiederum eine minimale Rekonfiguration von vorhandenen Netzwerken und Systemen erlaubt.
  • Details einer oder mehrerer Implementierungen des in dieser Spezifikation beschriebenen Gegenstands werden in den beigefügten Zeichnungen und in der nachstehenden Beschreibung dargelegt. Andere Merkmale, Aspekte und potenzielle Vorteile des Gegenstands werden aus der Beschreibung, den Zeichnungen und den Ansprüchen deutlich.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist ein Diagramm einer Beispielumgebung für die sichere Konfiguration von Ressourcen in einem Cloud-Computersystem.
  • 2 ist ein Schwimmbahndiagramm eines Beispielprozesses für die sichere Konfiguration von Ressourcen in einem Cloud-Computersystem.
  • 3 ist ein Schwimmbahndiagramm eines Beispielprozesses für die sichere Konfiguration von Ressourcen in einem Cloud-Computersystem.
  • 4 ist ein Diagramm eines Beispielkonfigurations-Controllers, der in der Umgebung von 1 verwendet wird.
  • 5 ist ein Flussdiagramm eines Beispielprozesses für die sichere Konfiguration von Ressourcen in einem Cloud-Computersystem.
  • 6 ist ein Diagramm von Computergeräten, das zur Implementierung der in diesem Dokument beschriebenen Systeme und Verfahren angewendet werden kann.
  • Entsprechende Referenznummern und Kennzeichnungen in den verschiedenen Zeichnungen zeigen entsprechende Elemente an.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Konfigurationsmanager, wie CHEFTM, PUPPET, SALT und ANSIBLE sind Softwareprogramme zur Umsetzung von Software an Computergeräte über ein Netzwerk. Diese Konfigurationsmanager werden häufig in lokalen Umgebungen verwendet, um Software über interne Netzwerke zu verteilen. Da diese Konfigurationsmanager viele nützliche Funktionen bieten, bemüht man sich, diese in größeren Cloud-Computersystemen einzusetzen. Da diese Konfigurationsmanager jedoch hauptsächlich für die interne Netzwerknutzung konzipiert sind, haben viele für ein Cloud-Computersysteme erwünschte Funktionen, wie robuste Sicherheit, Interoperabilität mit anderen Rahmenwerken und elastische Umsetzungsfähigkeiten, diese Bemühungen bisher erschwert.
  • Die vorliegende Offenbarung beschreibt Verfahren und Systeme zur sicheren Konfiguration von Knoten in einem Cloud-Computersystem. Die beschriebene Lösung nutzt die vorhandenen Konfigurationsmanager als Ressourcen für die Bereitstellung von Konfigurationsobjekten an Knoten während des Konfigurationsprozesses. Die Lösung kann mehrere unterschiedliche Arten von Konfigurationsmanagern mit verschiedenen Anwendungsprogrammierschnittstellen (APIs) unterstützen und erlaubt es diesen u. U., gemeinsam in einem einzigen Cloud-Computersystem verwendet zu werden. Des Weiteren bietet die Lösung Unterstützung für elastische Umsetzung von Ressourcen, wie als Antwort auf zunehmende Nachfrage nach Ressourcen oder sich verändernde Netzwerkbedingungen. Zusätzlich werden Sicherheitsmaßnahmen, wie die Allokation, Verteilung und das Management von Zugriffsrechten für potenziell vertrauliche Konfigurationsresscourcen allein von dem beschriebenen System gemanagt, anstatt durch die Konfigurationsressourcen oder die Knoten im Cloud-Computersystem.
  • Die beschriebene Lösung fügt eine Indirektionsschicht zwischen dem Konfigurationsmanager und den Knoten, die konfiguriert werden, hinzu. Wenn z. B. ein Knoten durch eine Konfigurationsressource konfiguriert wird, kann ein Vertrauensverhältnis zwischen dem zu konfigurierenden Knoten und der Konfigurationsressource hergestellt werden. Im Allgemeinen sind die Konfigurationsressource oder der Knoten ein Teil einer vertrauenswürdigen Computerbasis, um einen sicheren Konfigurationsprozess zu gewährleisten (z. B. dass unautorisierte oder unverifizierte Knoten daran gehindert werden, auf Anforderungen von Konfigurationsressourcen zuzugreifen, die vertrauliche Informationen enthalten können). In der hier beschriebenen Lösung kann der Konfigurations-Controller, der Teil der vertrauenswürdigen Computerbasis ist, Vertrauensverhältnisse zwischen Knoten und Konfigurationsressourcen aushandeln, so dass der Knoten und die Konfigurationsressource ein gegenseitiges Vertrauen aufbauen können, ohne dass sie selbst Bestandteil der vertrauenswürdigen Computerbasis sind. Der Konfigurations-Controller kann dieses Vertrauensverhältnis z. B. dadurch aubauen, dass Zugriffs-Berechtigungsnachweise für den Knoten an der Konfigurationsressource konfiguriert werden und indem er dem Knoten die Berechtigungsnachweise zur Verfügung stellt, um diese für den Zugriff auf die Ressource zu verwenden. Basierend auf dieser Indirektionsschicht, die vom Konfigurations-Controller bereitgestellt wird, kann die sichere Konfiguration eines Knotens erreicht werden, ohne dass der Knoten bzw. die Konfigurationsressource ein Teil der vertrauenswürdigen Computerbasis sind. Die vertrauenswürdige Computerbasis kann z. B. Komponenten innerhalb des Systems umfassen, die potenziell vertrauliche Zugriffsrechte verwalten und sichern.
  • Ein Administrator kann das System mit einem Satz Konfigurationsvorschriften konfigurieren, die definieren, welche Konfiguration von welchem Konfigurationsmanager auf einen bestimmten Knoten angewandt werden soll. Die Konfigurationsvorschriften können als Satz Regeln spezifiziert werden. Jede Regel passt die Eigenschaften eines Knotens (z. B. Name, Erstellungsdatum, Eigentümer, usw.) an einen Satz Konfigurationsdaten an. Jede Regel kann auch Konfigurationsmaßnahmen für das System enthalten, die nach einer erfolgreichen oder fehlgeschlagenen Knotenkonfiguration ergriffen werden müssen. Um eine Konfiguration zu erhalten, sendet ein Knoten eine Anforderung an das System (z. B. über ein Netzwerk). Wenn das System eine Anforderung zur Konfiguration einer Maschine erhält, findet es eine oder mehrere Regeln innerhalb der Konfigurationsvorschriften, die die Eigenschaften des Knotens anpassen, um festzustellen, welche Konfigurationsmaßnahmen ergriffen werden müssen.
  • Die vorliegende Lösung kann in vorhandene Konfigurationsmanager integriert werden, um Elastizität durch automatische Knotenkonfiguration als Antwort auf die Anforderung von Ressourcen bereitzustellen. Vorhandene Konfigurationsmanager arbeiten gewöhnlich in einer interaktiven Umgebung, in der ein Administrator den Konfigurationsmanager interaktiv nutzt, um neue Knoten bereitzustellen. Dieses interaktive Szenario eignet sich u. U. nicht für elastische Szenarien, bei denen Kunden Knoten als Antwort auf den aktuellen Status des Systems bereitstellen möchten. Die vorliegende Lösung verbessert die Fähigkeit des Administrators, Knoten auf Abruf bereitzustellen und wendet die Konfigurationsmanager auf elastische Szenarien an. Die Integrationsfähigkeit in vorhandene Lösungen macht das vorliegende System auch leichter umsetzbar in einer Reihe von unterschiedlichen vorhandenen Cloud-Konfigurationen, von denen jede einen oder mehrere Konfigurationsmanager verwenden kann, mit denen das vorliegende System integriert werden kann.
  • In Bezug auf Sicherheit können manche Cloud-Konfigurationsmanager einem derzeit konfigurierten Knoten Zugriff auf Berechtigungsnachweise bereitstellen (z. B. Verschlüsselungscodes, Anmelde-Berechtigungen, usw.), damit dieser auf Netzwerkressourcen zugreifen kann, um Objekte zu holen, die für die Konfiguration notwendig sind (z. B. Softwarebibliotheken, Quellcode, usw.). Eine derartige Konfiguration kann ein Sicherheitsrisiko darstellen, da ein Angreifer eine beliebige Anzahl von Knoten hacken kann, um diese Zugriffsberechtigungen zu erlangen. Die vorliegende Offenbarung beschreibt ein System, in dem Zugriffsberechtigungen vom Konfigurationssystem verwaltet werden können und nicht von den konfigurierten Knoten gemanagt oder gepflegt werden müssen. Dieser Aspekt erhöht die Gesamtsicherheit des Systems und erleichtert die sichere Konfiguration. Des Weiteren entfernt das vorliegende System die Fähigkeit eines individuellen Knotens, zu kontrollieren, wie er konfiguriert wird, was wiederum kompromittierte Knoten auf eine ad-Hoc-Weise daran hindert, Konfigurationsressourcen anzufordern, welche vertrauliche Informationen enthalten können.
  • Dies reduziert das Risiko, dass unautorisierte, unverifizierte oder kompromittierte Knoten auf vertrauliche Konfigurationsinformationen zugreifen können.
  • Die vorliegende Lösung kann auch erhöhte Sicherheit bieten, indem sie sicherstellt, dass ein bestimmter Knoten, der eine Konfiguration anfordert auch tatsächlich für die Konfiguration autorisiert ist. Das System kann eine Konfigurationsanforderung, die es von einem bestimmten Knoten erhält, mit einer entsprechenden Maßnahme durch einen Administrator korrelieren, um sicherzustellen, dass der Knoten für die Konfiguration autorisiert ist. Das System kann den Knoten auch anweisen, diverse Anweisungen auszuführen und den Ausgang dieser Anweisungen bereitstellen, um zu beweisen, dass der Knoten echt ist und nicht etwa ein kompromittierter Knoten, der von einem Angreifer angewiesen wird. So kann das System z. B. den Knoten anweisen, eine hohe Anzahl von Berechnungen in kürzester Zeit auszuführen, um sicherzustellen, dass der kompromittierte Knoten nicht manuell von einem menschlichen Angreifer gesteuert wird. Das System kann ebenfalls Anweisungen an den Knoten geben, dass dieser Informationen, wie eine eindeutige Kennung ausgibt, die Teil seiner Originalkonfiguration ist. Diese Informationen können mit der Original-Erstellungsanforderung einhergehen, damit der Knoten verifiziert, dass der Knoten für die Konfiguration autorisiert ist.
  • 1 ist ein Diagramm einer Beispielumgebung 100 für die sichere Konfiguration von Ressourcen in einem Cloud-Computersystem. Wie veranschaulicht, umfasst die Umgebung 100 einen Benutzer oder ein automatisiertes System 110 in Kommunikation mit dem Umsetzungsmanager 120. Der Umsetzungsmanager 120 setzt einen Knoten 130 (z. B. eine virtuelle Maschineninstanz, eine Containerinstanz oder eine andere Komponente eines Cloud-Computersystems) als Antwort auf eine Anforderungen vom Benutzer/vom automatisierten System 110 um. Ein Konfigurations-Controller 140 interagiert mit dem Knoten 130, um ihm eine Konfiguration bereitzustellen. Der Konfigurations-Controller 140 arbeitet auf der Basis von Konfigurationsvorschriften 160. Der Konfigurations-Controller 140 interagiert ebenfalls mit der Konfigurationsressource 150, um den Knoten 130 zu autorisieren, Konfigurationsobjekte von der Ressource zu erhalten. Beim Betrieb fordert der Benutzer/das automatisierte System 110, dass der Umsetzungsmanager 120 einen Knoten erstellt (170). Als Antwort setzt der Umsetzungsmanager 120 den Knoten 130 (172) um. Bei der Initialisierung sendet der Knoten 130 eine Konfigurationsanforderung 174 an den Konfigurations-Controller 140. Der Konfigurations-Controller 140 identifiziert eine Konfigurationsvorschrift 164, wobei der Knoten 130 auf Parameter basiert, die in der Konfigurationsanforderung 174 enthalten sind. Der Konfigurations-Controller 140 erteilt Konfigurationsbefehle 176 an den Knoten 130. Der Konfigurations-Controller 130 führt die Konfigurationsbefehle 176 aus und gibt die Ergebnisse der Befehle an den Konfigurations-Controller 140 weiter. Der Konfiguration-Controller 140 kann ebenfalls Konfigurationsbefehle 178 an die Konfigurationsressource 150 senden. So kann z. B. die Konfiguration für den Konfigurations-Controller 140 die Konfigurationsressource 150 so konfigurieren, dass der Knoten 130 autorisiert wird, Konfigurationsobjekte (180) von der Konfigurationsressource 150 abzurufen. Der Konfigurations-Controller 140 kann ebenfalls den Knoten 130 (z. B. über die Konfigurationsbefehle 176) mit Zugriffsberechtigungen konfigurieren, damit dieser auf die Konfigurationsressource 150 zugreifen kann.
  • Der Benutzer/das automatisierte System 110 ist eine Entität, die Knoteninstanzen anfordert, wie z. B. Knoten 130, um diesen vom Umsetzungsmanager 120 umsetzen zu lassen. So kann der Benutzer/das automatisierte System 110 z. B. Benutzer umfassen, die mit einer Benutzerschnittstelle interagieren, um eine neue Knoteninstanz zu erstellen. Der Benutzer/das automatisierte System 110 kann ebenso ein automatisiertes System umfassen, dass automatisch die Erstellung von Knoteninstanzen vom Umsetzungsmanager anfordert, wie z. B. als Antwort auf eine erhöhte Nachfrage nach Computerressourcen für eine bestimmte Anwendung, eine Verringerung der Leistung eines Cloud-Computersystems, das vom Umsetzungsmanager 120 verwaltet wird, oder als Antwort auf andere Ereignisse. In einigen Implementierungen kann der Benutzer/das automatisierte System 110 mit dem Umsetzungsmanager 120 über ein Netzwerk kommunizieren (nicht abgebildet), um die Erstellung eines Knotens (170) anzufordern und um eine Bestätigung zu erhalten, dass der Knoten erstellt wurde (182). Zusätzliche Informationen, wie z. B. die Identität des Benutzers/automatisierten Systems 110, Attribute des zu erstellenden Knotens, oder weitere Informationen, können in der Erstellungsanforderung (170) und in der Bestätigung (182) enthalten sein, wie im Folgenden im Einzelnen erläutert wird.
  • Der Umsetzungsmanager 120 kann eine Computerkomponente in einer verteilten Computerumgebung, wie in einem Cloud-Computersystem sein. In einigen Implementierungen kann der Umsetzungsmanager 120 aus einer oder mehreren Computerkomponenten bestehen, die zur Umsetzung von neuen Knoteninstanzen und zur Verwaltung von Knoteninstanzen in der verteilten Computerumgebung angewandt wird. In einigen Fällen kann der Umsetzungsmanager 120 als eine Softwarekomponente implementiert werden und kann eine API bereitstellen, mit der Entitäten wie der Benutzer/das automatisierte System 110 die Erstellung neuer Knoten innerhalb der verteilten Computerumgebung anfordern können. In einigen Implementierungen kann die Umsetzung eine Hypervisor-Komponente sein, die Knoten innerhalb einer oder mehrerer virtuellen Ausführungsumgebungen umsetzt und verwaltet. In diesem Fall können die Knoten, die vom Hypervisor umgesetzt und verwaltet werden, virtuelle Maschineninstanzen, Containerinstanzen, virtuelle Ressourcen (z. B. Disks, Prozessoren, usw.) oder andere virtuelle Komponenten sein.
  • Der Knoten 130 wird vom Umsetzungsmanager 120 bei 172 umgesetzt. Der Knoten 130 kann eine Knoteninstanz sein, die von einem physikalischen Computergerät in einer virtuellen Umgebung umgesetzt und ausgeführt wird. In einigen Fällen kann der Knoten 130 gemäß einer virtuellen Maschine oder einem Containerbild erstellt werden, das mit dem Umsetzungsmanager 120 verknüpft und vom Benutzer/automatisierten System 110 in der Erstellungsanforderung 170 spezifiziert wurde. In einigen Implementierungen kann der Knoten 130 mit einer minimalen Konfiguration umgesetzt werden, die jedoch ausreicht, damit dieser mit dem Konfigurations-Controller 140 kommunizieren kann. So kann z. B. der Knoten 130 mit einem minimal konfigurierten Betriebssystem umgesetzt werden, wobei eine eingeschränkte Netzwerkkonfiguration diesem erlaubt, über ein Netzwerk (nicht abgebildet) auf den Konfigurations-Controller 140 zuzugreifen, sowie Anweisungen, die Konfigurationsanforderung 174 an den Konfiguration-Controller 140 zu senden und eine Antwort vom Konfigurations-Controller 140 abzuwarten. Eine derartige Umsetzung erlaubt dem Konfigurations-Controller 140 u. U., die meisten Aspekte der Konfiguration des Knotens 130 zu steuern. Im Gegensatz hierzu kann ein Knoten, der mit einer nicht minimalen Konfiguration umgesetzt wird Konfigurationseinstellungen, Softwarepakete und andere Konfigurationsobjekte innerhalb des Bildes umfassen, mit dem der Knoten erstellt wurde. Diese Methode kann zu Schwierigkeiten führen, wenn Änderungen an den ursprünglichen Konfigurationen für neue Knoten vorgenommen werden sollen, da das Bild, aus dem die Knoten erstellt werden, aktualisiert werden muss, um solche Änderungen umzusetzen. Die vorliegende Lösung kann ebenso in Situationen verwendet werden, wo Knoten mit derart nicht minimalen Konfigurationen umgesetzt werden, wie z. B., um vorinstallierte Softwarepakete zu aktualisieren, um Änderungen an den Einstellungen der ursprünglichen Konfiguration des Bildes vorzunehmen und die dortigen Werte zu aktualisieren und um weitere Konfigurationsmaßnahmen zu ergreifen. Diese Methode kann einige der Schwierigkeiten bei Änderungen an ursprünglichen Konfigurationen beheben, die in einem Bild bestehen, da ein nicht minimal konfigurierter Knoten 130 bei der Initialisierung eine Konfiguration vom Konfigurations-Controller 140 anfordern und erhalten kann, genauso wie ein minimal konfigurierter Knoten.
  • Der Konfigurations-Controller 140 erhält die Konfigurationsanforderung 174 vom Knoten 130 über ein Netzwerk (nicht abgebildet). Bei einigen Implementierungen sendet der Knoten 130 die Konfigurationsanforderung 174 gemäß einem Representational State Transfer (REST) API, das vom Konfigurations-Controller 140 bereitgestellt wird. Der Knoten 130 kann angewiesen werden, über ein Hypertext Transfer Protocol (HTTP), HTTP Secure (HTTPS) oder ein anderes Protokoll auf eine Uniform Resource Locator (URL) zuzugreifen, die dem Konfigurations-Controller 140 entspricht. So kann z. B. der Knoten 130 eine HTTP-Anforderung für die URL „http://configcontroller.internal.net/start” an den Konfigurations-Controller 140 senden, wobei der Domainname „configcontroller.internal.net” eine Netzwerkadresse auflöst, die mit dem Konfigurations-Controller 140 verknüpft ist und das Ziel „Start” weist den Konfigurations-Controller 140 darauf hin, dass der Knoten 130 eine Konfiguration anfordert.
  • Die Konfigurationsanforderung 174 kann auch identifizierende Informationen zum Knoten 130 enthalten. So kann z. B. der Benutzer – das automatisierte System 110 Informationen zum Knoten 130 festlegen, die vom Umsetzungsmanager 120 erstellt werden müssen, wie z. B. ein Knoteninstanztyp, eine Identität des Benutzers oder des Systems, das die Erstellung des Knotens 130 anfordert, eine eindeutige Kennung für die Anforderung, den Knoten zu erstellen oder andere Informationen. In einigen Fällen werden diese Informationen in der Konfigurationsanforderung 174 kodiert. In einigen Implementierungen kann der Konfigurations-Controller 140 diese Informationen nutzen, um sicherzustellen, dass der Knoten 130 für die Konfiguration autorisiert ist. So kann z. B. der Konfigurations-Controller 140 die eindeutige Kennung für die Anforderung zur Erstellung eines Knotens in der Konfigurationsanforderung 174 erhalten und kann diese Kennung verwenden, um sicherzustellen, dass der Knoten 130 tatsächlich umgesetzt wurde und die Konfiguration basierend auf dieser gültigen Erstellungsanforderung anfordert. Eine derartige Verifizierung kann erhöhte Sicherheit bieten, da sie unautorisierten Knoteninstanzen den Zugriff auf interne und möglicherweise vertrauliche Konfigurationsdaten verwehrt. In einem Beispiel wird eine solche Knoteninstanz von einer bösartigen Entität erstellt, um zu versuchen, auf solche internen Daten zuzugreifen. Der Konfigurations-Controller 140 kann ebenfalls verifizieren, dass die Knoteninstanz von einem Benutzer oder einem System erstellt wurde, das zum Erstellen von Knoteninstanzen mit den spezifischen Attributen der Konfiguration autorisiert ist, die die Konfiguration anfordert.
  • In einigen Implementierungen kann der Konfigurations-Controller 140 die Konfigurationsanforderung 174 vom Umsetzungsmanager 120 erhalten. In diesem Fall, wenn der Umsetzungsmanager 120 einen neuen Knoten umsetzt, kann er die Konfigurationsanforderung 174 mit Informationen über den neu umgesetzten Knoten an den Konfigurations-Controller 140 senden. Der Konfiguration-Controller 140 kann, wie oben im knoten-initiierten Konfigurationsszenario beschrieben, die Informationen über den Knoten ähnlich verwenden, wie oben zur Identifizierung und Verifizierung der Identität des Knotens vor seiner Konfiguration beschrieben.
  • In einigen Implementierungen kann der Konfigurations-Controller 140 so konfiguriert werden, dass das Netzwerk für neu umgesetzte Knoten scannt, die auf Konfiguration warten. In einem solchen Fall würde der Konfiguration-Controller 140 keine Konfigurationsanforderung 174 erhalten, um eine Konfiguration eines bestimmten Knotens zu initiieren, sondern stattdessen den Konfigurationsprozess initiieren, wenn ein Knoten gefunden wird, der auf seine Konfiguration wartet. So kann der Konfigurations-Controller 140 regelmäßig eine Datenbank oder andere Ressource, die eine Liste von auf Konfiguration wartenden Knoten enthält und er kann die Kommunikation mit diesen Knoten initiieren, um den Konfigurationsprozess zu beginnen. Der Konfigurations-Controller 140 kann auch eine Übertragungsnachricht auf dem Netzwerk senden, die darauf hinweist, dass er bereit ist, neu umgesetzte Knoten zu konfigurieren. In einem solchen Fall würden diese neu umgesetzten Knoten so konfiguriert, dass sie auf diese Übertragungsnachricht reagieren, um den Konfigurationsprozess zu beginnen.
  • Der Konfigurations-Controller 140 kann die Informationen von der Konfigurationsanforderung 174 verwenden, um eine der Konfigurationsvorschriften 160 zur Konfiguration des Knotens 130 zu nutzen. In einigen Implementierungen kann eine Konfigurationsvorschrift 160 eine Regel und einen Satz Konfigurationsbefehle umfassen, die durchgeführt werden müssen, wenn ein zu konfigurierender Knoten zur jeweiligen Regel passt. So kann z. B. eine Konfigurationsvorschrift 160 festlegen, dass ein Knoten, der mit einem Knotentyp „Datenbank” konfiguriert werden soll, während des Konfigurationsprozesses mit einem Datenbank-Management-Softwareprogramm ausgestattet werden sollte. Wenn der Konfigurations-Controller 140 die Konfigurationsanforderung von einem Knoten 130 erhält, die festlegt, dass der Knotentyp 130 eine „Datenbank” ist, wird der Konfiguration-Controller feststellen, ob der Knoten 130 zur Konfigurationsvorschrift 160 für den Knotentyp „Datenbank” passt und gibt die Konfigurationsbefehle, die in der Konfigurationsvorschrift 160 definiert sind, an den Knoten 130 weiter, um das Datenbank-Management-Softwareprogramm zu installieren. Die Regeln in den Konfigurationsvorschriften 160 können Kriterien enthalten, die passende Werte für Informationen festlegen, die in der vom Knoten 130 erhaltenen Konfigurationsanforderung enthalten sind. In einigen Implementierungen kann die Konfigurationsvorschrift 160 bestimmte Verwendungszwecke für die Konfigurationsressourcen 152 festlegen, um die Konfiguration durchzuführen.
  • Sobald der Konfiguration-Controller 140 die Konfigurationsvorschrift 162 identifiziert, die zur Konfiguration des Knotens 130 verwendet wird, kann der Konfigurations-Controller 140 eine oder mehrere Konfigurationsbefehle 176 an den Knoten 130 senden. Wie zuvor erörtert, hört der Knoten 130 auf solche Befehle vom Konfigurations-Controller 140, nachdem er die Konfigurationsanforderung 174 sendet. In einigen Implementierungen, wenn der Knoten 130 den Konfigurationsbefehl 176 erhält, führen die Anweisungen, mit denen er umgesetzt wird dazu, dass er den erhaltenen Befehl ausführt und stellt die Ausgänge oder Ergebnisse des ausgeführten Befehls für den Konfigurations-Controller 140 bereit.
  • Diese Anordnung kann erhöhte Flexibilität bei der Konfiguration des Knotens 130 bieten, da der Konfiguration-Controller 140 dem Knoten 130 befehlen kann, jeden Befehl auszuführen, der vom Benutzer ausgeführt werden könnte, der Befehle direkt in den Knoten 130 eingibt. In einigen Implementierungen kann der Knoten 130 jeden erhaltenen Konfigurationsbefehl 176 in einem Betriebssystem-Shell oder in einer Befehlszeilenschnittstelle, wie z. B. Bourne-Shell (sh), Bourne-Again-Shell (bash), Korn-Shell (ksh), C-Shell (csh) oder andere Shells oder Befehlszeilenschnittstellen. Eine derartige Anordnung kann dem Konfigurations-Controller 140 erlauben, die umfassenden Funktionen dieser Shells bei der Konfiguration des Knotens 130 zu nutzen, wie als Skripten und die Flusskontrolloperationen, wie Umleitungen („>”) und Leitungen („|”).
  • So kann z. B. der Konfigurations-Controller 140 als Reaktion auf die Beispiels-Konfigurationsanforderung 174 von einem Knoten 130 des Knotentyps „Datenbank” dem Knoten 130 einen Konfigurationsbefehl 176 senden, um eine Paketmanagement-Client am Knoten 130 zu konfigurieren, wie z. B. das Advanced Packaging Tool (APT), RPM Package Manager, oder einen anderen Client, um auf eine bestimmte Konfigurationsressource 150 zuzugreifen. Beispiele für diesen Konfigurationsbefehl 176 wären „add-apt-repository 'deb http://config.blah.com/config/database-manager main”, worin „http://config.blah.com/config/” eine URL ist, die sich auf die Ressource 150 bezieht. Der Knoten 130 kann den Konfigurationsbefehl 176 erhalten und diesen wie oben beschrieben in einer Shell oder Befehlszeilenschnittstelle ausführen. Die Ausführung des Konfigurationsbefehls 176 führt dazu, dass das „add-apt-repository”-Programm Knoten 130 mit den festgelegten Parametern ausgeführt wird, was in diesem Fall dazu führt, dass die Konfiguration des APT-Paketmanagement-Clientprogramms aktualisiert wird. Der Konfigurations-Controller 140 kann dann einen Konfigurationsbefehl 176 senden, der den Paketmanagement-Client am Knoten 130 anweist, das entsprechende Paket abzuholen. So kann z. B. der Konfigurationsbefehl 176 zum Abholen der „Datenbankmanager”-Komponente aus dem vorigen Beispiel „apt-get install database-manager” sein. Der Knoten 130 kann den Konfigurationsbefehl 176 erhalten und diesen wie oben beschrieben in einer Shell oder Befehlszeilenschnittstelle ausführen. Die Ausführung des Konfigurationsbefehls 176 führt dazu, dass das „add-get”-Programm am Knoten 130 mit den festgelegten Parameter ausgeführt wird, was in diesem Fall dazu führt, dass der Knoten 130 das „Datenbankmanager”-Softwareprogramm von der mit dem vorigen Befehl konfigurierten Konfigurationsressource 150 zu holen und zu installieren.
  • Der Konfigurations-Controller 140 kann ebenfalls Konfigurationsbefehle 176 senden, die ausgewählt wurden, um sicherzustellen, dass der Knoten 130 für die Konfiguration autorisiert ist. So kann der Konfigurations-Controller 140 den Knoten 130 z. B. anweisen, eine Reihe von Berechnungen durchzuführen und innerhalb eines bestimmten Zeitraums Ergebnisse zu produzieren. Ein derartiger Mechanismus kann verwendet werden, um sicherzustellen, dass es sich bei dem Knoten 130 tatsächlich um eine Computerressource handelt und nicht um einen menschlichen Angreifer, der versucht, elektronisch auf das System zuzugreifen. Die Zeitdauer kann so gewählt werden, dass es für einen menschlichen Angreifer nicht möglich wäre, diese Berechnungen vor Ablauf der Zeit durchzuführen. In einem weiteren Beispiel kann der Konfigurations-Controller 140 den Knoten 130 anweisen, immutierbare Merkmale seiner Umgebung, wie eine physikalische Medium Access Control(MAC)-Adresse, Seriennummer oder eine andere eindeutige Kennung des physikalischen Computergeräts, auf dem er ausgeführt wird. Der Knoten 130 kann diese Daten zur Prüfung an den Konfigurations-Controller 140 bereitstellen. Eine derartige Prüfung kann sicherstellen, dass der Knoten 130 die Knoteninstanz ist, die vom Umsetzungsmanager 120 als Reaktion auf die Anforderung vom Benutzer/automatisierten System 110 umgesetzt wurde, und kein Angreifer, der die umgesetzte Instanz für einen möglicherweise bösartigen Zweck nutzt.
  • Bei der Konfigurationsressource 150 kann es sich um eine Computerkomponente oder einen Satz Computerkomponenten handeln, von denen der Knoten 130 Konfigurationsobjekte (180) erhalten kann. So kann es sich z. B. bei der Konfigurationsressource 150 um einen Konfigurations-Managementserver handeln, der ein Konfigurations-Managementtool wie z. B. CHEFTM, PUPPET, SALT, ANSIBLE oder ein anderes Konfigurations-Managementtool ausführt. Die Konfigurationsressource 150 kann ebenso eine Datenbank, ein Depot oder eine weitere Sammlung von Konfigurationsobjekten sein. In einigen Implementierungen kann der Konfigurations-Controller so konfiguriert werden, dass er mit mehreren unterschiedlichen Typen von Konfigurationsressourcen 150 kommuniziert, die APIs, Kommunikationsprotokolle oder andere Mechanismen verwendet, die spezifisch für die jeweilige Art von Konfigurationsressource 150 sind. Der Konfigurations-Controller 140 kann Konfigurationsbefehle 178 an die Konfigurationsressource 150 senden, um den Knoten 130 zu autorisieren, auf die Konfigurationsressource 150 zuzugreifen. Der Konfigurations-Controller 140 kann ebenfalls Konfigurationsbefehle 176 an den Knoten 130 senden und diesem die Berechtigungsnachweise zum Zugriff auf die Konfigurationsressource 150 bereitstellen. In einigen Fällen können diese Berechtigungsnachweise so eingeschränkt sein, dass der Knoten 130 nur das Zugriffslevel erhält, der er zu seiner Konfiguration benötigt. So können dem Knoten 130 z. B. Zugriffsberechtigungen für die Konfigurationsressource 150 gewährt werden, die vom Konfigurations-Controller 140 erstellt wird, wenn der Konfigurationsprozess beginnt und die vom Konfiguration-Controller 140 gelöscht werden, wenn der Konfigurationsprozess endet. Derartige Techniken können im Vergleich zu vorherigen Techniken zu erhöhter Sicherheit führen, da die Notwendigkeit für den Knoten 130, seine eigenen Zugriffsberechtigungen für die Konfigurationsressource 150 zu speichern und zu pflegen, entfällt. Stattdessen kann der Konfigurations-Controller 140 diese Berechtigungen verwalten und diese nur an den Knoten 130 bereitstellen, wenn dies für die Konfiguration erforderlich ist. Dies kann die Ressourcen, auf die ein Angreifer zugreifen kann, wenn er dem Knoten 130 mächtig wird und schränkt die Anzahl der Komponenten innerhalb des Systems ein, die potenziell vertrauliche Zugriffsberechtigungen verwalten und sichern müssen.
  • In einigen Implementierungen können die Interaktionen zwischen denen in 1 veranschaulichten Komponenten als Nachrichten implementiert werden, die über ein oder mehrere Netzwerke, an die die Komponenten angeschlossen sind, zwischen den Komponenten hin- und hergesendet werden. So können diese ein oder mehrere Netzwerke z. B. Internet Protocol (IP) oder andere Netzwerktypen umfassen und sie können Transmission Control Protocol (TCP), Universal Datagram Protocol (UDP) oder andere Protokolle auf der Transportschicht nutzen. Die zwischen den Komponenten hin- und hergesendeten Nachrichten können gemäß einem Kommunikationsprotokoll, wie z. B. Hypertext Transfer Protocol (HTTP), Remote Procedure Call (RPC), Simple Object Access Protocol (SOAP) oder anderen Kommunikationsprotokollen aufgebaut sein. Die einen oder mehreren Netzwerke können über ein- oder mehrschichtige Netzwerktechnologien implementiert werden, die u. a. folgende umfassen können: Ethernet, Synchronous Optical Networking (SONST), Asynchronous Transfer Mode (ATM) und andere verdrahtete oder drahtlose Netzwerktechnologien.
  • In einigen Implementierungen kann der Konfigurations-Controller 140 vorhandene Knoten im Netzwerk versetzt aktualisieren. In einem derartigen rollenden Aktualisierungsprozess wählt der Konfigurations-Controller 140 Knoten aus, die eine aktualisierte Konfiguration basierend auf spezifischen Kriterien erhalten sollen. Die Kriterien können z. B. festlegen, dass Knoten im Netzwerk mit einer Rate von 100 pro Stunde aktualisiert werden. Als Reaktion hierauf kann der Konfigurations-Controller 140 100 Knoten pro Stunde auswählen und diese anweisen, die aktualisierte Konfiguration wie oben beschrieben zu akzeptieren. In einigen Fällen kann der Konfigurations-Controller 140 den Aktualisierungsprozess initiieren, indem er eine Nachricht an die zu aktualisierenden Knoten sendet. Der Konfigurations-Controller 140 kann ebenso eine Nachricht von jedem zu aktualisierenden Knoten erhalten, was den Aktualisierungsprozess initiiert. Der Konfigurations-Controller 140 kann ebenso eine Nachricht vom Umsetzungsmanager 120 erhalten, was den Aktualisierungsprozess initiiert.
  • 2 ist ein Schwimmbahndiagramm eines Beispielprozesses für die sichere Konfiguration von Ressourcen in einem Cloud-Computersystem. Bei 205 fordert der Benutzer/das automatisierte System 110, dass der Umsetzungsmanager 120 einen Knoten erstellt. Bei 210 erstellt der Umsetzungsmanager 120 den Knoten 130 und setzt ihn um. Bei 215, bei der Initialisierung, sendet der Knoten 130 eine Nachricht an den Konfigurations-Controller 140 und fordert die Konfiguration. Bei 220 sucht der Knoten 130 nach Konfigurationsbefehlen vom Konfigurations-Controller 140. In einigen Implementierungen kann der Knoten 130 in eine „Besetzt”-Schlaufe geraten, wo er regelmäßig nach Konfigurationsbefehlen prüft, die vom Konfigurations-Controller 140 erhalten wurden.
  • Bei 225, als Reaktion auf den Erhalt der Konfigurationsanforderung vom Knoten 130, sendet der Konfigurations-Controller 140 einen Konfigurationsbefehl an den Knoten 130. Bei 230 führt der Knoten 130 den erhaltenen Konfigurationsbefehl aus. Bei 235 sendet der Knoten 130 ein Ergebnis des Konfigurationsbefehls an den Konfigurations-Controller 140. So kann der Knoten 130 z. B. den Konfigurationsbefehl in einer Betriebssystem-Shell ausführen und die Ausgänge des ausgeführten Befehls an den Konfigurations-Controller 140 als Ergebnis bereitstellen. Bei 240 sucht der Knoten 130 erneut nach Konfigurationsbefehlen vom Konfigurations-Controller 140.
  • 3 ist ein Schwimmbahndiagramm eines Beispielprozesses für die Konfiguration eines Knotens 130 und einer Konfigurationsressource 150 unter Verwendung des Konfigurations-Controllers 140. Bei 305 konfiguriert der Konfigurations-Controller 140 den Knoten 130, um auf die Konfigurationsressource 150 zuzugreifen. So kann z. B. der Konfigurations-Controller 140 dem Knoten 130 Informationen zum Zugriff auf die Konfigurations-Ressource 150 bereitstellen, wie z. B. eine Netzwerkadresse mit der Kontakt mit der Konfigurationsressource 150 aufgenommen werden kann, Zugriffsberechtigungen, die für den Zugriff auf die Konfigurationsressource 150 verwendet werden oder andere Informationen. In einigen Implementierungen kann die Konfiguration stattfinden, nachdem der Konfigurations-Controller 140 die Konfigurationsressource bei 310 und 315 (weiter unten beschreiben) vorbereitet. In einigen Implementierungen kann der Konfigurations-Controller 140 eine Client-Anwendung installieren, die mit der Konfigurationsressource 150 am Knoten 130 verknüpft ist und kann diese Client-Anwendung auslösen, wenn er den Knoten 130 anweist, Konfigurationsobjekte von der Konfigurationsressource 150 einzuholen.
  • Bei 310 führt der Konfigurations-Controller 140 Einrichtungsoperationen durch, um die Konfigurationsressource 150 darauf vorzubereiten, Konfigurationsobjekte für den Knoten 130 bereitzustellen. In einigen Implementierungen können diese Einrichtungsoperationen die Bestimmung umfassen, ob die Konfigurationsressource 150 die betroffenen Konfigurationsobjekte bereitstellen kann, die zur Konfiguration 130 erforderlich sind. Bei 315 weist der Konfigurations-Controller 140 die Konfigurationsressource 150 an, den Knoten 130 für den Zugriff auf die Konfigurationsressource 150 zu autorisieren. So kann der Konfigurations-Controller 140 z. B. einen Satz von Zugriffsberechtigungen auf der Konfigurationsressource 150 für den Knoten 130 zu erstellen. In einigen Fällen kann der Konfigurations-Controller 140 der Konfigurationsressource 150 Informationen zum Knoten 130 bereitstellen, wie z. B. seine Netzwerkadresse oder andere identifizierende Informationen, so dass die Konfigurationsressource 150 den Knoten 130 verifizieren, wenn dieser versucht, auf die Ressource zuzugreifen. In einigen Implementierungen kann der Konfigurations-Controller 140 die Schritte 310 und 315 ausführen, indem er eine API verwendet, die spezifisch für die Konfigurationsressource 150 ist. Der Konfigurations-Controller 140 kann über mehrere APIs mit mehreren unterschiedlichen Arten von Konfigurationsressourcen 150 kommunizieren.
  • Bei 320 weist der Konfigurations-Controller 140 den Knoten 130 an, Konfigurationsobjekte von der Konfigurationsressource 150 einzuholen. So kann der Konfigurations-Controller 140z. B. den Knoten 130 anweisen, die bei 305 installierte Client-Anwendung zu starten, um auf die Konfigurationsressource 150 zuzugreifen. Der Konfigurations-Controller 140 kann die Identifizierung des Konfigurationsobjekts oder der einzuholenden Konfigurationsobjekte umfassen. In einigen Implementierungen kann der Konfigurations-Controller 140 den Knoten 130 anweisen, eine Nachricht, die gemäß eines speziell auf die Konfigurationsressource 150 ausgelegten Protokolls über das Netzwerk zu senden, um das Konfigurationsobjekt einzuholen. Bei 330 sendet die Konfigurationsressource 150 das Konfigurationsobjekt aus den Anforderungen aus 325 zurück.
  • Bei 335 wendet der Knoten 130 das von der Konfigurationsressource 150 erhaltene Konfigurationsobjekt an. In einigen Implementierungen kann die Anwendung des Konfigurationsobjekts die Client-Anwendung umfassen, die damit zusammenhängt, dass die Konfigurationsressource 150 das erhaltene Konfigurationsobjekt auf dem Knoten 130 installiert. Der Knoten 130 kann auch ein Ergebnis an den Konfigurations-Controller 140 zurücksenden, wenn er das Konfigurationsobjekt von der Konfigurationsressource 150 bei 330 erhält. Als Antwort kann der Konfigurations-Controller 140 den Konfigurationsbefehl an den Knoten 130 senden, einschließlich Anweisungen zur Installation des Konfigurationsobjekts. Bei 340 sendet der Knoten 130 ein Ergebnis des Konfigurationsobjekts an den Konfigurations-Controller 140. In einigen Implementierungen können die Schritte 320 bis 340 mehrfach wiederholt werden, um mehrere unterschiedliche Konfigurationsobjekte am Knoten 130 anzuwenden. Die Konfigurationsvorschrift 160, die vom Konfigurations-Controller 140 für den Knoten 130 identifiziert wurde, kann festlegen, welche Konfigurationsobjekte am Knoten 130 installiert werden sollen, und kann damit die Häufigkeit festlegen, mit der die Parameter der Schritte 320 bis 340 wiederholt werden können.
  • Bei 345 bestimmt der Konfigurations-Controller 140, dass die Konfiguration des Knotens 130 abgeschlossen ist. In einigen Implementierungen kann der Konfigurations-Controller 140 bestimmen, dass die Konfiguration abgeschlossen ist, basierend auf dem Erhalt eines erfolgreichen Ergebnisses vom Knoten 130, dass jedes Konfigurationsobjekt auf den Knoten 130 angewandt wurde. Bei 350 sendet der Konfigurations-Controller 140 einen Hinweis an den Knoten 130, dass der Konfigurationsprozess abgeschlossen ist. Bei 355 sendet der Knoten 130 einen Hinweis an den Umsetzungsmanager 120 erfolgreich umgesetzt wurde. Bei 360 sendet der Umsetzungsmanager 120 einen Hinweis an den Benutzer/das automatisierte System 110, dass der Knoten 130 erfolgreich erstellt wurde. In einigen Implementierungen erhält der Konfigurations-Controller 140 kein erfolgreiches Ergebnis vom Knoten 130 für eines oder mehrere der Konfigurationsobjekte, die angewandt werden sollen, der Konfigurations-Controller kann eine negative Nachricht an den Knoten 130 senden, wie z. B. einen „Konfigurationsfehler”. Der Knoten 130 kann diesen Hinweis an den Umsetzungsmanager 120 kommunizieren, der diesen Hinweis an den Benutzer/das automatisierte System 110 weiterleiten. In einigen Fällen löscht sich der Knoten 130 als Antwort auf einen derartigen Fehlerhinweis. Das Löschen des Knotens kann auch vom Konfigurations-Controller 140 oder vom Umsetzungsmanager 120 ausgeführt werden.
  • 4 ist ein Diagramm einer Beispielumgebung 400, einschließlich Konfigurations-Controller 140, wie in 1 dargestellt. As shown, the configuration controller 140 includes a configuration service 410, the configuration worker 420, a set of configuration data 432, and a user interface 450. Im Betrieb kann ein Konfigurations-Initiator 440 über ein REST API mit dem Konfigurationsservice 410 kommunizieren. Der Konfigurations-Initiator 440 kann den Konfigurationsservern 410 mitteilen, dass ein neuer Knoten 130 umgesetzt wurde und eine Konfiguration beim Konfigurations-Controller 140 angefordert wird. In einigen Fällen kann dieser Konfigurations-Initiator 440 der Benutzer/das automatisierte System 110 aus 1, der Umsetzungsmanager 120 aus 1, oder jegliche andere Computerkomponente oder Entität sein, die umgesetzt wird oder den Knoten 130 erstellt hat. Der Konfigurations-Initiator 440 kann Informationen zum Knoten 130 bereitstellen, wie eindeutige identifizierende Informationen für den Knoten 130 oder für die Anforderung, worauf der Knoten 130 umgesetzt oder erstellt wurde. Diese Informationen können verwendet werden, um sicherzustellen, dass die Anforderung für die Konfiguration, die vom Konfigurations-Controller 140 erhalten wurde, vom Knoten 130 stammt, der vom Konfigurations-Initiator 440 erstellt oder umgesetzt wurde.
  • Als Antwort auf den Erhalt einer derartigen Mitteilung vom Konfigurations-Initiator 440 kann der Konfigurationsservice 410 die Aufgabe der Konfiguration des Knotens 130 an den Konfigurations-Worker 420 übertragen. In einigen Implementierungen kann dieser Konfigurations-Worker 420 eine Softwarekomponente, wie ein Thread, Modul oder Objekt sein, einschließlich der Funktionalität, die notwendig ist, um eine Konfigurationsanforderungen vom Knoten 130 zu handhaben und die notwendigen Konfigurationsbefehle für den Knoten 130 bereitzustellen, um die erforderliche Konfiguration durchzuführen. In einigen Fällen kann der Konfigurationsservice 410 auch eine Anforderung für eine Konfiguration auslösen, die als aus dem Knoten 130 stammend identifiziert wurde und an den Konfigurations-Worker 420 weitergeleitet wird, der dem Knoten 130 für die Konfiguration zugeordnet wurde, wie z. B. durch ein Netzwerkmodul (nicht abgebildet), das für die interne Weiterleitung von empfangenen Nachrichten innerhalb des Konfigurations-Controllers 140 verantwortlich ist. Wenn der Konfigurations-Worker 420 die Anforderung für eine Konfiguration vom Knoten 130 erhält, kann er mit dem Knoten 130 in der Konfigurationsressource 150 interagieren, um den Knoten 130 wie in Bezug auf 1 bis 3 beschrieben zu konfigurieren.
  • Der Konfigurationsservice 410 und der Konfigurations-Worker 420 können einen Satz Konfigurationsdaten 432 erstellen und pflegen. In einigen Implementierungen können die Konfigurationsdaten 432 Informationen über anstehende Konfigurationsoperationen, die Ergebnisse von vorhergehenden Konfigurationsoperationen (z. B. Erfolg oder Fehler), oder Wiederherstellungsdaten enthalten, die zur Wiederherstellung oder Wiederaufnahme von anstehenden Konfigurationsoperationen im Fall von Ausfällen des Konfigurations-Controllers 140 verwendet werden.
  • Wie veranschaulicht, erstellt der Konfigurationsservice 410 die Rechnungsakten 470 und die Protokolle 480. In einigen Implementierungen umfassen die Rechnungsakten 470 und die Protokolle 480 Informationen zu abgeschlossenen Konfigurationsoperationen. Die Rechnungsakten 470 können z. B. vom Konfigurations-Initiator 440 oder einer anderen Entität zu zahlende Beträge für die erfolgreiche Umsetzung des Knotens 130 umfassen. Die Protokolle 480 können detaillierte Informationen zum Konfigurationsprozess für den Knoten 130 umfassen, wie z. B. welche Konfigurationsbefehle vom Konfigurations-Controller 140 erteilt wurden und die Ergebnisse dieser Befehle. Die Protokolle 480 bieten einen historischen Beleg der Aktivitäten des Konfigurations-Controllers 140.
  • Die Benutzerschnittstelle 450 bietet Zugriff auf Informationen aus den Rechnungsakten 470 und Protokollen 480 an den Administrator 460. So kann z. B. der Administrator 460 einen Webbrowser nutzen, um auf die Benutzerschnittstelle 450 über ein Netzwerk, das mit HTTP ausgestattet ist, zuzugreifen und kann eine Webseite von der Benutzerschnittstelle abrufen, einschließlich Informationen aus den Rechnungsakten 470 und den Protokollen 480. In einigen Implementierungen kann die Benutzerschnittstelle 450 oder eine andere Benutzerschnittstelle als die gezeigte dem Administrator 460 gestatten, in den Rechnungsakten 470 und in den Protokollen 480 nach Informationen zu suchen, diese Informationen zu filtern, diese Informationen auf verschiedene Weisen zu betrachten und die Informationen in verschiedene Formate zu exportieren oder andere Operationen durchzuführen.
  • 5 ist ein Flussdiagramm eines Beispielprozesses 500 für die sichere Konfiguration von Ressourcen in einem Cloud-Computersystem. Zu klaren Darstellung wird der Prozess 500 wird in Bezug auf die in 1 gezeigten Komponenten beschrieben. Bei 505 erhält der Konfigurations-Controller 140 eine Konfigurationsanforderung von einem bestimmten Knoten 130 in einem Cloud-Computernetzwerk. In einigen Fällen umfasst die Konfigurationsanforderung Knoteninformationen für den jeweiligen Knoten. Diese Knoteninformationen können die Identität des jeweiligen Knotens umfassen.
  • Bei 510 stellt der Konfigurations-Controller 140 sicher, dass der jeweilige Knoten 130 für die Konfiguration autorisiert ist, basierend zumindest zum Teil auf den Knoteninformationen. In einigen Fällen umfasst die Verifizierung, dass der jeweilige Knoten 130 für die Konfiguration autorisiert ist, dass der Konfigurations-Controller 140 über das Netzwerk eine Informationsanforderung an den jeweiligen Knoten 130 sendet, anschließend eine Antwort auf die Informationsanforderung vom jeweiligen Knoten 130, die verifiziert, dass die erhaltene Antwort vom Knoten 130 zu einer erwarteten Antwort passt. In einigen Implementierungen umfasst die Informationsanforderung einen oder mehrere Befehle, die nach Erhalt vom betroffenen Knoten 130 ausgeführt werden müssen, und die Antwort auf die Informationsanforderung umfasst den Ausgang, der durch die Ausführung eines oder mehrerer Befehle vom betroffenen Knoten 130 produziert wurde. Die Verifizierung, dass der betroffene Knoten 130 für die Konfiguration autorisiert ist, kann auch die Bestimmung umfassen, dass eine administrative Komponente im Zusammenhang mit dem Cloud-Computernetzwerk einen Knoten erzeugt hat, dessen Knoteninformationen mit dem übereinstimmt, das vom betroffenen Knoten 130 erhalten wurde und dass der Knoten noch konfiguriert werden muss. In einigen Implementierungen umfassen die Knoteninformationen Erstellungsinformationen, die im Einzelnen aufzeigen, wie der betroffene Knoten 130 erstellt wurde und die Verifizierung, dass der betroffene Knoten 130 für die Konfiguration autorisiert ist umfasst die Verifizierung, dass die Erstellungsinformationen mit einer Sicherheitsvorschrift im Zusammenhang mit dem Cloud-Computernetzwerk übereinstimmt. Die Erstellungsinformationen können mindestens einen der folgenden Punkte umfassen: eine administrative Komponente, die den betroffenen Knoten 130 erstellt hat, einen Benutzer der administrativen Komponente, der diesen betroffenen Knoten 130 erzeugt hat, ein Projekt, für den der betroffene Knoten 130 erstellt wurde, oder ein Knotentyp für den betroffenen Knoten.
  • Bei 515, wie zuvor im Zusammenhang mit 1 beschrieben: als Antwort auf die Verifizierung, dass der entsprechende Knoten 130 für die Konfiguration autorisiert wurde, identifiziert der Konfiguration-Controller 140 Konfigurationsmaßnahmen, die am betroffenen Knoten 130 durchgeführt werden müssen, basierend zumindest zum Teil auf der Knoteninformation. Bei 520, wie zuvor im Zusammenhang mit 1 beschrieben: der Konfigurations-Controller 140 sendet einen Konfigurationsbefehl, der einer oder mehreren der identifizierten Konfigurationsmaßnahmen am jeweiligen Knoten 130 entspricht; und der betroffene Knoten 130 führt den Konfigurationsbefehl bei Erhalt aus, um die entsprechenden Konfigurationsmaßnahmen durchzuführen.
  • In einigen Fällen umfasst der Prozessor 500 darüber hinaus, dass der Konfigurations-Controller 140 über das Netzwerk einen Konfigurationsbericht enthält, der sich auf den Konfigurationsbefehl vom entsprechenden Knoten 130 bezieht, einschließlich Berichtsinformationen, die sich auf die Ausführung des Konfigurationsbefehls durch den jeweiligen Knoten 130 beziehen.
  • In einigen Fällen ist der Konfigurationsbefehl ein erster Konfigurationsbefehl; und der Prozess 500 umfasst darüber hinaus, dass der Konfigurations-Controller 140 bestimmt, ob der erste Konfigurationsbefehl basierend auf den Berichtsinformationen erfolgreich vom betroffenen Knoten 130 ausgeführt wurde; und als Antwort auf die Bestimmung, dass der erste Konfigurationsbefehl erfolgreich ausgeführt wurde das Senden, über das Netzwerk, eines zweiten Konfigurationsbefehls, der sich auf eine oder mehrere Konfigurationsmaßnahmen für den jeweiligen Knoten 130 bezieht, worin die eine oder mehrere zusätzliche Konfigurationsmaßnahmen aus den identifizierten Konfigurationsmaßnahmen ausgewählt werden und sich von den Konfigurationsmaßnahmen bzgl. des ersten Konfigurationsbefehls unterscheiden.
  • In einigen Implementierungen umfasst der Prozess 500 darüber hinaus, dass der Konfigurations-Controller 140 bestimmt, dass der Konfigurationsbefehl nicht erfolgreich vom betroffenen Knoten 130 ausgeführt wurde, basierend auf den Berichtsinformationen; und als Antwort auf diese Bestimmung, dass der Konfigurationsbefehl nicht erfolgreich ausgeführt wurde, eine administrative Komponente, die mit dem betroffenen Knoten 130 verknüpft ist, darüber zu benachrichtigen, dass der betroffene Knoten 130 nicht erfolgreich konfiguriert wurde.
  • 6 ist ein Blockdiagramm der Computergeräte 600, 650, die zur Implementierung der hierin beschriebenen Systeme und Verfahren benutzt werden können, entweder als Client oder als Server oder als eine Vielzahl von Servern. Computergerät 600 soll verschiedene Formen von Digitalcomputern darstellen, zum Beispiel Laptops, Desktops, Workstations, Personal Digital Assistants, Server, Blade Server, Mainframes und andere geeignete Computer. Computergerät 650 soll verschiedene Formen mobiler Geräte, wie Personal Digital Assistants, Mobiltelefone, Smartphones und andere ähnliche Computergeräte, darstellen. Zusätzlich dazu kann das Datenverarbeitungsgerät 600 oder 650 USB(Universal Serial Bus)-Speichermedien beinhalten. Die USB-Speichermedien können Betriebssysteme und andere Anwendungen speichern. Die USB-Flashlaufwerke können Eingabe-/Ausgabekomponenten, wie z. B. einen kabellosen Transmitter oder USB-Anschluss enthalten, der in eine USB-Schnittstelle eines anderen Computers eingesteckt werden kann. Die hier gezeigten Komponenten, ihre Verbindungen und Beziehungen und ihre Funktionen sollen nur exemplarisch sein und sollen Implementierungen der in diesem Dokument beschriebenen und/oder beanspruchten Erfindungen nicht einschränken.
  • Das Computergerät 600 beinhaltet einen Prozessor 602, einen Speicher 604, ein Speichergerät 606, eine Hochgeschwindigkeitsschnittstelle 608, die verbunden ist mit Speicher 604 und Hochgeschwindigkeits-Erweiterungsports 610, und eine Niedriggeschwindigkeitsschnittstelle 612 zum Anschluss an den Niedriggeschwindigkeitsbus 614 und das Speichergerät 606. Alle der Komponenten 602, 604, 606, 608, 610 und 612 sind mithilfe verschiedener Busse miteinander verbunden und können an einer gemeinsamen Hauptplatine oder auf andere Weise, wie geeignet, angebracht sein. Der Prozessor 602 kann Anweisungen zur Ausführung innerhalb des Computergeräts 600 verarbeiten, einschließlich Anweisungen, die im Speicher 604 oder auf dem Speichergerät 606 gespeichert sind, um graphische Informationen für eine GUI auf einem externen Eingabe-/Ausgabegerät anzuzeigen, wie Anzeige 616, die an die High-Speed-Schnittstelle 608 gekoppelt ist. In anderen Implementierungen können mehrere Prozessoren und/oder mehrere Busse verwendet sein, wie angemessen, zusammen mit mehreren Speichern und Speichertypen. Außerdem können mehrere Computergeräte 600 verbunden sein, wobei jedes Gerät Teile der nötigen Operationen bereitstellt (z. B. als Serverbank, eine Gruppe von Blade Servern oder ein Multiprozessor-System).
  • Der Speicher 604 speichert Informationen in Computergerät 600. In einer Implementierung ist der Speicher 604 ein flüchtiges Speichergerät oder flüchtige Speichergeräte. In einer anderen Implementierung ist der Speicher 604 ein nicht flüchtiges Speichergerät oder nicht flüchtige Speichergeräte. Der Speicher 604 kann auch eine andere Form von computerlesbarem Medium sein, zum Beispiel ein magnetischer oder optischer Datenträger.
  • Das Speichergerät 606 kann Massenspeicher für das Computergerät 600 bereitstellen. In einer Implementierung kann das Speichergerät 606 ein computerlesbares Medium sein oder enthalten, zum Beispiel ein Diskettengerät, ein Festplattengerät, ein optisches Datenträgergerät oder ein Bandgerät, ein Flash-Speicher oder ein anderes ähnliches Solid-State-Speichergerät oder eine Reihe von Geräten, zum Beispiel Geräte in einem Storage Area Network oder anderen Konfigurationen. Ein Computerprogrammprodukt kann konkret in einem Informationsträger ausgeführt sein. Das Computerprogrammprodukt kann auch Anweisungen enthalten, die, wenn sie ausgeführt werden, ein oder mehrere Verfahren ausführen, wie die oben beschriebenen. Der Informationsträger ist ein computer- oder maschinenlesbares Medium, wie der Speicher 604, das Speichergerät 606 oder der Prozessorspeicher 602.
  • Der Hochgeschwindigkeitscontroller 608 managt bandbreitenintensiver Operationen für das Computergerät 600, während der Niedriggeschwindigkeitscontroller 612 weniger bandbreitenintensive Operationen managt. Eine solche Zuordnung von Funktionen ist nur exemplarisch. In einer Implementierung, ist der High-Speed-Controller 608 an den Speicher 604, die Anzeige 616 (z. B. durch einen Grafikprozessor oder -beschleuniger) und an die -Erweiterungsanschlüsse 610 gekoppelt, die verschiedene Erweiterungskarten aufnehmen können (nicht gezeigt). In der Implementierung ist der Low-Speed-Controller 612 an das Speichergerät 606 und an den Low-Speed-Erweiterungsanschluss 614 gekoppelt. Der Low-Speed-Erweiterungsanschluss, der verschiedene Kommunikationsanschlüsse (z. B. USB, B, Ethernet, Funkethernet) beinhalten kann, kann an ein oder mehrere Eingabe-/Ausgabe-Geräte, wie eine Tastatur, ein Zeigegerät, einen Scanner oder ein Netzwerkgerät, wie einen Switch oder Router, z. B. durch einen Netzwerkadapter gekoppelt sein.
  • Das Computergerät 600 kann in einer Reihe verschiedener Formen implementiert sein, wie in der Figur dargestellt. Zum Beispiel kann es als Standardserver 620, oder mehrmals in einer Gruppe solcher Server implementiert sein. Es kann auch als Teil eines Rackserversystems 624 implementiert sein. Darüber hinaus kann es in einem Personal Computer, wie Laptop-Computer 622, implementiert sein. Alternativ können Komponenten von Computergerät 600 mit anderen Komponenten in einem mobilen Gerät kombiniert sein (nicht dargestellt), z. B. Gerät 650. Jedes dieser Geräte kann eines oder mehrere Computergeräte 600, 650 enthalten, und ein gesamtes System kann aus mehreren Computergeräten 600, 650 bestehen, die miteinander kommunizieren.
  • Das Computergerät 650 beinhaltet unter anderen Komponenten einen Prozessor 652, einen Speicher 664, eine Eingabe-/Ausgabevorrichtung, wie ein Display 654, eine Verbindungsschnittstelle 666, und einen Transceiver 668. Das Gerät 650 kann auch mit einem Speichergerät ausgestattet sein, zum Beispiel einem Microdrive oder einem anderen Gerät, um zusätzlichen Speicher bereitzustellen. Jede der Komponenten 650, 652, 664, 654, 666 und 668 ist mithilfe verschiedener Busse miteinander verbunden, und kann an einer gemeinsamen Hauptplatine oder auf andere Weise, wie geeignet, angebracht sein.
  • Der Prozessor 652 kann Anweisungen im Computergerät 650 ausführen, einschließlich im Speicher 664 gespeicherter Anweisungen. Der Prozessor kann als ein Chipsatz von Chips implementiert werden, die separate und mehrere analoge und digitale Prozessoren beinhalten. Zusätzlich dazu kann der Prozessor mit einer beliebigen Anzahl von Architekturen implementiert werden. So kann der Prozessor 610 beispielsweise ein CISC-Prozessor (Complex Instruction Set Computers), ein RISC-Prozessor (Reduced Instruction Set Computer) oder ein MISC-Prozessor (Minimal Instruction Set Computer) sein. Der Prozessor kann zum Beispiel für die Koordination der anderen Komponenten des Geräts 650 sorgen, zum Beispiel die Kontrolle von Benutzeroberflächen, Anwendungen, die vom Gerät 650 ausgeführt werden, und die drahtlose Kommunikation durch Gerät 650.
  • Der Prozessor 652 kann mit einem Benutzer über die Steueroberfläche 658 und die mit einem Display 654 gekoppelte Displayschnittstelle 656 kommunizieren. Die Anzeige 654 kann zum Beispiel ein TFT-LCD-Display (Thin-Film-Transistor Liquid Crystal Display) oder eine OLED-Anzeige (organische Leuchtdiode) oder eine andere angemessene Anzeigetechnologie sein. Die Displayschnittstelle 656 kann eine geeignete Schaltung enthalten, die das Display 654 dazu bringt, einem Benutzer grafische und andere Informationen zu präsentieren. Die Steuerschnittstelle 658 kann Befehle von einem Benutzer empfangen und sie für die Sendung an Prozessor 652 umwandeln. Zusätzlich kann eine externe Schnittstelle 662 Kommunikation mit dem Prozessor 652 bereitstellen, zum Beispiel, um Nahbereichskommunikation des Geräts 650 mit anderen Geräten zu ermöglichen. Die externe Schnittstelle 662 kann zum Beispiel in einigen Implementierungen, eine kabelgebundene Kommunikation bereitstellen, oder in anderen Implementierungen eine drahtlose Kommunikation, und es können auch mehrere Schnittstellen verwendet werden.
  • Der Speicher 664 speichert Informationen in Computergerät 650. Der Speicher 664 kann als eines oder mehrere computerlesbare Medien, flüchtige Speichergeräte oder nicht flüchtige Speichergeräte implementiert sein. Erweiterungsspeicher 674 kann ebenfalls bereitgestellt und mit dem Gerät 650 über Erweiterungsschnittstelle 672 verbunden werden, die zum Beispiel eine SIMM(Single In Line Memory Module)-Kartenschnittstelle umfassen kann. Dieser Erweiterungsspeicher 674 kann zusätzlichen Speicherplatz für Gerät 650 bereitstellen oder er kann auch Anwendungen oder andere Informationen für Gerät 650 speichern. Insbesondere kann Erweiterungsspeicher 674 Anweisungen zum Ausführen oder Ergänzen der oben beschriebenen Prozesse enthalten, und er kann außerdem sichere Informationen enthalten. Somit kann Erweiterungsspeicher 674 zum Beispiel als Sicherheitsmodul für Gerät 650 bereitgestellt werden und er kann mit Anweisungen programmiert sein, die die sichere Verwendung von Gerät 650 erlauben. Zusätzlich dazu können über die SIMM-Cards sichere Anwendungen bereitgestellt werden, zusammen mit zusätzlichen Informationen, wie dem Ablegen von Identifizierungsinformationen auf der SIMM-Card auf eine Weise, die nicht gehackt werden kann.
  • Der Speicher kann zum Beispiel Flashspeicher und/oder NVRAM-Speicher beinhalten, wie unten besprochen. In einer Implementierung, ist ein Computerprogrammprodukt konkret in einem Informationsträger ausgeführt. Das Computerprogrammprodukt enthält Anweisungen, die, wenn sie ausgeführt werden, ein oder mehrere Verfahren ausführen, wie die oben beschriebenen. Der Informationsträger ist ein computer- oder maschinenlesbares Medium, wie der Speicher 664, die Speichererweiterung 674 oder der Speicher in Prozessor 652, zu empfangen, zum Beispiel, über den Sender-Empfänger 668 oder die externe Schnittstelle 662.
  • Gerät 650 kann drahtlos über Kommunikationsschnittstelle 666 kommunizieren, die eine digitale Signalverarbeitungsschaltung beinhalten kann, wo nötig. Die Verbindungsschnittstelle 666 kann Verbindungen mit verschiedenen Kommunikationstypen oder -protokollen aufbauen, darunter u. a. GSM-Sprachanrufe, SMS, EMS, oder MMS-Messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000 oder GPRS. Eine solche Kommunikation kann zum Beispiel über Funkfrequenzempfänger 668 erfolgen. Zusätzlich kann eine Kurzstreckenkommunikation stattfinden, wie unter Verwendung eines Bluetooth-, WLAN- oder anderen solchen Sende-Empfängern (nicht gezeigt). Außerdem kann GPS(Global Positioning System)-Empfängermodul 670 zusätzliche navigations- und standortbezogene drahtlose Daten für Gerät 650 bereitstellen, die ggf. von Anwendungen verwendet werden können, die auf Gerät 650 ausgeführt werden.
  • Gerät 650 kann außerdem akustisch mithilfe von Audio-Codec 660 kommunizieren, der gesprochene Informationen von einem Benutzer empfangen und in nutzbare digitale Informationen umwandeln kann. Das Audio-Codec 660 kann zudem akustische Töne für einen Benutzer erzeugen, z. B. durch einen Lautsprecher, wie beispielsweise in einem Handgerät von Gerät 650. Diese Töne können Töne von Sprachtelefonanrufen beinhalten, können aufgezeichnete Töne (z. B. Sprachnachrichten, Musikdateien usw.) beinhalten und können auch Töne, die von Anwendungen, welche auf Gerät 650 operieren, beinhalten.
  • Das Computergerät 650 kann in einer Reihe verschiedener Formen implementiert sein, wie in der Figur dargestellt. Zum Beispiel, kann es als Mobiltelefon 680 implementiert werden. Es kann außerdem als Teil eines Smartphones 682, Personal Digital Assistant oder eines anderen ähnlichen mobilen Geräts implementiert sein.
  • Verschiedene Implementierungen der hier beschriebenen Systeme und Techniken können in digitaler elektronischer Verschaltung, integrierter Verschaltung, in speziell konstruierten ASICs (anwendungsspezifische integrierte Schaltungen), in Computer-Hardware, Firmware, Software und/oder Kombinationen davon realisiert werden. Diese verschiedenen Implementierungen können eine Implementierung in einem oder mehreren Computerprogrammen beinhalten, die auf einem programmierbaren System ausführbar und/oder interpretierbar sind, das mindestens einen programmierbaren Prozessor beinhaltet, der ein spezieller Prozessor oder ein Prozessor für allgemeine Zwecke sein kann, und der zum Empfangen von Daten und Anweisungen von und zum Übertragen von Daten und Anweisungen an ein Speichersystem, mindestens eine Eingabevorrichtung und mindestens eine Ausgabevorrichtung gekoppelt ist.
  • Diese Computerprogramme (auch bekannt als Programme, Software, Anwendungen oder Code) enthalten Maschinenbefehle für einen programmierbaren Prozessor und können in eine hochrangige verfahrens- und/oder objektorientierte Programmiersprache und/oder in eine Montage-/Maschinensprache umgesetzt werden. Wie hier verwendet, bezeichnen die Begriffe „maschinenlesbares Medium”, „computerlesbares Medium” ein beliebiges Computerprogrammprodukt, eine beliebige Vorrichtung und/oder ein beliebiges Gerät (z. B. Magnetplatten, optische Platten, Speicher, programmierbare Logikbausteine (PLDs)), die verwendet werden, um einem programmierbaren Prozessor Maschinenanweisungen und/oder Daten bereitzustellen, einschließlich eines maschinenlesbaren Mediums, das Maschinenanweisungen als ein maschinenlesbares Signal empfängt. Der Begriff „maschinenlesbares Signal” bezeichnet ein beliebiges Signal, das verwendet wird, um einem programmierbaren Prozessor Maschinenbefehle und/oder Daten bereitzustellen.
  • Zur Interaktion mit einem Benutzer können die hier beschriebenen Techniken und Systeme auf einem Computer mit einem Bildschirm (z. B. einem CRT-(Cathode Ray Tube) oder LCD-(Liquid Crystal Display)Monitor) für die Anzeige von Informationen für den Benutzer und mit einer Tastatur und einem Zeigegerät (z. B. einer Maus oder einem Trackball), durch die der Benutzer Eingaben an den Computer weiterleiten kann, implementiert werden. Andere Arten von Geräten können auch verwendet werden, um eine Interaktion mit einem Benutzer bereitzustellen; zum Beispiel kann eine dem Benutzer bereitgestellte Rückmeldung irgendeine Form von Sinnesrückmeldung sein (z. B. visuelle Rückmeldung, auditive Rückmeldung oder Tastrückmeldung); und eine Eingabe vom Benutzer kann in einer beliebigen Form empfangen werden, einschließlich akustischer, Sprach- oder Tasteingaben.
  • Die hier beschriebenen Systeme und Techniken können in einem Computersystem implementiert werden, das eine Back-End-Komponente beinhaltet (z. B. als Datenserver) oder das eine Middleware-Komponente (z. B. einen Anwendungsserver) beinhaltet oder das eine Front-End-Komponente (z. B. einen Client-Computer, der eine grafische Benutzeroberfläche oder einen Webbrowser aufweist, durch die ein Benutzer mit einer Implementierung der hier beschriebenen Systeme und Techniken interagieren kann) oder eine beliebige Kombination solcher Back-End, Middleware- oder Front-End-Komponenten beinhaltet. Die Komponenten des Systems können durch eine beliebige Form oder ein beliebiges Medium von digitaler Datenkommunikation (z. B. ein Kommunikationsnetzwerk) miteinander verbunden sein. Beispiele von Datenübertragungsnetzwerken umfassen ein lokales Netz („LAN”), ein Weitverkehrsnetz („WAN”), Peer-to-Peer-Netze (mit Ad-hoc-Mitgliedern und ständigen Mitgliedern), Netzrechnerinfrastrukturen und das Internet. Die Komponenten des Systems können ebenfalls Computergeräte (z. B. Clients oder Server) sein, einschließlich eine oder mehrere virtuelle Umgebungen zur Ausführung von Softwareinstanzen, wie virtuelle Maschineninstanzen oder Containerinstanzen. Diese virtuellen Umgebungen können virtuelle Repräsentationen von Hardware, Software und anderen Ressourcen für die ausführenden Softwareinstanzen bereitstellen.
  • Das Computersystem kann Clients und Server umfassen. Ein Client und Server befinden sich im Allgemeinen ortsfern voneinander und interagieren typischerweise über ein Kommunikationsnetz. Die Beziehung zwischen Client und Server entsteht aufgrund von Computerprogrammen, die auf den jeweiligen Computer laufen und die eine Client-Server-Beziehung zueinander haben. In einigen Implementierungen kann es sich bei den Servern um Knoten innerhalb eines Cloud-Computersystems handeln, auf die Client über ein Kommunikationsnetzwerk zugreifen.
  • Obwohl vorstehend mehrere Implementierungen detailliert beschrieben wurden, sind andere Modifikationen möglich. Darüber hinaus erfordern die logischen Abläufe in den Abbildungen nicht unbedingt die abgebildete Reihenfolge oder die sequenzielle Reihenfolge, um die gewünschten Ergebnisse zu erzielen. Es können weitere Schritte zu den beschriebenen Abläufen hinzugefügt oder aus diesen weggelassen werden, und andere Komponenten zu den beschriebenen Systemen hinzugefügt oder von diesen weggelassen werden. Dementsprechend liegen andere Implementierungen im Geltungsbereich der folgenden Ansprüche.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Nicht-Patentliteratur
    • http://configcontroller.internal.net/start [0035]
    • http://config.blah.com/config/database-manager main [0042]
    • http://config.blah.com/config/ [0042]

Claims (10)

  1. Nichtflüchtiges computerlesbares Medium, das Instruktionen speichert, deren Ausführung mindestens einen Prozessor zur Ausführung von Operationen veranlasst, umfassend: das Empfangen, über ein Netzwerk, einer Konfigurationsanforderung von einem bestimmten Knoten im Cloud-Computernetzwerk, wobei die Konfigurationsanforderung Knoteninformationen für den entsprechenden Knoten beinhaltet; das Verifizieren, dass der betroffene Knoten für die Konfiguration autorisiert ist, basierend zumindest zum Teil auf der Knoteninformation; als Antwort auf das Verifizieren, dass der entsprechende Knoten für die Konfiguration autorisiert wurde, das Identifizieren der Konfigurationsmaßnahmen am entsprechenden Knoten, basierend zumindest zum Teil auf der Knoteninformation; und das Senden, über das Netzwerk, eines Konfigurationsbefehls, der einer oder mehreren der identifizierten Konfigurationsmaßnahmen am jeweiligen Knoten entspricht, worin der bestimmte Knoten den Konfigurationsbefehl bei Erhalt ausführt, um die entsprechenden Konfigurationsmaßnahmen durchzuführen.
  2. Computerlesbares Medium nach Anspruch 1, wobei die Operationen des Weiteren Folgendes umfassen: das Empfangen, über das Netzwerk, eines Konfigurationsberichts, der sich auf den Konfigurationsbefehl vom entsprechenden Knoten bezieht, einschließlich Berichtsinformationen, die sich auf die Ausführung des Konfigurationsbefehls durch den jeweiligen Knoten beziehen.
  3. Computerlesbares Medium nach Anspruch 2, wobei der Konfigurationsbefehl ein erster Konfigurationsbefehl ist, wobei die Operationen des Weiteren Folgendes umfassen: das Bestimmen, dass der erste Konfigurationsbefehl erfolgreich vom jeweiligen Knoten ausgeführt wurde, basierend auf den Berichtsinformationen; und als Antwort auf das Bestimmen, dass der erste Konfigurationsbefehl erfolgreich ausgeführt wurde, das Senden, über das Netzwerk, eines zweiten Konfigurationsbefehls, der sich auf eine oder mehrere Konfigurationsmaßnahmen für den jeweiligen Knoten bezieht, worin der eine oder mehrere zusätzliche Konfigurationsmaßnahmen aus den identifizierten Konfigurationsmaßnahmen ausgewählt werden und sich von den Konfigurationsmaßnahmen bzgl. des ersten Konfigurationsbefehls unterscheiden.
  4. Computerlesbares Medium nach Anspruch 2, wobei die Operationen des Weiteren Folgendes umfassen: das Bestimmen, dass der erste Konfigurationsbefehl nicht erfolgreich vom jeweiligen Knoten ausgeführt wurde, basierend auf den Berichtsinformationen; und als Antwort auf das Bestimmen, dass der Konfigurationsbefehl nicht erfolgreich ausgeführt wurde, das Inkenntnissetzen einer administrativen Komponente im Zusammenhang mit dem betroffenen Knoten, dass der jeweilige Knoten nicht erfolgreich konfiguriert wurde.
  5. Computerlesbares Medium nach Anspruch 1, worin das Verifizieren, dass der betroffene Knoten für eine Konfiguration autorisiert ist, Folgendes umfasst: Senden, über das Netzwerk, einer Informationsanforderung an den betroffenen Knoten; das Senden, über das Netzwerk, einer Antwort auf die Informationsanforderung des betroffenen Knotens; und das Verifizieren, dass die erhaltene Antwort vom betroffenen Knoten zu einer erwarteten Antwort passt.
  6. Computerlesbares Medium nach Anspruch 5, worin die Informationsanforderung einen oder mehrere Befehle umfasst, die nach Erhalt vom betroffenen Knoten ausgeführt werden müssen, und die Antwort auf die Informationsanforderung umfasst den Ausgang, der durch die Ausführung eines oder mehrerer Befehle vom betroffenen Knoten produziert wurde.
  7. Computerlesbares Medium nach Anspruch 1, worin das Verifizieren, dass der betroffene Knoten für die Konfiguration autorisiert ist, das Bestimmen umfasst, dass eine administrative Komponente im Zusammenhang mit dem Cloud-Computernetzwerk einen Knoten erzeugt hat, dessen Knoteninformationen mit dem übereinstimmt, das vom betroffenen Knoten erhalten wurden und dass der Knoten noch konfiguriert werden muss.
  8. Computerlesbares Medium nach Anspruch 1, worin die Knoteninformationen Erstellungsinformationen umfassen, die im Einzelnen aufzeigen, wie der betroffene Knoten erstellt wurde, und worin das Verifizieren, dass der betroffene Knoten für die Konfiguration autorisiert ist, das Verifizieren umfasst, dass die Erstellungsinformationen mit einer Sicherheitsvorschrift im Zusammenhang mit dem Cloud-Computernetzwerk übereinstimmen.
  9. Computerimplementiertes Medium nach Anspruch 8, worin die Erstellungsinformationen mindestens einen der folgenden Punkte umfassen: eine administrative Komponente, die den betroffenen Knoten erstellt hat, einen Benutzer der administrativen Komponente, der diesen betroffenen Knoten erzeugt hat, ein Projekt, für den der betroffene Knoten erstellt wurde, oder ein Knotentyp für den betroffenen Knoten.
  10. System, das Folgendes umfasst: einen Speicher zum Speichern von Daten; und einen oder mehrere Prozessoren, die folgende Operationen durchführen können: das Empfangen, über ein Netzwerk, einer Konfigurationsanforderung von einem bestimmten Knoten im Cloud-Computernetzwerk, wobei die Konfigurationsanforderung Knoteninformationen für den entsprechenden Knoten beinhaltet; das Verifizieren, dass der betroffene Knoten für die Konfiguration autorisiert ist, basierend zumindest zum Teil auf der Knoteninformation; als Antwort auf die Verifizierung, dass der entsprechende Knoten für die Konfiguration autorisiert wurde, Identifizierung der Konfigurationsmaßnahmen am entsprechenden Knoten, basierend zumindest zum Teil auf der Knoteninformation; und das Senden, über das Netzwerk, eines Konfigurationsbefehls, der einer oder mehreren der identifizierten Konfigurationsmaßnahmen am jeweiligen Knoten entspricht, worin der bestimmte Knoten den Konfigurationsbefehl bei Erhalt ausführt, um die entsprechenden Konfigurationsmaßnahmen durchzuführen.
DE202016008055.6U 2016-06-16 2016-06-16 Sichere Konfiguration von Cloud-Computerknoten Active DE202016008055U1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE202016008055.6U DE202016008055U1 (de) 2016-06-16 2016-06-16 Sichere Konfiguration von Cloud-Computerknoten

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE202016008055.6U DE202016008055U1 (de) 2016-06-16 2016-06-16 Sichere Konfiguration von Cloud-Computerknoten

Publications (1)

Publication Number Publication Date
DE202016008055U1 true DE202016008055U1 (de) 2017-02-16

Family

ID=58281557

Family Applications (1)

Application Number Title Priority Date Filing Date
DE202016008055.6U Active DE202016008055U1 (de) 2016-06-16 2016-06-16 Sichere Konfiguration von Cloud-Computerknoten

Country Status (1)

Country Link
DE (1) DE202016008055U1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020168826A1 (zh) * 2019-02-22 2020-08-27 华为技术有限公司 设备配置方法、系统和装置

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
http://config.blah.com/config/
http://config.blah.com/config/database-manager main
http://configcontroller.internal.net/start

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020168826A1 (zh) * 2019-02-22 2020-08-27 华为技术有限公司 设备配置方法、系统和装置

Similar Documents

Publication Publication Date Title
DE60205289T2 (de) System und Verfahren zur gesicherte Funkübertragung von Konfigurationsdaten
DE602005003314T2 (de) Spezialisierung der Unterstützung für eine Verbandsbeziehung
DE202016107487U1 (de) Authentifizierung eines lokalen Gerätes
DE102014113582B4 (de) Vorrichtung, Verfahren und System für die kontextbewusste Sicherheitssteuerung in einer Cloud-Umgebung
DE102019103927A1 (de) Systeme und Verfahren zur Ausführung eines Sicherheitsprotokolls in einem durch hierarchische Zustandsautomaten gesteuerten Ausführungsplan
DE102017201271A1 (de) Sichere verbindungen für niedrigenergie-geräte
DE102012203561A1 (de) Die Personifikation/Bevollmächtigung eines Benutzers in einem Merkmal-basierenden Authentifizierungssystem
DE102008030523A1 (de) System und Verfahren zur sicheren Dateiübertragung
DE202013012485U1 (de) System für Browseridentität
DE112017007393T5 (de) System und verfahren für netzwerkvorrichtungssicherheits- und vertrauenswertbestimmung
DE102011013469A1 (de) Trusted group einer mehrzahl von einrichtungen mit einer sicheren authentisierung mit single sign-on
DE112020004289T5 (de) Einrichten einer sicherheitszuordnung und einer berechtigungsprüfung zum sichern einer datenübertragung zwischen einem initiator und einem antwortenden
DE112011102224B4 (de) Identitätsvermittlung zwischen Client- und Server-Anwendungen
DE112020004286T5 (de) Einrichten einer sicherheitszuordnung und einer berechtigungsprüfung zum sichern einer datenübertragung zwischen einem initiator und einem antwortenden
DE202012013453U1 (de) Gehostete Speichersperrung
DE112020000535B4 (de) Fehlerbehebung innerhalb und außerhalb der eigenen Räumlichkeiten
DE112016002392T5 (de) Autorisierung in einem verteilten System unter Verwendung von Zugriffssteuerungslisten und Gruppen
DE102014225538A1 (de) Verwaltungsvorrichtung und verwaltungsverfahren für eine verwaltungsvorrichtung
DE112018006443T5 (de) Multifaktor-authentifizierung
DE112020003699T5 (de) Gleichzeitige aktivierung von verschlüsselung auf einem betriebspfad an einem speicheranschluss
WO2020229537A1 (de) Verfahren zum selektiven ausführen eines containers und netzwerkanordnung
WO2013017394A1 (de) Zugangsregelung für daten oder applikationen eines netzwerks
DE112022000280T5 (de) Identitätsautorität
DE112021005026T5 (de) Persistente quellwerte für angenommene alternative identitäten
DE10024347B4 (de) Sicherheitsservice-Schicht

Legal Events

Date Code Title Description
R207 Utility model specification
R081 Change of applicant/patentee

Owner name: GOOGLE LLC (N.D.GES.D. STAATES DELAWARE), MOUN, US

Free format text: FORMER OWNER: GOOGLE INC., MOUNTAIN VIEW, CALIF., US

R082 Change of representative

Representative=s name: BETTEN & RESCH PATENT- UND RECHTSANWAELTE PART, DE

R150 Utility model maintained after payment of first maintenance fee after three years
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012240000

Ipc: H04L0041000000

R151 Utility model maintained after payment of second maintenance fee after six years