Contexte et exigences de la gestion de clés

Les projets d’IA d’entreprise manipulent des modèles, des poids et des checkpoints qui sont classés comme données sensibles. Les audits exigent une liste nominative de tous les acteurs capables de déchiffrer ces artefacts. Sur la plupart des clouds, le fournisseur figure sur cette liste, ce qui bloque l’adoption de workloads AI. CoreWeave répond à ce problème de détention de clés en proposant un chiffrement où la clé ne quitte jamais le périmètre du client.

Le service s’appuie sur les systèmes déjà déployés par le client : gestionnaires de secrets, KMS, HSM ou tout produit compatible KMIP. Aucun secret n’est importé dans un magasin CoreWeave, ce qui réduit la surface d’exposition et simplifie la conformité aux exigences de traçabilité.

Architecture du Remote Key Encryption

Le chiffrement s’effectue côté client, à l’intérieur de la frontière de calcul du client. Les algorithmes utilisés sont des standards (AES‑256‑GCM, RSA‑2048, etc.), ce qui évite la nécessité d’un nouveau modèle de sécurité. La clé est générée par le gestionnaire du client, puis stockée dans le même coffre que les autres secrets. CoreWeave ne conserve que le texte chiffré.

Les nœuds de calcul restent protégés par le Support Access Management de CoreWeave. Les ingénieurs de support ne peuvent accéder aux nœuds qu’après une autorisation explicite du client, ce qui empêche tout accès non autorisé même en cas de compromission interne.

La rotation, l’expiration et la révocation des clés sont pilotées par les outils du client (HashiCorp Vault, Vault Enterprise ou tout autre KMS KMIP). CoreWeave ne crée pas de processus parallèles, ce qui évite la duplication de politiques et les risques de désynchronisation.

Intégration avec l’écosystème CoreWeave

Remote Key Encryption s’insère dans le même cadre d’identité que CoreWeave IAM. Ce dernier fédère les identités avec Microsoft Entra, Okta et d’autres fournisseurs d’identité d’entreprise, conservant le fournisseur du client comme source de vérité. L’automatisation du provisioning synchronise utilisateurs et groupes entre IAM, le service Kubernetes et le stockage d’objets AI en temps réel.

Pour les clusters d’entraînement, CoreWeave propose SUNK, un package Slurm pour Kubernetes. SUNK crée les comptes POSIX, synchronise les clés SSH et associe les comptes Slurm dès qu’un utilisateur apparaît dans IAM. Cette approche réduit le délai d’accès à moins d’une minute, tout en conservant la traçabilité des identités.

Implications de sécurité et limites

Le principal avantage réside dans la séparation stricte des clés et du chiffrement. En ne conservant que du ciphertext, CoreWeave élimine le risque de fuite de clés depuis son infrastructure. Cependant, la sécurité dépend entièrement de la robustesse du KMS du client : une mauvaise configuration du HSM ou du Vault peut compromettre l’ensemble du système.

Le service est en disponibilité limitée pour le reste de l’année, avec IBM comme partenaire de lancement. La prise en charge de tout KMS compatible KMIP assure une large interopérabilité, mais les clients utilisant des solutions propriétaires devront recourir à des adaptateurs ou à des développements supplémentaires.

En résumé, Remote Key Encryption propose une implémentation pragmatique du chiffrement client‑side, compatible avec les pratiques existantes de gestion de clés, tout en imposant une dépendance forte à la chaîne de confiance du client.