Einführung einheitlicher API-Schlüssel für Elastic Cloud Serverless und Elasticsearch

Stellen Sie sich vor, Sie sind Site Reliability Engineer (SRE) und für eine wachsende Fleet von Elastic Cloud Serverless-Projekten verantwortlich: Elastic Observability für Ihre Produktionsinfrastruktur, Elastic Security für Ihr Security Operations Center (SOC)-Team und Elasticsearch für Ihre kundenseitige Anwendung. Jedes Projekt hat seinen eigenen Elasticsearch-API-Schlüssel. Ihre Pipeline für Continuous Integration und Continuous Delivery (CI/CD) benötigt einen separaten Cloud-API-Schlüssel, um diese Projekte bereitzustellen und zu verwalten. Einmal pro Quartal ist Rotationstag: Sie gehen jedes Projekt durch, erstellen neue Schlüssel, aktualisieren Ihren Terraform-State, stellen Ihre Pipelines erneut bereit und hoffen, dass nichts durchs Raster fällt. Wenn um 02:00 Uhr ein Vorfall eintritt und Sie den Zugriff schnell widerrufen müssen, prüfen Sie eine Tabelle mit Anmeldeinformationen gegen, um herauszufinden, welcher Schlüssel zu welchem Projekt und welchem Dienst gehört.

Heute ist dies viel einfacher. Elastic Cloud API-Schlüssel können nun direkt zur Authentifizierung bei den Elasticsearch- und Kibana-APIs auf Elastic Cloud Serverless verwendet werden. Sie können nun eine einzige Zugangsberechtigung verwenden, um die Ressourcen Ihrer Organisation zu verwalten und Datenoperationen auszuführen, wie z. B. Elasticsearch Abfragesprache (ES|QL)-Abfragen, Daten-Ingestion und Alerting.

Schauen wir uns an, warum wir das entwickelt haben, wie wir eine global verteilte Identitätsschicht konstruiert haben, um dies zu ermöglichen, und wie sie die Grundlage für die projektübergreifende Suche bildet.

Die Last der geheimen Verwaltung

Der Aufbau zuverlässiger CI/CD-Pipelines, GitOps-Workflows oder Terraform-Automatisierung rund um Datenplattformen geht mit einem versteckten Kostenfaktor einher: der Geheimnisverbreitung.

Im vorherigen Modell hatten Entwickler ein uneinheitliches Authentifizierungskonzept:

• Steuerebene (Elastic Cloud API-Schlüssel): Organisationsbezogene Schlüssel, die zum Erstellen von Projekten, zur Einladung von Nutzern und zur Verwaltung der Abrechnung über die Elastic Cloud API verwendet werden.
• Datenebene (Elasticsearch-API-Schlüssel): Projektbezogene Schlüssel, die innerhalb eines bestimmten Serverless-Projekts erstellt werden, um mit Elasticsearch und Kibana-APIs zu interagieren.

Das bedeutete, dass Ihr Deployment-Skript sich bei Elastic Cloud authentifizieren, ein Serverless-Projekt bereitstellen, einen neu erstellten Elasticsearch-API-Schlüssel aus diesem speziellen Projekt extrahieren und diesen zweiten Schlüssel dann in die Downstream-Anwendung oder das Automatisierungstool einfügen musste, was zu komplexen Pipelines, fragmentierten Audit-Logs und einem höheren Risiko von Credential-Lecks führte.

Vereinheitlichte Authentifizierung in Elastic Cloud Serverless

Mit dieser Version entfällt die Trennung bei Serverless-Projekten. Sie können jetzt einen Elastic Cloud API-Schlüssel erstellen, der explizit für Cloud-, Elasticsearch- und Kibana-APIs autorisiert ist.

• Vorher: Ein Elastic Cloud-API-Schlüssel war ausschließlich ein Token für die Steuerungsebene. Er konnte Projekte erstellen, die Abrechnung verwalten und Benutzer einladen. Es gab jedoch eine klare Grenze: Es konnte nicht verwendet werden, um die Elasticsearch- oder Kibana-APIs innerhalb dieser Projekte aufzurufen. Sie benötigten immer einen zweiten, projektspezifischen Schlüssel für Datenoperationen.
• Jetzt: Durch die Aktivierung des Zugriffs auf Cloud, Elasticsearch und Kibana-APIs bei der Erstellung eines Elastic-Cloud-API-Schlüssels wird die harte Grenze für Serverless entfernt. Dieser API-Schlüssel wird zu einem wirklich einheitlichen Berechtigungsnachweis. Er behält seine Fähigkeit bei, die Infrastruktur Ihrer Organisation zu verwalten und gleichzeitig nativen Zugriff auf das Abfragen, Ingestieren und Analysieren von Daten in jedem autorisierten Serverless-Projekt zu ermöglichen.

