La sécurisation des comptes à privilèges avec des clés de sécurité FIDO2 est la meilleure façon de les protéger contre les menaces internes et externes car
La gestion des secrets fait partie intégrante de la sécurité de stockage. Le code d’application dépend fréquemment des secrets d’infrastructure, tels que les clés d’API, les mots de passe et les jetons d’accès. Trop souvent, les développeurs et le personnel DevOps codent en dur ces secrets dans des images de stockage ou les injectent en tant que variables d’environnement. Ces deux méthodes font que les secrets sont vulnérables aux failles. En outre, le codage en dur couple le processus de gestion des secrets avec le processus de développement, ce qui signifie que la modification ou la rotation d’un secret nécessite de refactoriser et de redéployer le code.
Bien que la CLI de Docker inclue des commandes de gestion secrète, elles fonctionnent uniquement avec les clusters Swarm et non avec les modules autonomes. Pour surmonter cette restriction, les utilisateurs peuvent définir des secrets dans un fichier Docker Compose via le champ Secrets de premier niveau. Cependant, cela nécessite que les administrateurs stockent des secrets dans des fichiers de type «texte ordinaire», qui sont montés sur leurs supports et lus par les applications. Si ces fichiers sont engagés dans la gestion des sources, toute personne ayant accès au référentiel peut y accéder.
En plus d’être non sécurisé, le stockage des secrets Docker dans les fichiers texte participe à l’étalement des secrets, un scénario où les secrets d’infrastructure sont stockés sur l’ensemble du réseau, sans ordre spécifique. Cela peut ne pas sembler être une grosse affaire lorsqu’une organisation a un nombre relativement faible de secrets, mais à mesure que les entreprises se développent, les secrets d’infrastructure se multiplient de manière exponentielle. Par exemple, les clés SSH peuvent facilement se chiffrer en milliers.
Sécurisez les secrets Docker sans difficulté – ou étalement
Keeper Secrets Manager (KSM), la première et seule solution Zero-Trust et Zero-Knowledge basée sur le cloud pour sécuriser les secrets d’infrastructure, permet aux développeurs et au personnel DevOps de sécuriser facilement les secrets de Docker, ainsi que tous les autres secrets d’infrastructure, améliorant la sécurité du stockage tout en éliminant l’étalement des secrets sur l’ensemble de l’environnement de données.
KSM offre aux développeurs et aux équipes DevOps trois méthodes principales pour sécuriser les secrets de Docker.
1. Créez une image avec des secrets en utilisant BuildKit
Avec Docker BuildKit, les secrets du Keeper Vault peuvent être intégrés à un coffre Docker. À partir de Docker 18.09 ou d’une version ultérieure, la création d’images prend en charge la possibilité de passer des secrets via un système de fichiers montés. Pensez à cette méthode comme à la cuisson d’un gâteau, un gâteau avec vos secrets en toute sécurité à l’intérieur. Pour plus de détails et un exemple utile, consultez notre documentation, où nous démontrons cette méthode en créant un compte d’utilisateur dans l’image de destination avec un nom d’utilisateur et un mot de passe de Keeper Secrets Manager.
2. Créez une image avec des secrets en utilisant des arguments de création
En s’appuyant sur l’analogie du gâteau dans la méthode 1, cette méthode ressemble à la préparation d’un gâteau dynamique; elle peut «téléphoner à la maison» au coffre et récupérer en toute sécurité les secrets dont vous avez besoin au moment de l’exécution.
Avec cette méthode, les secrets sont acheminés via le module –build-arg. Il suffit de définir des variables environnementales avec la notation Keeper pour les secrets qui sont nécessaires, et d’utiliser la commande ksm exec pour créer la compilation Docker avec les secrets nécessaires. Consultez notre documentation pour plus de détails et un autre exemple utile.
3. Utilisez l’image du KSM Docker Writer
Le KSM Docker Writer, une image Docker à usage général, simplifie la sécurité des secrets de Docker en téléchargeant automatiquement les fichiers secrets et en générant un fichier qui comporte des secrets. L’image KSM Docker Writer peut être retirée simplement en exécutant la commande CLI suivante:
$ docker pull keeper/keeper-secrets-manager-writer
Lors de l’exécution, ses paramètres sont acheminés via des variables d’environnement.
$ docker run \
-v $PWD:/wd –workdir /wd \
-e « KSM_COINIFG=BASE64 CONFIG » \
-e « SECRETS=JfXpSQ2nZG6lkdl1rxB0dg/file/example.crt >
file:example.crt »
keeper/keeper-secrets-manager-writer
En utilisant le KSM Docker Writer, tout le code source dans les images Docker tire des secrets d’un point de terminaison d’API sécurisé – pas un fichier de texte ! Chaque secret est chiffré avec une clé AES 256-bit, qui est chiffré à nouveau par une autre clé d’application AES-256. L’appareil client récupère le texte chiffré du cloud Keeper, et les secrets sont déchiffrés et utilisés localement sur l’appareil (et non sur le serveur de Keeper). En outre, toutes les demandes de serveur sont chiffrées avec une clé de transmission AES-256 en plus de TLS pour prévenir les attaques MITM ou de replay. Cette cryptographie multicouche est gérée de manière transparente via les SDKs côté client de Keeper, qui sont faciles à intégrer dans n’importe quel environnement.
Un exemple solide d’utilisation de l’image de KSM Docker Writer est l’intégration dans des outils d’orchestration tels que Kubernetes et Docker Compose. L’image KSM peut récupérer les secrets nécessaires lors de l’initialisation, puis les partager avec les autres destinataires qui en dépendent. L’exemple fourni avec Docker Compose dans notre documentation utilise un volume partagé pour stocker les secrets.
Utilisez KSM pour sécuriser tous vos secrets d’infrastructure
La valeur d’utilité de KSM ne s’arrête pas à Docker ou à des stockages. KSM protège les secrets utilisés par le code source dans l’ensemble de l’écosystème informatique d’une organisation, ainsi que les serveurs, les pipelines CI / CD et les environnements de développeur. En outre, comme KSM est une extension naturelle du gestionnaire de mot de passe d’entreprise (EPM) de Keeper, il est entièrement intégré au coffre Web de Keeper, à l’application de bureau et à la console d’administration. KSM s’intègre également de manière transparente au module de rapport et d’alertes avancés (ARAM) de Keeper, à BreachWatch, aux Webhooks, à l’intégration SIEM et aux outils de conformité.
L’utilisation de KSM au lieu du codage en dur, des variables d’environnement ou des fichiers élimine l’étalement des secrets, réduit radicalement les risques de compromission involontaire des secrets et stocke les secrets d’infrastructure dans l’EPM Zero-Knowledge de Keeper. Cela donne aux administrateurs et au personnel DevOps les mêmes avantages et la même maîtrise des secrets d’infrastructure que Keeper leur donne pour les mots de passe. Ceux-ci incluent la rotation des secrets simplifiée, le pilotage d’accès basé sur les rôles (RBAC) et l’intégration avec des modules complémentaires tels que BreachWatch, qui analyse le Dark Web pour trouver des identifiants compromis et des alertes pour les administrateurs informatiques le cas échéant.
Keeper Secrets Manager est entièrement géré et utilise une nouvelle architecture de sécurité en attente de brevet. À la différence des solutions de gestion des secrets concurrentes, KSM s’intègre à pratiquement n’importe quel environnement de données, sans qu’aucun matériel supplémentaire ou infrastructure hébergée dans le cloud n’ait été nécessaire, et offre des intégrations prêtes à l’emploi avec une grande variété d’outils DevOps, y compris Github Actions, Kubernetes, Ansible et plus encore.
Pas encore client Keeper ? Inscrivez-vous dès maintenant pour un essai gratuit de 14 jours ! Vous voulez savoir comment Keeper peut aider votre entreprise à empêcher les violations de sécurité ? Contactez notre équipe dès aujourd’hui.