Présentation des clés API unifiées pour Elastic Cloud Serverless et Elasticsearch

Imaginez que vous êtes ingénieur en fiabilité des sites (SRE) responsable d’un parc croissant de projets Elastic Cloud Serverless : Elastic Observability pour votre infrastructure de production, Elastic Security pour votre centre des opérations de sécurité (SOC) et Elasticsearch pour votre application orientée client. Chaque projet dispose de sa propre clé API Elasticsearch. Votre pipeline d’intégration continue et de déploiement continu (CI/CD) nécessite une clé API Cloud distincte pour provisionner et gérer ces projets. Chaque trimestre arrive le jour de rotation : vous parcourez chaque projet, générez de nouvelles clés, mettez à jour l’état Terraform, redéployez vos pipelines et espérez que rien ne passe entre les mailles du filet. Lorsqu’un incident survient à 2 h du matin et que vous devez révoquer rapidement des accès, vous consultez une feuille de calcul de secrets pour déterminer quelle clé correspond à quel projet et à quel service.

Aujourd’hui, tout devient beaucoup plus simple. Les clés API Elastic Cloud peuvent désormais être utilisées pour s’authentifier directement auprès des API Elasticsearch et Kibana dans Elastic Cloud Serverless. Vous pouvez désormais utiliser un seul identifiant pour gérer les ressources de votre organisation et exécuter des opérations sur les données, comme des requêtes Elasticsearch Query Language (ES|QL), l’ingestion de données et l’alerting.

Voyons pourquoi nous avons conçu cette solution, comment nous avons mis en place une couche d’identité distribuée à l’échelle mondiale pour la rendre possible, et comment elle pose les bases d’une recherche interprojets.

Le fardeau de la gestion des secrets

Mettre en place des pipelines CI/CD fiables, des workflows GitOps ou une automatisation Terraform autour des plateformes de données a un coût caché : la prolifération des secrets.

Dans le modèle précédent, les développeurs étaient confrontés à une gestion de l’authentification fragmentée :

• Plan de contrôle (clés API Elastic Cloud) : clés au périmètre de l’organisation utilisées pour créer des projets, inviter des utilisateurs et gérer la facturation via l’API Elastic Cloud.
• Plan de données (clés API Elasticsearch) : Clés de portée projet créées à l'intérieur d'un projet Serverless spécifique pour interagir avec Elasticsearch et Kibana API.

Cela signifiait que votre script de déploiement devait s’authentifier auprès d’Elastic Cloud, provisionner un projet Serverless, extraire une clé API Elasticsearch nouvellement générée depuis ce projet, puis injecter cette seconde clé dans l’application en aval ou l’outil d’automatisation, ce qui entraînait des pipelines complexes, des journaux d’audit fragmentés et un risque accru de fuite d’identifiants.

Authentification unifiée dans Elastic Cloud Serverless

Avec cette version, cette séparation disparaît pour les projets Serverless. Vous pouvez désormais créer une clé API Elastic Cloud explicitement autorisée pour les API Cloud, Elasticsearch et Kibana.

• Avant : une clé API Elastic Cloud était strictement un jeton du plan de contrôle. Elle permettait de créer des projets, de gérer la facturation et d’inviter des utilisateurs, mais présentait une limite stricte : elle ne pouvait pas être utilisée pour appeler les API Elasticsearch ou Kibana au sein de ces projets. Vous aviez toujours besoin d’une seconde clé, spécifique au projet, pour les opérations sur les données.
• Maintenant : en optant pour l'accès aux API Cloud, Elasticsearch et Kibana lors de la création d'une clé API Elastic Cloud, la limite stricte est supprimée pour Serverless. Cette clé API devient un véritable identifiant unifié. Il conserve sa capacité à gérer l'infrastructure de votre organisation, tout en bénéficiant d'un accès natif pour interroger, ingérer et analyser les données de tout projet Serverless autorisé.

En unifiant cela avec une seule clé API Elastic Cloud, vous disposez d’une identité unique pouvant être définie par périmètre, auditée, renouvelée et révoquée comme une seule entité. Chaque appel API, qu’il serve à provisionner un nouveau projet ou à exécuter une requête ES|QL, apparaît sous le même identifiant dans vos journaux d’audit, vous offrant une trace unique à suivre lors des enquêtes d’incident ou des audits de conformité. La rotation des identifiants devient une opération en une seule étape, au lieu d’une mise à jour coordonnée entre les secrets du plan de contrôle et du plan de données. Et comme les rôles sont attribués par projet, une seule clé peut couvrir plusieurs projets : gérer l’ingestion dans votre projet d’observabilité et exécuter des requêtes dans votre projet de sécurité, sans avoir à manipuler des identifiants distincts pour chacun.

Il est important de noter qu' unifié ne signifie pas tout-puissant. En utilisant le payload role_assignments, vous pouvez restreindre la portée d'une clé unifiée à un seul projet et à un rôle spécifique (lecture seule, par exemple), ce qui garantit que le rayon d'impact reste totalement contenu si un identifiant est exposé. En cas de départ d'un développeur ou de mise hors service d'une application, vous pouvez révoquer une seule clé depuis la console Elastic Cloud, ce qui met immédiatement fin à l'accès à la fois au plan de contrôle et à tous les projets Elasticsearch associés.