Indem Sie dies unter einem einzigen Elastic Cloud API-Schlüssel vereinen, erhalten Sie eine einzige Identität, die als eine Einheit festgelegt, geprüft, rotiert und widerrufen werden kann. Jeder API-Aufruf, egal ob er ein neues Projekt bereitstellt oder eine ES|QL-Abfrage ausführt, erscheint unter denselben Anmeldedaten in Ihren Auditprotokollen, was Ihnen eine einzige Spur bei Vorfalluntersuchungen oder Compliance-Überprüfungen bietet. Die Rotation von Anmeldeinformationen wird zu einem einstufigen Vorgang, anstatt einer koordinierten Aktualisierung über separate Steuerungs- und Datenebenen-Geheimnisse. Und da Rollenzuweisungen pro Projekt erfolgen, kann ein einzelner Schlüssel mehrere Projekte umfassen, die Ingestion in Ihrem Beobachtbarkeit-Projekt verwalten und Abfragen in Ihrem Sicherheitsprojekt ausführen, ohne dass für jedes einzelne Zugangsdaten getrennt werden müssen.

Wichtig ist, dass vereint nicht allmächtig bedeutet. Durch die Verwendung der role_assignments Nutzdaten können Sie einen einheitlichen Schlüssel strikt auf ein einzelnes Projekt und eine bestimmte Rolle (z. B. schreibgeschützt) beschränken und so sicherstellen, dass der Explosionsradius vollständig eingegrenzt bleibt, falls ein Berechtigungsnachweis jemals offengelegt wird. Wenn ein Entwickler ausscheidet oder eine Anwendung eingestellt wird, können Sie einen einzelnen Schlüssel aus der Elastic Cloud-Konsole widerrufen und somit den Zugriff sowohl auf der Kontrollebene als auch auf allen zugehörigen Elasticsearch-Projekten sofort beenden.

(Hinweis: Für Elastic Cloud Hosted/verwaltete Elastic Cloud-Deployments verwalten API-Schlüssel weiterhin nur die Steuerungsebene.) Die Unterstützung für die Erweiterung auf gehostete Stack-APIs ist für eine zukünftige Version geplant.

Automatisieren Sie Ihre Workflows

Der Einstieg ist einfach. Sie können dies komplett über die Elastic Cloud-Konsole konfigurieren oder mit der Elastic Cloud API automatisieren.

Der Benutzeroberflächenprozess bleibt derselbe, aber jetzt können Sie Cloud-, Elasticsearch- und Kibana-API-Zugriff unter der Projektrollenzuweisung auswählen.

Hier erfahren Sie, wie Sie einen einheitlichen Schlüssel programmatisch mit der Elastic Cloud API erstellen. Beachten Sie das application_roles-Array, da dieses dem Schlüssel nativen Zugriff auf die Elasticsearch-Datenebene gewährt:

Nach der Erstellung übergeben Sie einfach genau denselben Schlüssel im Header Authorization: ApiKey sowohl an api.elastic-cloud.com als auch an Ihre spezifischen Serverless Elasticsearch-Endpunkte.

Hinter den Kulissen: Aufbau einer verteilten Identitätsebene

Die Verwendung eines Cloud-API-Schlüssels sowohl auf der Steuerungsebene als auch auf der Datenebene ist nicht so einfach wie die Übergabe eines Tokens. Es erfordert das Lösen einer grundlegenden Herausforderung in verteilten Systemen.

Historisch gesehen befanden sich Cloud-API-Schlüssel in einem zentralisierten globalen Sicherheitscluster. Das funktioniert gut für Operationen auf der Steuerungsebene, bei denen eine höhere Latenz akzeptabel ist. Allerdings erfordern Elasticsearch-Datenanfragen eine äußerst niedrige Latenz. Wir können uns keine Reise um den Globus zu einer zentralen Steuerungsebene leisten, um jede einzelne Suchanfrage oder jeden einzelnen Ingest-Anfrage zu validieren.

Um dies zu lösen, haben wir eine neue Authentifizierungsarchitektur eingeführt, die von einem global verteilten Datenspeicher unterstützt wird. Das folgende Sequenzdiagramm zeigt einen Client, der eine Elasticsearch-Abfrage mit einem Elastic Cloud API-Schlüssel sendet, und veranschaulicht, wie die Authentifizierung vollständig innerhalb der lokalen Region stattfindet, ohne eine Rundreise zur globalen Kontrollebene. Elasticsearch delegiert die Authentifizierung an den Regional IAM Service, der den Schlüssel validiert und seine Rollenzuweisungen anhand eines lokalen Replikats der global verteilten Datenbank auflöst. Nach der Autorisierung führt Elasticsearch die Abfrage aus und liefert dem Client die Ergebnisse.

Weltweit verteilte Persistenz

Anstatt sich ausschließlich auf einen zentralisierten Sicherheitscluster zu verlassen, werden die Elastic Cloud API-Schlüssel und die zugehörigen Rollendefinitionen jetzt in einer global verteilten, hochverfügbaren Datenbank gespeichert. Diese Datenbank synchronisiert Identitäts- und Zugriffsmanagementdaten (IAM) über die globale Kontrollebene und die regionalen Datenebenen, in denen Ihre Serverless-Projekte tatsächlich laufen.

Lokale Validierung mit regionalem IAM

Wenn Ihr Client eine Anfrage an Elasticsearch mit einem Elastic Cloud API-Schlüssel sendet, wird die Anfrage nicht an die globale Steuerungsebene zurückgesendet. Stattdessen wird er an den neuen regionalen IAM-Dienst weitergeleitet. Der Schlüssel wird mit der lokalen Datenbankreplik abgeglichen, wodurch sichergestellt wird, dass die Authentifizierung mit einer Latenzzeit von nahezu Null erfolgt und vollständig von Ausfällen der globalen Kontrollebene abgeschirmt ist.

Dynamisches Rollen-Mapping

Die Authentifizierung ist nur die halbe Miete; das System muss die Anfrage ebenfalls autorisieren. Der regionale IAM-Dienst übersetzt Ihre Cloud-Rollenzuweisungen, z. B. application_roles, sofort in native Elasticsearch-Privilegien. Elasticsearch kann die Anfrage dann lokal autorisieren und ausführen, ohne jemals einen lokalen .security-Index zu benötigen.

Die Grundlage für Cross-Project Search

Diese verteilte Identitätsarchitektur ist ein grundlegender Baustein für die Zukunft der Elastic-Plattform.

Da Identität und Zugriff nun einheitlich und global synchronisiert sind, verfügen wir über das notwendige Framework, um Ihre Identität sicher zwischen verschiedenen Projekten weiterzugeben. Dies ermöglicht die kommenden Cross-Project Search (CPS)-Funktionen für Serverless.

Mit CPS können Sie Daten aus mehreren entfernten Serverless-Projekten abfragen – beispielsweise durch die Kombination von Security- und Observability-Workloads. Und das so einfach, als wären es ein einziger Datensatz. Durch die Verwendung einheitlicher API-Schlüssel kann das System Ihre Berechtigungen in allen Projekten automatisch und gleichzeitig auswerten, ohne dass Sie komplexe Vertrauensbeziehungen, Zertifikate oder doppelte Zugangsdaten für jedes Zielprojekt konfigurieren müssen.

Weitere Informationen

Sind Sie bereit, Ihren Stack zu vereinfachen?

• Lesen Sie die Dokumentation zu Elastic Cloud API-Schlüsseln, um zu erfahren, wie Sie Stack-Zugriff zuweisen.
• Schauen Sie sich API-Schlüssel erstellen (Elastic Cloud API) an, um die Schlüsselgenerierung zu automatisieren.
• Überprüfen Sie die Elastic API-Schlüssel, um einen vollständigen Vergleich der Schlüsseltypen auf der gesamten Elastic-Plattform zu erhalten.

Beginnen Sie noch heute mit dem Aufbau in Elastic Cloud oder setzen Sie Ihre Arbeit fort.

Verzichtserklärung

Die Entscheidung über die Veröffentlichung der in diesem Blogeintrag beschriebenen Leistungsmerkmale und Features sowie deren Zeitpunkt liegt allein bei Elastic. Es ist möglich, dass noch nicht verfügbare Leistungsmerkmale oder Features nicht rechtzeitig oder überhaupt nicht veröffentlicht werden.