(Remarque : pour les déploiements Elastic Cloud Hosted/gérés, les clés API Cloud ne gèrent toujours que le plan de contrôle.) La prise en charge de l’extension aux API de la stack hébergée est prévue dans une prochaine version.)

Automatiser vos workflows

La mise en route est simple. Vous pouvez configurer cela entièrement via la console Elastic Cloud ou l'automatiser en utilisant l'API Elastic Cloud.

Le processus de l'interface utilisateur reste le même, mais vous pouvez désormais sélectionner l'accès aux API Cloud, Elasticsearch et Kibana dans l'affectation des rôles du projet.

Voici comment créer une clé unifiée de façon programmatique en utilisant l’API Elastic Cloud. Notez le tableau application_roles, car c’est ce qui donne à la clé un accès natif au plan de données Elasticsearch :

Une fois créée, il vous suffit de transmettre exactement la même clé dans l'en-tête Authorization: ApiKey à api.elastic-cloud.com et à vos points de terminaison Elasticsearch Serverless spécifiques.

En coulisses : conception d’une couche d’identité distribuée

Faire fonctionner une clé API Cloud à la fois sur le plan de contrôle et sur le plan de données ne se résume pas à transmettre un jeton. Cela nécessite de résoudre un défi fondamental des systèmes distribués.

Historiquement, les clés API Cloud étaient stockées dans un cluster de sécurité global centralisé. Cela fonctionne bien pour les opérations du plan de contrôle, où une latence plus élevée est acceptable. Cependant, les requêtes de données Elasticsearch nécessitent une latence extrêmement faible. Nous ne pouvons pas nous permettre un aller-retour à travers le globe vers un plan de contrôle central pour valider chaque requête de recherche ou d’ingestion.

Pour résoudre ce problème, nous avons introduit une nouvelle architecture d’authentification reposant sur un datastore distribué à l’échelle mondiale. Le diagramme de séquence suivant montre un client envoyant une requête Elasticsearch à l’aide d’une clé API Elastic Cloud, illustrant comment l’authentification s’effectue entièrement dans la région locale, sans aller-retour vers le plan de contrôle global. Elasticsearch délègue l’authentification au service IAM régional, qui valide la clé et résout ses attributions de rôles à partir d’une réplique locale de la base de données distribuée à l’échelle mondiale. Une fois autorisé, Elasticsearch exécute la requête et renvoie les résultats au client.

Persistance distribuée à l’échelle mondiale

Au lieu de s’appuyer uniquement sur un cluster de sécurité centralisé, les clés API Elastic Cloud et leurs définitions de rôles associées sont désormais stockées dans une base de données distribuée à l’échelle mondiale et hautement disponible. Cette base de données synchronise les données de gestion des identités et des accès (IAM) entre le plan de contrôle global et les plans de données régionaux où vos projets Serverless s’exécutent réellement.

Validation locale avec IAM régional

Lorsque votre client envoie une requête à Elasticsearch à l’aide d’une clé API Elastic Cloud, la requête ne revient pas vers le plan de contrôle global. Elle est plutôt redirigée vers le nouveau service IAM régional. Celui-ci valide la clé à partir de la réplique locale de la base de données, garantissant une authentification avec une latence quasi nulle et totalement isolée des pannes du plan de contrôle global.

Mappage dynamique des rôles

L'authentification n'est que la moitié de la bataille ; le système doit également autoriser la demande. Le service IAM régional traduit instantanément vos attributions de rôles au niveau du cloud (par exemple, application_roles) en privilèges Elasticsearch natifs. Elasticsearch peut alors autoriser et exécuter la requête localement, sans jamais avoir besoin d’un index .security local.

La base de la recherche interprojets

Cette architecture d'identité distribuée est un élément fondamental pour l'avenir de la plateforme Elastic.

L'identité et l'accès étant désormais unifiés et synchronisés à l'échelle mondiale, nous disposons du framework nécessaire pour transmettre votre identité en toute sécurité entre différents projets. Cela permet d'activer les capacités de recherche inter-projets (CPS) à venir pour Serverless.

Avec CPS, vous pourrez interroger des données couvrant plusieurs projets Serverless distants, par exemple en combinant des charges de travail de sécurité et d’observabilité, aussi simplement que s’il s’agissait d’un seul jeu de données. En s’appuyant sur des clés API unifiées, le système peut automatiquement évaluer vos autorisations sur l’ensemble des projets simultanément, sans vous obliger à configurer des relations de confiance complexes, des certificats ou des identifiants dupliqués pour chaque projet cible.

En savoir plus

Êtes-vous prêt à simplifier votre stack ?

• Lisez la documentation sur les clés API d'Elastic Cloud pour savoir comment attribuer l'accès à la pile.
• Consultez la référence Create API key (Elastic Cloud API) pour automatiser la génération de clés.
• Consultez les clés API Elastic pour une comparaison complète des types de clés sur la plateforme Elastic.

Commencez ou continuez à construire dans Elastic Cloud dès aujourd’hui.

Avis de non-responsabilité

La publication et la date de publication de toute fonctionnalité ou fonction décrite dans le présent article restent à la seule discrétion d'Elastic. Toute fonctionnalité ou fonction qui n'est actuellement pas disponible peut ne pas être livrée à temps ou ne pas être livrée du tout.