Quand on fait d'une infrastructure à Scott, on se demande toujours quoi faire des données sensibles.
Qu'est-ce qu'on va gérer ces secrets ?
Est-ce qu'on les met dans Git ? Est-ce qu'on les met ailleurs ?
Est-ce qu'on utilise une base de données dédiée, ou d'autres solutions ?
Quels outils on peut utiliser ?
Bienvenue sur Radio DevOps, la balade aux diffusions des compagnons du DevOps.
Si c'est la première fois que tu nous écoutes, abonne-toi pour ne pas rater les futurs épisodes.
C'est parti !
Bienvenue à toi chers compagnons !
Dans ce nouvel épisode de Radio DevOps, ton podcast préféré est animé par les membres de la communauté des compagnons du DevOps.
Dans chaque épisode, nous débattons sur un sujet de fond.
Et aujourd'hui, comme tu l'auras compris, on va parler de la gestion des secrets dans un contexte d'infrastructure à Scott.
Excusez-moi.
Évidemment, si l'épisode te plaît, tu peux venir en discuter avec nous dans la communauté des compagnons du DevOps.
Il suffit de t'inscrire et c'est le premier lien en description.
Et pour parler secrets avec moi, il n'y a pas de secret entre nous.
D'amir, j'ai d'amir.
Ah de belles références.
Ben bonjour, bonsoir à tous.
J'ai aussi Nicolas.
Bonjour.
Et enfin, René.
Ben bonjour, bonsoir à tous.
Et on va parler secrètement.
Alors je vous propose qu'on chuchote un petit peu.
Qu'on fasse un podcast ASMR pour parler de ces petits secrets.
Alors justement, parler de ces petits secrets, pourquoi est-ce qu'on va parler de secrets dans l'infrastructure à Scott ?
De quoi est-ce qu'on parle ?
Et je crois que Nicolas voulait nous faire une petite introduction là-dessus.
Oui, parce que c'est un sujet qui me préoccupe depuis pas mal de temps.
Et j'essaie de trouver des solutions.
Et j'ai pas encore des solutions magiques à tout.
Mais déjà, de manière générale en sécurité, on réfléchit d'abord à quoi, de quelle menace on veut se protéger.
Donc là, on va plutôt parler de quelle partie on va vouloir protéger.
Donc il y a une première partie qu'on va vouloir protéger, c'est le code source.
Parce qu'il y a des petits malins qui trouvent que Guide, c'est super pratique pour sauvegarder des trucs.
Et comme on a un repository de dit-of public, on pousse les secrets en même temps.
C'est facile, on fait dit-à-dit, commit-dit, push et pouf.
Et comme l'Innustor va de la dit, si vous n'avez pas de solution de sauvegarde à un coût raisonnable,
publiez-le sur Internet, il y a des gens qui vont tout sauvegarder votre place.
Donc c'est un des risques qui est quand même les plus critiques, c'est que votre code source inclut des secrets.
Donc c'est un truc à proscrire totalement.
Donc on parlera tout à l'heure de différentes solutions pour s'en protéger.
Et comment on peut avoir du code source qui utilise des secrets.
On a l'infrascode qui doit pouvoir utiliser des secrets et comment est-ce qu'on peut lui fournir ses secrets.
Tout en protégeant l'infrastructure.
Parce qu'il faut que le secret soit utilisé au bon moment.
Et que l'on puisse le stocker de manière sécurisée.
Et ensuite, le dernier risque, c'est la machine en elle-même.
Puisque de plus en plus avec le cloud, on utilise l'ordinateur d'un autre.
Et mon ordinateur d'aujourd'hui, ça sera peut-être l'ordinateur de quelqu'un d'autre, mais d'un autre utilisateur demain.
Et s'il est mal intentionné, il va essayer de récupérer les secrets.
Ou alors on va se faire piquer une machine d'une manière ou d'une autre.
Et si le secret est en clair sur la machine, c'est un problème.
Donc il faut pouvoir se protéger de ça aussi.
Et je pense que René, tu veux nous parler d'un autre risque aussi.
Pardon.
Oui, c'était une petite aparté.
Je ne pourrais rien cacher aux auditeurs.
J'ai un peu embêté les gens avec ça.
C'est quelque chose qu'il faut prendre aussi en considération.
Les outils que tout le monde m'a présenté peuvent aussi servir beaucoup à partager des secrets de manière sûre.
Et voilà, souvent c'est aussi...
Enfin, on parlait un peu plus loin des bonnes pratiques.
Mais voilà, il y a parfois quand on n'y dispose pas de d'outils ou de ce type-là,
on peut vite déraper, faire des très mauvaises pratiques
et coller les secrets sur des post-it.
Ou se les changer avec des manières peu sûres, des manies en clair, des choses comme ça.
Ou même qu'on est de l'autre côté de la planète, c'est comment on s'envoie le secret.
Parce que les SMS, c'est quand même pas terrible.
Moir.
Et finalement, je t'ai laissé embêter tout le monde.
Mais j'ai exactement le même problème.
Et on va parler des différentes solutions que j'ai utilisées par le passé
et comment on peut même les détourner de leurs buts initiales.
Donc maintenant qu'on a identifié toutes les parties du code et de l'infrastructure qu'on veut protéger,
on va regarder quelques pistes.
Donc une première piste qui est facile à mettre en œuvre, c'est de mettre des secrets dans des variables.
Donc là, ça va protéger le code, parce que la variable d'environnement
n'est pas committée avec le code.
Ça va probablement protéger la machine en elle-même,
puisqu'on peut très bien mettre les secrets dans un fichier
qui est dans un volume temporaire.
C'est notamment comme ça que fonctionne Docker avec sa partie secret.
Et le gros intérêt, c'est que cette partie secret est totalement volatile
si la machine reboute, les secrets ont disparu.
Quand on va vouloir stocker des secrets sur du disque,
bien entendu on va les chiffrer,
avec du chiffrement symétrique ou asymétrique peu importe,
mais il faut que l'attaquant qui va récupérer les données
ne puisse pas les récupérer en clair.
Et après, il y a une autre solution que j'aime bien.
Ça peut être utilisé avec les deux solutions précédentes,
mais c'est des crédents de choses dynamiques.
Par exemple, quand vous avez un accès à une base de données,
un accès à un serveur, traditionnellement,
on récupère un login mot de passe
pour se connecter à la base de données, au serveur, etc.
Il y a une autre solution, c'est d'avoir des crédents de choses dynamiques.
Au lieu d'avoir un login qui va perdurer jusqu'à ce qu'il soit supprimé,
on va vous créer un accès sur la bonne ressource.
Et cet accès-là, il va être disponible
qu'une période de temps, par exemple.
Par exemple, je vais demander un accès à une base de données posérée.
Je sais que cet accès-là va être disponible pendant 4 heures, 4 jours, peu importe,
mais à la fin de cette période-là,
soit on va lui dire, prolonge-moi la durée de ce crédent de choses-là,
ou alors tout simplement, il va expirer.
Et comme on a des cycles de vie de plus en plus rapides,
on redémarre un nouveau conteneur avec un nouvel accès,
et du coup, on redémarre sur des bassins.
Le gros intérêt de ce sécrétement de choses dynamiques,
c'est que si jamais un compte est compromis,
dans quelques jours, il sera inutilisable,
donc ça complexifie la tâche des attaquants.
Et une question qui reste, c'est, mais qu'est-ce que c'est qui en se crée ?
Oui, c'est la question que je me suis posée.
Qu'est-ce qu'on entend par secret pour notre auditeur ?
Parce que finalement, nous, on sait ce que c'est qu'un secret,
mais qu'est-ce que c'est ? Comment est-ce qu'on définit un secret ?
A titre personnel, j'ai tendance à considérer que les mots de passe d'accès
au service ou à base de données, donc les tokens, c'est des secrets.
Parfois même, je considère que les noms d'utilisateurs sont des secrets.
En gros, pour moi, tout ce qui est une donnée que j'ai pas envie de faire échapper,
de se voir échapper, pour moi, c'est un secret.
Ça peut même être des URL d'API particulières,
typiquement, si je prends l'exemple d'OpenStack,
OpenStack, on a une URL particulière pour l'API qui nous est propre,
et bien je peux considérer que ça, c'est un secret par exemple.
Est-ce que vous avez une autre définition de ce que peut être un secret, justement ?
Moi, je dirais simplement toute information sensible qui en étant partagée
pour engendrer des problématiques de sécurité.
C'est assez large, j'achève vague, mais c'est dur de définir précisément.
Je pense que ça peut être intéressant de donner pour nos auditeurs quelque type.
Donc, il y a bien évidemment les mots de passe.
Ça peut pas être con, mais on les oublie, les certificats, qui sont aussi des secrets.
Il y a les certificats, les clés privés, bien sûr, votre clé SSH,
votre clé PGP, etc. sont des secrets.
Si vous envoyez d'autres qui paraissent évident, là, j'en ai pas sous la main.
À au-delà des mots de passe, il y a aussi les tokens qui eux, sont encore plus fragiles,
parce que c'est juste une seule chaîne de caractères.
Mais quand on protège un mot de passe, pensez à protéger l'utilisateur en même temps,
parce que l'utilisateur, ça va être le premier élément qui va servir à l'attaque.
Si on a l'utilisateur, on sait qu'on peut faire du bruit de force sur l'utilisateur,
donc effectivement, on n'a pas le mot de passe.
Mais si on a déjà l'utilisateur, c'est une première simplification.
Oui, alors une fois qu'on a défini nos secrets, qu'on sait de quoi on veut se protéger,
finalement, la deuxième question, c'est comment est-ce qu'on va garder
ou comment est-ce qu'on va partager nos secrets avec les membres de notre équipe.
Du coup, là, on parle d'avant la mise à disposition des secrets dans l'infrastructure AsCode.
C'est vraiment la collègue des infos et puis le fait de garder nos infos.
Comment est-ce que ça va se passer ? Est-ce qu'on a des bonnes pratiques et des outils ?
Je sais, René, vous voulez nous parler justement de l'échange de secrets et genre de choses.
Oui, oui, oui.
Il y a différentes techniques, plus ou moins avancées, suivant les tailles des équipes.
Donc, si on est le seul administrateur,
un exemple d'outil qui peut être utilisé, c'est Kipas,
ou Kipas XC, donc des coffres forts entre guillemets personnels
où on peut stocker nos secrets et qui sont bien plus efficaces
que de stocker ça dans une feuille Excel.
Après, on peut éventuellement partager la base avec certains collègues.
Voilà, c'est possible aussi.
Ça reste une solution facile pour des petites équipes.
Après, ça devient plus compliqué.
Dans certains environnements, pour s'envoyer, par exemple,
des mots de passe, on peut utiliser du chiffrement avec des outils comme GPG.
Donc voilà, ça, c'est un peu historique.
Éventuellement, on peut utiliser des mails chiffrés.
Qu'est-ce qu'on a d'autres ?
Et puis après, on a des outils plus évolués,
mais peut-être que Christophe, je vais te laisser en parler
de ces outils un peu plus évolués.
Oui, parce que justement, tu citais qu'il passe,
nous, on utilisait Kipas XC chez Lydra avant.
Maintenant, on est passé chez Bitwarden,
donc il y a une solution en ligne, du coup.
Nous, on utilisait Kipas XC, ça chronisait avec notre next cloud.
Donc, c'était déjà bien sécurisé, mais c'était pas super ergonomique,
de manière ergonomique.
Nous, on utilise Bitwarden, on a essayé aussi Passbolt,
qui sont deux outils similaires.
On a une préférence pour Bitwarden,
qui permet justement de gérer les accès au secret aussi.
Puisqu'on stocke des mots de passe,
mais pas que.
Dans Bitwarden, on peut stocker plein d'autres choses,
y compris des cartes bleues, par exemple.
C'est intéressant dans le cadre d'un business.
Mais on peut gérer plein de chaînes de caractères,
des fichiers, etc.
Donc, ça, c'est plutôt pas mal.
Et Nicolas, je crois que tu as essayé un autre outil,
dont tu voudrais nous parler pour stocker des mots de passe
et des secrets.

Moi, je l'utilise depuis très, très longtemps.
Ça doit faire au moins une dizaine d'années.
Il n'y a pas du tout Open Source,
il est très propriétaire, c'est One Password.
Donc, le gros intérêt de One Password,
c'est qu'il peut se synchroniser de plein de manières différentes.
On a des clients qui sont disponibles
sur pas mal de systèmes d'exploitation.
Moi, je suis sur Mac.
J'ai déjà utilisé le client Linux,
le client Windows.
Pardon, le client Linux,
il y en a une version qui est intégrée dans le navigateur web.
Et depuis à peu près 5 ans, peut-être un peu plus,
ils ont une version en Cli.
Donc, c'est super pratique, parce qu'on peut aller chercher
dans les secrets avec de la Cli
et avoir des usages un petit peu détournés,
dont on parlera tout à l'heure.
Et tout récemment, l'année dernière,
ils ont rajouté une fonctionnalité
qui demande point de vue manquée cruellement.
C'était du partage de mot de passe.
Donc, avant, il fallait avoir un coffre fort
qui était partagé avec d'autres personnes.
En plus, c'était un compte payant plus cher, etc.
Et en fait, l'application est tellement bien
que j'ai pris la version familiale
et j'ai passé tous mes enfants dessus.
Donc, mes enfants ont des One Password.
Je pense que ça doit être les seuls
dans leur collège d'ICI respectifs.
Mais bon.
Mais pour tous ceux qui n'ont pas de One Password,
il y a une fonctionnalité de partage.
Donc, ça crée une URL.
On peut lui donner une temporalité.
On peut lui dire, c'est en accès, en lecture,
écriture, machin, etc.
On donne URL et la personne avec URL
peut avoir accès aux secrets.
Donc, si on veut partager un compte,
un truc qu'il ne faut pas faire comme Netflix,
c'est qu'on peut partager temporairement le compte
avec quelqu'un d'autre.
Et je crois même qu'il y a une fonctionnalité
où, au moment où on clique,
ça révoque automatiquement le lien.
Donc, la personne qui a lu le secret
le verra directement.
Donc, après, au-delà de ça, il y a plein d'autres fonctionnalités
comme ça va aller regarder dans une base de données
en ligne sur les mots de passe qui ont liqué
pour la petite histoire, c'est la société
qui a créé cette base de données.
C'est l'éditeur de OnePassword,
qui maintenant est utilisé par plein d'autres
gestionnaires de mots de passe
pour savoir si votre mot de passe est habité.
Et il va vous faire des audits régulièrement
du style celui-là de mots de passe
qui est trop faible,
celui-là, vous l'avez réutilisé tant de fois et ainsi de suite.
Donc, c'est vraiment pour inciter les utilisateurs
à avoir des mots de passe différents
sur toutes les applications.
Ce que ça, on n'en a pas parlé, mais c'est une des bonnes pratiques
de ne pas réutiliser deux fois le même mot de passe.
C'est même la bonne pratique.
Pourquoi ? Pour comprendre.
Parce que c'est vrai qu'on n'a pas incité à ça.
Mais, si vous mettez votre mot de passe un peu identique partout,
appartement, vous êtes fait...
Mais, Jean, il y a une fuite de données chez un de vos fournisseurs
qui est stockée, bien sûr, tout ça en clair,
parce que ce n'est pas marrant.
Potentiellement, la personne, elle a votre mail, elle a votre mot de passe.
Donc, elle a possensé-moi que ça a tout vos comptes.
Et à partir du moment où elle a accès à plusieurs de vos comptes,
ça peut être très vite être empirique et devenir très problématique.
Donc, c'est pour ça qu'il vaut mieux éviter ça.
Si vous êtes maso comme moi, vous changez de mail à chaque fois aussi.
Oui.
Je pense qu'il faut bien montrer aussi avec ces outils-là,
donc Bitwarden, Passball, OnePassort,
c'est qu'il n'y a plus la nécessité d'avoir un secret partagé
entre les membres de l'équipe, chacun à son compte,
son propre mot de passe.
Et on sait qui a accès à tel secret.
Et si demain, on veut que cette personne n'ait plus accès au secret,
parce qu'elle s'en va de là, société ou etc.,
on peut donc arrêter ce partage de secret.
Bon, bien sûr, il faut renouveler le secret,
sinon la personne, si elle l'a enregistrée, elle le connait.
Oui.
Alors, juste, on peut parler des bonnes pratiques aussi,
d'échange de mot de passe,
parce que je crois qu'on est tous ici, on a vu ce genre de choses.
Mot de passe est changé par mail, non chiffré, non signé.
Mot de passe est changé sur Slack.
Mot de passe est changé, le pire que j'ai vu, c'est mot de passe.
Excusez-moi.
L'intégralité des secrets, des accès et des tokens partagés
dans une feuille XSATIMS, pas TIMS, comment ça s'appelle ?
SharePoint.
SharePoint, voilà. Exactement, merci.
Peut-être qu'on fait référence aux mêmes clients.
Je pense pas, mais c'est mon...
Ce genre de choses, ne le faites pas par pitié, ne le faites pas.
Prenez un compte au pire, achetez un compte chez Bitwarden,
parce que en plus, je dis Bitwarden, parce qu'en plus,
ça le salle le salle libre, mais c'est Berger en Europe,
mais surtout, c'est chiffré au niveau du navigateur,
ce qui fait que même les Berger n'a pas votre mot de passe,
c'est impossible, c'est votre navigateur qui va déchiffrer le truc.
Donc, partagez vos mots de passe avec un gestion de mot de passe.
Enfin, au tout cas, moi, c'est ma préférence.
Ne le faites pas.
C'est vrai qu'on a parlé de gestionnaire de mot de passe
en partant du principe que tout le monde savait à peu près ce que c'était.
Le gestionnaire de mot de passe va effectivement chiffrer
tous vos mots de passe avec une clé unique.
Donc, c'est cette passe phrase qui va vous permettre
de déchiffrer votre coffre fort,
et après, vous vous aurez accès à tous les secrets
qui sont stockés dedans.
Après, certains sont plus ou moins évolués.
Je ne peux pas m'avancer sur Bitwarden et PassBolt,
mais qui passe la passe phrase,
c'est la passe phrase qui permet de déchiffrer la clé
qui a permis à chiffrer tous les secrets.
Et OnePassword, il y a plusieurs niveaux de secrets.
Donc, il y a un premier token à avoir.
Si vous ne l'avez pas, vous ne pouvez pas y avoir accès.
Et il faut aussi la passe phrase qui vous sert à déverrouiller
le coffre fort à chaque fois.
Et vous pouvez rajouter d'autres facteurs.
Moi, j'ai rajouté MyUbiti sur tous mes coffres OnePassword.
Ce qui fait que maintenant, en plus,
il faut la clé physique pour pouvoir déchiffrer tout ça.
La promesse d'un gestionnaire de mot de passe,
c'est justement qu'on faisait qu'il faut avoir un mot de passe
qui est fort et différent sur chaque site.
On se doute bien que très vite humainement,
c'est plus possible de tous les retenir.
Donc là, l'idée, c'est vous retenez une master key,
et d'ailleurs, vous avez pu à vous préoccuper de rien.
Il va compléter automatiquement sur votre navigateur,
souvent avec des extensions et des informations de connexion.
Donc ça fonctionne très bien.
D'ailleurs, j'ai une petite question.
Ce que tu parles de double authentification,
c'est vrai qu'il faut l'activer sur vos comptes.
C'est quand même un gros, gros step up au niveau sécurité.
On ne va pas se mentir.
Et j'ai une petite question,
parce que moi, je suis un peu opposé à la pratique.
Je fais partie des personnes qui veulent pas mettre
mes tokens de double authentification dans mon gestionnaire de mot de passe,
sauf des comptes ultra génériques
ou des comptes d'administration de sites spécifiques
qui ne sont pas rattachés à une personne physique.
Mais vous vous en pensez quoi ?
Est-ce que vous stockez vos tokens MFA
dans le même secret qui stockent votre mot de passe ?
Alors tu parles des tokens de recouvrement ?
Ouais, ou même du token de base.
En fait, avec un token, tu peux générer tes tokens temporaires.
Et en fait, il y a beaucoup de gens qui les stockent
dans leur gestionnaire de mot de passe.
À part pour les comptes génériques qui ne sont pas rattachés à une personne,
je trouve ça un peu...
ça me perturbe, je veux dire que le deuxième facteur d'authentification,
il est accessible au même endroit que le premier.
Alors moi, pour être honnête, je les stocke dans mon exploit,
dans mon espace privé et parfois je le chiffre.
Même à double authentification, c'est mon smartphone.
Donc du coup, j'ai une application dessus qui me génère mes doubles authentifications,
mais c'est pour ça que je parlais des records de recouvrement.
Ouais, les records de recouvrement.
Bon, on a un peu parlé des gestions de mot de passe,
mais parce que les gestions de mot de passe permettent de gérer des mots de passe,
des néons d'utilisateur, des fichiers, enfin un peu tout.
Donc ça permet facilement de mettre tout un tas de types de secrets.
Mais en fait, on est là pour parler d'un phrase code.
Et quand on fait de l'un phrase code,
moi je suis très Githops, vous le savez,
j'ai fait un épisode de podcast justement là-dessus sur le Githops.
Et la première chose qu'on peut faire, et tout-fois, c'est le plus facile,
c'est mettre ses secrets dans Gith.
Tout à l'heure, on parlait de pas mettre ses secrets dans Gith,
mais mettre ses secrets dans Gith, c'est une possibilité.
Mais par contre, il faut pas les mettre en clair, il faut les chiffrer.
Donc on a plein de choses pour les chiffrer.
Mais Damir va nous dire justement,
comment est-ce qu'on peut ne pas les mettre en clair dans Gith ?
Ouais, alors on a tous connu, on a peut-être fait,
ça peut arriver, on a peut-être connu quelqu'un qui l'a fait en tout cas,
a eu un moment où un secret, un token, souvent un token,
ça c'est le classique, le petit token pour se connecter,
qui a été committé, qui a été post-shoulderipo,
c'est quelque chose qui est problématique,
donc bien sûr, généralement si on arrive à répondre assez vite,
on va pouvoir le supprimer et le renouveler,
pas obéder de le renouveler quand un token ne fuite, bien sûr.
Mais on aimerait bien éviter que ça arrive avant.
Donc pour ça, il y a un petit outil qui se base sur les hook-githes,
j'en ai déjà parlé pas mal de fois,
parce que je t'ai découvert il y a quelques années maintenant,
et c'est quand même quelque chose qui change la vie,
qui permet d'automater des actions,
et il y a un outil qui permet particulièrement de le faire
avant de committer une action,
c'est l'appel pré-commit.
Et avec ce système, vous allez pouvoir mettre des vérifications
pour vérifier que lorsque vous allez faire un commit,
il va checker s'il ne voit pas de secret en clair.
Alors ça marche pas à 100%,
vous allez possiblement trouver des use-cases,
vous pouvez committer un secret,
mais il va permettre de vous éviter certaines erreurs
et de committer certaines choses,
donc ça peut vous sauver la vie, entre guillemets.
Donc je conseille vraiment de le faire,
ça ne coûte pas grand-chose,
ça vous permet d'automater d'autres choses en même temps,
il n'y a pas que les secrets.
Donc là-dessus, vraiment, c'est à faire.
Je confirme, les hook-githes de pré-commit,
c'est indispensable, on l'a mis en place,
c'est vraiment bien.
Du coup, ça permet de tester des secrets s'ils sont en clair,
il faut avoir des patterns évidemment,
ou alors de tester, nous c'est ce qu'on fait,
c'est qu'on met tous nos secrets dans des fichiers
qui s'appellent point-volt, point-quelque chose,
et si ces fichiers-là ne sont pas chiffrés,
on arrête, par exemple, le hook de pré-commit.
Et donc il y a quelques outils qui permettent de chiffrer nos secrets
dans guite, je vous en avais parlé justement
dans la travail du vendredi du 13 août 2021.
Donc il y a le premier qui est pour l'instant celui que j'utilise le plus,
qui est en cible volt, qui est assez facile,
il y a deux commandes,
une commande pour chiffrer, une commande pour déchiffrer,
ça se base sur un mot de passe,
qui peut être dans un fichier,
ou alors qu'on peut renseigner au moment de faire la commande.
Et je pense qu'on va petit à petit migrer
vers le deuxième dont je vais parler,
parce qu'en cible volt c'est bien, mais ça c'est limite,
notamment ça chiffre l'intégralité du fichier.
Ce qui fait qu'en vous avez des fichiers versionnés dans guite,
et ben vous voyez pas trop les différences en fait.
Donc si vous avez plusieurs variables,
par exemple nous on l'utilise dans le cadre d'en cible,
si on a plusieurs variables dans un fichier,
on voit pas laquelle a été modifiée en fait.
Il y a tout le fichier qui a été modifié.
Et du coup,
tu peux chiffrer entrez par entrez,
mais c'est vraiment pénible.
Ah bah écoute, je savais pas.
Je vais parler justement de Mozilla Soaps,
qui est certainement la solution qu'on va utiliser,
qui permet de chiffrer le contenu des variables,
puisque apparemment c'est fait pour ça.
C'est un autre outil qui permet justement
de chiffrer des parties de fichier,
et je pense que c'est plus facile qu'en cible volt.
En l'occurrence, et enfin il y a Git Crypt,
que pour le coup j'ai pas utilisé,
mais qui a l'air d'être assez utilisé par la communauté,
pour chiffrer aussi des données.
René, on a ajouté un je crois dessus.
Je crois que c'est toi.
Oui, oui. Alors c'est...
c'est une alternative à Git Crypt.
Alors Git Crypt pour...
si je me souviens bien c'est un binaire.
Et en fait on a Git Secret,
qui lui c'est plutôt un...
s'appuie sur GNU PG,
et du script Bache,
pour faire à peu près l'équivalent.
Et l'avantage en fait c'est qu'une fois qu'on a chiffré nos secrets,
eh ben on peut les mettre et on peut les versionner dans Git.
Et du coup, le code d'infrastructure
y contient aussi les secrets d'infrastructure.
Et comme ça quand on déploie l'infrastructure,
les secrets y suivent.
Il n'y a pas besoin d'aller les chercher ailleurs.
Pour des petites équipes et des petits projets,
je trouve que c'est un très bon compromis.
Je pense que...
je ne sais pas si vous êtes d'accord avec moi.
Disons que c'est mieux que le fichier Word
ouvert dans une machine à distance en RDP.
Donc oui, c'est sûr que c'est un premier niveau.
Après je pense qu'il y a plusieurs niveaux de maturité
et clairement c'est...
je pense le premier vrai niveau,
où on commence à avoir quelque chose de solide, moi.
De plutôt solide en termes de sécurité par rapport à taille de équipe.
Oui je pense que c'est vraiment ça le différent, c'est ça.
Le plus important c'est que cette pratique là,
elle n'est-ce qu'elle pas trop...
voilà, sur les grosses équipes forcément c'est compliqué.
Oui on est assez d'accord pour les grosses équipes,
ça devient vite limité.
Par contre pour déchiffrer ces secrets,
parce que souvent quand on est dans une optique githops,
c'est la CIA qui va aller soit faire du poule
et donc générer notre infrastructure.
Il faut quand même que la CIA puisse déchiffrer ces secrets.
Et souvent il y a un secret pour déchiffrer les secrets.
Et du coup ce secret là,
c'est Masterki, ce secret principal,
il faut la mettre quelque part et le quelque part en l'occurrence
c'est souvent les variables de la CIA.
Et donc là il faut faire confiance à soit son hébergeur de CIA,
soit il faut héberger soit même sa propre solution.
Il faut avoir confiance aussi dans ton équipe,
parce que potentiellement si une personne a le droit de modifier son job CIA,
c'est un GitLab par exemple, si ils touchent le GitLab CIA,
ils pourraient faire juste un écho de la variable avec un Masterki,
récupérer tous les passeports non ?
Normalement c'est bien foutu parce qu'il va systématiquement remplacer
tes secrets par des étoiles.
Ça c'est beau quand même.
Oui, GitLab, il y a une notion de secret.
En plus GitLab a plusieurs gestions,
donc du coup tu peux accéder ou pas au variable de la CIA
en fonction de ton niveau.
Tu peux afficher ou pas le contenu de ton secret,
parce qu'une variable ne peut pas être un secret,
mais surtout tu peux rendre la variable présente ou pas dans certaines branches.
Ok.
Du coup de façon on tendra besoin de toutes les branches potentiellement,
vu que c'est un Masterki, tu as tous les secrets dedans.
Ça dépend, tu peux avoir des clés par environnement par exemple.
Tu peux aller jusqu'à ce niveau là.
Tu peux avoir un GitCrypt avec plusieurs niveaux de Masterki dessus ?
Si par exemple tu te dis en CibleVolt,
en CibleVolt ils se basent sur un fichier.
Non mais là je parlais plus de GitCrypt et de GitSecret,
en CibleVolt je sais qu'il y a moyen, mais c'était plus pour les autres solutions.
Alors je vais pas parler pour GitCrypt mais je pense que c'est la même chose,
mais sur GitSecret c'est du chiffrage assez maitrique,
donc il n'y a pas un secret partagé.
Du coup tu définis qui va pouvoir déchiffrer.
Ah oui tu as dit que c'était sur pgp, excuse-moi.
Donc maintenant qu'on a parlé des petites solutions pour petites équipes,
on va rentrer dans le dur du dur et les gros trucs que je connais pas,
donc c'est vous qui allez m'aider.
On va parler des coffres forts,
j'ai appelé ça coffre fort mais parce que c'est le terme anglais.
Et on va commencer par les bonnes pratiques liées aux coffres forts,
qui veut commencer à nous brifier un tout petit peu sur ces fameux coffres forts
et après vraiment nous donner ces bonnes pratiques.
Moi je peux en parler,
mais vous allez me voir bouger un petit peu
parce que j'ai les batteries de mon casque qui sont en train de me lâcher.
Donc dans les coffres forts,
on va avoir différentes solutions.
Celles qui fait un petit peu référence et que je connais mieux c'est Volt,
donc la solution d'Achicor.
C'est un produit qui a été designé pour gérer tout ce qui est secret.
Donc ça permet de gérer pas mal de choses.
Damir parlait par exemple de certifia, notamment TLS.
Volt permet de gérer la partie privée et publique de les générer pour nous et ainsi de suite.
Ça permet aussi de générer tous les secrets.
Tout à l'heure je parlais de secrets dynamiques,
typiquement en tibol Volt et vraiment bien foutu pour ça.
Et il a été prévu pour fournir de l'infrastructure.
Mais en préambule, je pense qu'on pourrait parler de bonnes pratiques
parce que toutes les solutions dont on va parler un petit peu plus tard
utilisent à peu près toutes ces pratiques-là.
Et je suis en train de chercher...
Pendant que tu cherches les bonnes pratiques,
ce que je voulais dire c'est qu'un coffre-force est un endroit
où on va mettre la tégraïété de nos secrets et qui va pouvoir être accessible
soit par notre CIA, soit par notre infrastructure,
soit par nos services qui sont dans l'infrastructure.
C'est ça que j'entendais dans le coffre-force.
Est-ce que tu es d'accord avec cette définition ?
Oui.
J'espère que tu as retrouvé tes petits.
Oui, c'est bon.
Dans toutes nos bonnes pratiques,
ça va être la rotation automatique des secrets.
J'en ai parlé tout à l'heure.
C'est autant les mots de passe pour une personne physique
changer régulièrement de mots de passe.
Ça commence à être considéré comme une mauvaise pratique.
Parce que pour information,
la personne qui avait créé cette règle de
« Il faut changer son mot de passe régulièrement ».
C'était une personne qui travaillait eniste, je crois.
Il est parti à l'art très récemment.
Il a dit « Non mais en fait, faites pas ça ».
Quand j'ai dit ça, je savais pas de quoi je parlais.
Donc, et en pêcher...
Arrêtez d'obliger vos utilisateurs à changer régulièrement de mots de passe
parce qu'ils finissent par les noter sur des post-it.
Par contre, sur l'infrastructure, nos serveurs, eux, ils n'ont pas de post-it.
Ils ne peuvent pas les noter.
Par contre, il faut bien le noter quelque part.
Tout à l'heure, je disais qu'on allait les stocker quelque part.
Par exemple sur le disque.
Et un fichier qui est stocké sur le disque,
à un moment donné, il va liquer.
Si vous ne voulez pas qu'il se retrouve dans la nature
et qu'on puisse récupérer d'autres informations avec votre mot de passe,
il va falloir mettre en place une rotation automatique de ces credentials.
Je parlais de Vault qui permettait de faire ça automatiquement.
Il va vous créer un credentials à la volée.
Vous allez le fournir à votre application au moment où elle va démarrer.
Et quelques jours plus tard, ce credentials-là va être supprimé.
Donc prévoyez ces trucs-là de générer un nouveau secret régulièrement
et de mettre à jour votre application.
Le gros intérêt de faire ça, ça va être deux choses.
Déjà, le premier, c'est que vous allez avoir régulièrement des secrets qui vont changer.
Donc quand votre secret va liquer, c'est pas grave, il sera déjà périmé.
Et le deuxième intérêt à faire ça très régulièrement,
c'est que ça va vous amener une routine de changement des secrets.
Et plus vous allez changer ça régulièrement, plus vous allez être rompu à
« On a un secret qui est à liquer », c'est pas grave.
On clique sur un bouton, on gêner un secret, on remet à jour l'infrastructure.
Et de mon point de vue, c'est une des premières défenses pour protéger vos données.
Et après, il y a un truc qui est très important à faire.
Et là, je vais laisser Damir en parler.
Après, comme tout, et ça c'est un sujet assez...
On a déjà abordé dans une émission de Radio DevOps,
mais c'est de back-up tout ça, non, de back-up tout ça, on a déjà parlé,
mais pas de back-up tout ça au même endroit.
Comme la data entre guillemets qui va contenir votre base de données chiffrées
entre guillemets va être déchefrée avec un mot de passe,
si vous devez sauvegarder les deux,
sauvegarder pas les deux au même endroit, parce que si la sauvegarde un jour est chopée,
vous allez vous faire avoir.
Et au-delà de ça, on parlait du but et de ce qu'est un coffre fort.
Un coffre fort, globalement, ça va être vraiment quelque chose.
Je vois vraiment comme un service, une brique de service,
qui va vous permettre d'exposer une manière de retrouver vos mots de passe.
Et pour retrouver ces mots de passe, en fait, nous on veut quelques caractéristiques,
notamment on veut que pas tout le monde puisse accéder à tous les mots de passe.
Vous vous doutez bien que si on est une entreprise, on veut que certains mots de passe,
ils soient pas accessibles, on va dire, à n'importe qui.
On veut aussi que, potentiellement, j'ai déjà eu des cas de grosses entreprises,
notamment des banques, où aucun humain n'avait accès en fait,
réellement au mot de passe, la 99% des mots de passe de production
étaient utilisés par des bots uniquement ou des automatismes.
Donc nous-même, on n'y avait pas accès.
Ça évite des fuites, tout simplement.
Une autre chose aussi qui est importante, c'est les logs d'accès.
Parce que, si jamais une fois une personne a accès à un mot de passe,
qu'elle n'aurait pas dû, ou on a une modification de mot de passe suspecte,
c'est important pour un lieu de sécurité de pouvoir tracer ce qui s'est passé
et qui a fait l'action où le mot de passe, à partir du temps, il a fuité.
C'est quelque chose d'en sécurité qui est assez important et assez vital, je dirais même.
Et bien sûr qu'on foie les logs, vous les centralisez.
On en a déjà parlé plusieurs fois, mais la centralisation des logs,
c'est important pour l'aspect de sécurité.
Et bien sûr, il y a aussi un autre technique, et ça, c'est pour moi,
pour moi, c'est important, même ça dépasse peut-être un peu le cadre des coffres forts.
C'est utiliser des systèmes d'authentification forte, que ce soit sur les coffres forts
ou d'autres choses.
Je prends un exemple, je prends exemple d'AWS, que c'est l'exemple que je connais un peu mieux, on va dire.
Sur AWS, si vous devez vous authentifier au vault,
vous avez une application qui tourne, par exemple sur une EC2,
vous devez vous authentifier à un vault pour bootstrap des secrets de votre application.
Le fait pas avec un secret de base ne mettez pas un mot de passe en clair qui va se connecter à votre vault.
Vous pouvez essayer des choses comme les signatures avec les métadata de l'instance,
qui vont pouvoir de se s'authentifier au vault, avec les métadata de l'instance, plus la signature d'AWS.
Ce qui fait que demain, si jamais votre volume à froid est dumpé à l'extérieur ou autre chose,
ils auront pas vos secrets.
Même si ils sont sur AWS, vu que c'est pas signé par AWS, entre guillemets, en cours de run,
ils auront pas accès à ces secrets.
Du coup, ça c'est typiquement un workflow, on va dire, qui fonctionne avec Vault,
HCorp Vault, mais qui fonctionne très bien.
Il y a pas mal d'exemples là-dessus, de systèmes qui vous permettent de faire de l'authentification
plutôt efficace, sans pour autant exposer trop de surface,
on va dire, d'attaque ou de possibilité en fait.
Quand tu parlais de backup et du backup de la clé, ça m'a fait penser à autre chose par rapport à Vault.
C'est que, par défaut, il va chiffrer votre base de données avec une clé privée,
qui elle va être rechiffrée avec un algorithme type asymétrique.
Et en fait, pour déchiffrer cette clé-là, il faut par défaut cinq secrets.
Le principe, c'est que vous allez initialiser votre base de données en disant,
j'ai cinq personnes dans mon équipe et il m'en faut minimum trois,
qui vont rentrer chacun leur morceau de secrets.
C'est un algorithme qui est basé sur Shamir, c'est un de ceux qui a créé RSA.
Et c'est un algorithme de chiffrement, des chiffrements,
qui permet de, donc, pour déchiffrer votre secret sur un nombre de passphrases,
il va vous en falloir un minimum.
C'est un peu compliqué à expliquer, mais en gros, par défaut,
vous avez cinq, dix personnes dans l'équipe,
vous allez chacun leur générer un secret,
et vous allez dire qu'il faut x personnes pour pouvoir déchiffrer les données.
Donc, par exemple, deux personnes doivent rentrer leur secret pour pouvoir déchiffrer la base.
Ça permet un truc qui est super important,
c'est que si jamais la base est arrêtée,
au moment où il faut redémarrer, il faut qu'il y ait deux personnes qui soient disponibles.
Alors ça, c'est la contrainte.
Le gros intérêt, c'est que si jamais une personne mal intentionnée récupère cette base-là,
la méchée, lui et l'art démarrent,
il ne pourra pas la réouvrir pour pouvoir aller faire tout ce qu'il veut dedans.
Donc, ça vous permet de garantir que, si il y a une action malveillante,
bon, il y a deux personnes qui se font complices,
ou trois personnes, mais ce n'est pas une personne isolée dans son coin
qui pourra récupérer l'intégralité de la base de données.
Justement, vous en avez beaucoup parlé.
Alors peut-être qu'on peut parler plus précisément de la solution VOLT,
parce que quand on pense à Coffrefort,
moi, la seule idée que j'ai, c'est à Chicorps VOLT.
Je ne sais pas comment on faisait avant qu'il existe,
mais en tout cas, je le vois un peu de partout dans les grosses infrastructures.
Est-ce que vous confirmez qu'il est surutilisé de partout
dans les vraiment infrastructures assez costaudes ?
Mais c'est devenu un peu un standard, en fait, par défaut, pour le coup à Chicorps VOLT.
Parce que, bon, à pas se cacher,
la Chicorps sont très bien installées sur la StackDevops.
On va pas se le rêler là-dessus.
Donc, c'est plus simple pour eux de pousser un produit de leur écosystème.
Et bien, c'est un produit qui est ultra efficace.
Là aussi, il n'y a rien à redire.
Et qui a beaucoup d'intégration et beaucoup de produits populaires.
Donc là, j'ai parlé à KWS, le workflow, il marche très bien nativement.
Marche aussi très bien avec Duel, du cube classique.
Donc, je pense que ça fait un peu son succès là-dessus.
Est-ce que c'est facile, justement,
est-ce que c'est facile à maintenir à un VOLT, en fait ?
Alors, j'aurais complété un petit peu la réponse de Damir.
Il est aussi parfaitement intégré à Nomad.
C'est une alternative avec Kubernetes.
Et en fait, au moment où Nomad charge son fichier de description,
il va charger à la voler les secrets dans VOLT.
Et après, pour répondre à la question,
est-ce que c'est facile à installer ?
Oui, c'est facile à installer.
Tu suis le tutoriel et pas c'est fait en deux minutes.
Après, est-ce que c'est facile à administrer sur du long terme ?
Oui, c'est facile à installer.





Et en fait, ça dépend du niveau de fonctionnalité
que tu vas vouloir avoir
et des contraintes de sécurité que tu vas te mettre dessus.
Par exemple, je parlais des secrets
qui vont avoir une durée temporelle
et de la complexité de mettre à jour ces secrets
dans l'infrastructure.
Par défaut, toute l'authentification d'un VOLT
se fait avec des tokens.
Il y a différentes formes de tokens.
Il y a des tokens classiques, des tokens applicatifs, etc.
Mais globalement, un token va avoir une validité dans le temps.
Et une fois que le token a expiré, il est devenu inutilisable.
Donc il faut savoir regenerer des tokens
pour pouvoir les repousser dans l'application
et il faut savoir le faire de manière automatique.
Je dirais que c'est peut-être plus cette partie-là
qui est compliquée à gérer dans VOLT.
C'est la gestion de ces secrets.
Et je pense que la plus grosse problématique
c'est que comme c'est un nouveau produit
et une nouvelle manière de faire,
on n'a pas encore tout ce qu'il faut dans notre outillage
pour pouvoir le faire de manière automatique.
C'est quoi ton expérience là-dessus, Odamir ?
Alors moi, c'est vrai que pour l'instant,
j'ai une plus forte expérience de VOLT à l'utilisation
qu'à l'installation en maintenant.
Quand j'ai utilisé VOLT, c'était surtout dans des grosses équipes
où c'était une équipe à part qui gérait ça ou à séparer.
Ce qui fait que j'ai jamais eu vraiment de contrainte
au niveau de la maintenabilité.
Moi, j'ai plus une expérience d'utilisateur de VOLT
au niveau API intégration.
Mais effectivement, après, je pense que le vrai...
je pense que ce que je fais bien de mentionner, c'est comme beaucoup de choses.
Ça dépend beaucoup du niveau d'exigence que tu vas avoir avec toi-même
et à avoir avec la sécurité par rapport à ça.
Oui, donc ce que je voulais dire,
c'est qu'il explique un petit peu la difficulté d'utilisation du produit.
C'est que c'est un produit...
il devait un critique, c'est-à-dire qu'il faut qu'il répond
à partir du moment, mais des secrets pour utilisation dans la CIA.
Il faut que le produit soit toujours disponible,
sinon on n'a plus accès aux secrets et la CIA va tomber
ou d'autres applications vont tomber.
Du coup, c'est un outil dont on peut...
c'est industriel, on peut faire de la achat qui est assez modulaire.
Donc on peut avoir plusieurs instances de VOLT en lui-même
qui va vraiment s'occuper de la partie chiffrement.
Et derrière, après, on peut le coupler avec un backend.
Donc une deuxième bric pour le stockage.
Après cette deuxième bric, ça peut être du console qui est la solution
potentiellement HICORP.
Du coup, on maintient à la fois la brick-volte plus un peu la brick-console.
Ou alors, ça peut être d'autres back-ends, type S3, etc.
La liste est très très longue.
ETCD, dans le cas de par exemple d'un cube,
ça peut être intéressant de stocker aussi des choses dans ETCD.
C'est ce qui explique que ça a un certain coût d'entrée,
parce que ça devient vraiment critique et il faut vraiment assurer
la disponibilité du service.
Et quand tu commences à mettre un truc comme ça en place,
ça devient vraiment critique si il démarre plus,
parce que, en toute logique, il ne peut rien redémarrer derrière.
Pour compléter un petit peu ce que tu disais sur la partie
aux disponibilités et stockage, il y a un nom 2.
Ils ont sorti un backend de RAFT.
Donc RAFT, c'est un protocole de mise en cluster.
Et en fait, VOLT est devenu totalement autonome.
Donc on peut se passer d'un backend tiers.
C'est un tout petit peu plus compliqué,
parce que console, moi je l'ai beaucoup utilisé comme backend
et il est assez simple à mettre en place et à maintenir.
Avec le backend de RAFT, j'ai un petit peu plus de mal à comprendre,
mais par contre, ça reste super intéressant de pouvoir avoir un VOLT totalement autonome.
Parce que VOLT va aussi amener toute la partie sécurité sur console.
Donc si tu stock ton VOLT dans console et que tu te sers de VOLT
pour gérer les accès à ton console, c'est le serpent qui se mord la queue.
Donc le fait d'avoir un VOLT totalement autonome, ça résoud une partie du problème.
Justement, juste pour info, je viens de voir que sur CUBE,
il y a un opérateur VOLT qui permet de gérer jusqu'au cycle de vie de VOLT.
Alors peut-être que ça peut être une piste pour les équipes de taille intermédiaire.
Parce que j'ai vraiment l'impression que c'est un produit super, mais pour les grosses entreprises.
C'est un produit extrêmement... Enfin voilà, c'est un produit industriel.
C'est un produit complet qui répond, je pense, à tous les cas d'usage.
Et du coup, comme il a fait beaucoup de choses, il est un peu compliqué à appréhender.
Moi, j'avais une question sur l'autorification.
Justement, on ne voulait pas l'authentification, vas-y.
Justement, c'est aussi un des points forts de VOLT.
C'est qu'il peut être le point central de la gestion de la sécurité.
Alors sécurité au sens secret et chiffrement.
Parce qu'on a parlé du fait qu'il pouvait stocker des secrets.
On a parlé du fait qu'il pouvait gérer des certificats TLS.
Donc plus clairement, il a une PKI disponible.
Il gère des créations de secrets dynamiques.
Et en fait, tout ça, ça va s'appuyer sur une authentification.
Et en fait, l'authentification, on peut avoir des tokens tout simples pour un utilisateur.
Mais quand on commence à avoir une entreprise plus grande et qu'on veut donner des accès au développeur,
on peut aussi mettre de l'authentification.
Alors je ne sais plus s'il y a du LDAP, mais il me semble que si.
Il y a de l'OpenID connex de mémoire.
Il y a de l'OpenID, il y a du AWS IAM, il y a l'équivalent Google,
il y a l'équivalent Azure, il y a une pléthore d'authentification.
Et pour chaque authentification, on va pouvoir dire qu'il faut qu'il ait tel droit,
il faut qu'il ait tel rôle, il faut qu'il ait tel truc.
Et ce qui fait que pour chaque secret, on va pouvoir dire tel utilisateur,
il a le droit de lire tel utilisateur, il a le droit d'écrire et ainsi de suite.
Donc en plus de l'authentification, il y a aussi des espèces d'ACL qui sont positionnées sur chaque secret.
Et est-ce qu'il existe ? Parce que à part la…
J'imagine que Chikorp fournit une solution d'hébergement,
j'ai vu qu'ils faisaient un Vault Enterprise,
mais est-ce qu'il existe des Vault as a service à votre connaissance ?
Alors, la partie Vault Enterprise, c'est pas une solution sas,
c'est la solution, ils ont une solution Open Source,
qui a des fonctionnalités limitées, et ils ont une version Enterprise
qui va servir quand vous appelez Orange, Saint-François, je sais pas quoi,
mais pas la petite boîte qui est en train de se monter dans le garage.
La licence, je sais même pas combien, c'est à coûte,
mais c'est plusieurs, centaines de milliers d'euros par an,
donc clairement pas accessible pour des petites boîtes.
Par contre, récemment, ils ont commencé à mettre en sas toutes leurs solutions.
Donc ils avaient conçu les nomades, et c'est l'année dernière, ils l'ont sorti pour Vault aussi.
Alors c'est un petit peu particulier, parce qu'en fait,
ils ont pris à peu près de même modèle qu'est la Stick Search,
qui distribue leurs solutions en sas, mais c'est...
En fait, tu vas pouvoir souscrire le service Vault auprès de HitchiCorp,
pour déployer la solution entièrement managée par HitchiCorp,
sur un cluster qui va être entièrement dédié,
mais tu vas choisir ton provider.
Donc tu vas citer chez AWS, tu vas pouvoir le mettre chez AWS,
si tu es chez GCP, tu vas pouvoir le mettre chez eux, et la même chose chez Azure.
Du coup, ça veut dire que si tu veux le mettre sur des infras localisées en France ou autre, tu peux.
Et eux, ils n'ont pas accès à tes secrets, ils managent la solution,
et toi, t'es protégé vis-à-vis de tes secrets, et par exemple du Clodact, tout ce genre de choses.
Alors t'es protégé à partir du moment où tu as mis...
Témoins exposés, c'est-à-dire, peut-être du dire.
En fait, ils vont te fournir la Master Key, donc est-ce qu'ils la sauvegardent dans un coin encore ?
Ah, d'accord, excuse-moi, je pensais que tu générais toi-même ta Master Key.
Je crois pas, mais peut-être que si, là tu vois, j'ai un doute.
On parle bien de HitchiCorp Cloud Platform, on a parti au caron.
HitchiCorp, ils ont décliné pour Consul, Vault, et maintenant, et Nomad.
Et Terraform aussi.
Ceci plus dans quel sens ?
Alors Terraform, c'est différent.
Oui, mais c'est intégré, je veux dire, dans l'écosystème à ce niveau-là.
Oui, c'est ça.
En tout cas, je vois sur leur site qu'il y a beaucoup de partenaires, alors peut-être qu'en effet,
il y a des partenaires qui fournissent du Vault à The Service, je pense qu'il faudrait les contacter,
si on veut pas gérer son propre Vault.
Je pense qu'ils partenaires, ils entendent plus les personnes qui ont des niveaux de partenariat
pour conseiller dessus ou des migrations.
Je le sais parce que notre entreprise est partenaires avec HitchiCorp, donc on doit être dans la liste.
Si vous voulez contacter moi, je vous installe un Vault.
Est-ce qu'on a autre chose à dire sur Vault ou est-ce qu'on passe aux alternatives ?
Alors, je vais juste compléter une dernière partie.
On a parlé d'authentification, gestion des secrets, etc.
Mais il y a aussi quelques fonctionnalités sympas comme je veux chiffrer une donnée
pour la mettre dans la base de données normales.
En fait, ils ont aussi des mécanismes pour dire, chiffre-moi cette donnée-là.
Vos donne-moi la donnée chiffrée, tu la stockes dans ta base de données où tu veux.
Et au moment où tu veux la déchiffrer, tu récupères la donnée chiffrée,
tu la redonne à Vault et il va te la redonner en clair.
Donc il y a plein de petits trucs comme ça qui vont te permettre de simplifier la vie.
Donc ça va permettre de sécuriser vraiment toute ton infrastructure,
mais aussi des développeurs ne sont pas suffisamment à l'aise avec le chiffrement.
Ça va leur permettre de chiffrer les trucs.
Et ça, c'est un truc de manière globale.
Ne faites pas votre propre chiffrement parce que sinon,
vous allez vous retrouver avec les données en clair.
Donc au mieux, utiliser des librairies qui vont gérer le chiffrement pour vous
au pire, utiliser GPG ou Vault, mais bricolez pas un truc dans votre coin.
Le ROT13 pour chiffrer les données, ça marche plus.
D'ailleurs, juste une petite pression, je ne sais pas si on l'a dit,
mais Vault, du coup, il y a bien sûr un client en ligne de commande qui existe,
qui est très bien fait, il y a une API et il y a bien évidemment une petite interface graphique
si vous avez peur que certains développeurs soient un peu perdus au début
qui peut un peu aider à retrouver ces petits.
C'est vraiment un bon produit, n'hésitez pas à regarder aussi un peu les intégrations
comme on l'a dit sur REN, sur AWS, il y a moyen de faire des choses très intéressantes,
sans trop de galère.
J'ai jamais eu trop de galère à faire des trucs,
vous savez, avec 10 000 niveaux de dépendance pour en arriver à un truc automatique.
Généralement, ça se fait assez rapidement, assez facilement,
donc n'hésitez pas à creuser un peu ça.
Oui, il y a pas mal d'intégrations aussi toutes faites pour les bases de données,
pour la BTMQ, enfin pour des produits un peu standard classiques.
Il y a aussi pas mal de librairies, pas mal de langages,
ce qui fait que si vous voulez pousser à l'extrême la gestion de vos secrets,
vous demandez aux développeurs d'intégrer le SDK dans l'application
et plutôt que de charger les secrets en variables d'environnement,
il va les demander le secret directement à Volt.
Comme ça, vous fournissez qu'un token au moment où l'application démarre,
donc ça sera un token de Volt.
Et le token de Volt, vous allez lui donner accès au secret pour la base de données,
le secret pour la BTMQ, le secret pour Stripe et c'est tout.
Et bien maintenant qu'on a bien parlé de Volt,
on peut peut-être parler des alternatives pour les équipes un peu plus...
ou alors pour les équipes qui veulent pas de Volt, par exemple.
Et je crois que Damir a des solutions en sace.
Alors, c'est quasiment, je pense, la plupart des gros cloud providers le fournissent.
Chez Scaloway, je crois que c'est en cours de développement d'ailleurs.
Mais vous pouvez tout simplement être des services de gestion de secrets
qui sont proposés par les fournisseurs de cloud existants.
Donc je pense notamment à WS Secret Manager,
et pour les autres, honnêtement, je ne saurais pas le nom.
Mais il y en a à peu près sur tous les cloud providers,
ou les fournisseurs cloud, si j'arrive à remettre mes mots dans le bon sens.
C'est une solution qui même si elle n'est pas portative,
elle apporte quand même un bon niveau de sécurité.
Surtout, vous n'avez pas à manager derrière des rotations
de clé-chiffrement de bas niveau, etc.
Ni des backups et des choses comme ça qui peuvent être un peu sensibles
quand vous êtes une petite équipe justement.
Donc ça peut être une très bonne alternative.
L'autre chose qui est aussi bien, c'est que souvent,
c'est très bien intégré avec l'écosystème dans lequel vous êtes.
Donc pour le coup, ça peut aussi là-dessus,
vous faire gagner un peu de temps quand une petite équipe,
encore une fois, c'est des choses qui comptent.
Donc là-dessus, je ne sais pas si vous avez déjà utilisé
des secrets manager qui étaient fournis par les provider cloud.
Moi, j'ai essayé juste à WS Secret Manager,
une petite équipe, et ça marchait bien.
Vous pouvez apporter même des clés de chiffrement externes avec AMS.
Donc il n'y a pas trop de soucis là-dessus.
Et sinon, une autre solution, c'est aussi de réduire des fois le nombre de secrets.
Alors ça, c'est comme je disais, c'est par rapport au design des plateformes.
Je reprends mon exemple avec WS, parce que c'est très utilisé.
Là-dessus, c'est ce que je connais le mieux niveau exemple.
Si vous avez une application, en fait,
qui est, on va prendre un cas très simple,
votre application de tourne sur une machine virtuelle, donc une C2 sur AWS,
elle doit se connecter en fait à un autre service, une base de données ou autre.
Vous seriez tenté de créer un usateur en base de données
et de le fournir dans votre application, par un moins à X ou Y.
Mais en fait, si vous pouvez simplifier votre problème,
et plutôt que vous dire, j'ai besoin de stocker ça de ma carte secrète
et de pouvoir le provisionner de manière sécurisée,
là, vous pouvez simplement ne pas l'utiliser
et ajouter par exemple un profil à un rolyam à votre instance
qui va lui donner le droit de se connecter à votre instance RDS.
Donc, c'est le genre de choses qui peut vous éviter d'avoir trop de mots de passe
et quand vous êtes une petite équipe,
parfois, ça peut vous enlever les mots de passe qui vous embêtent un peu
et vous pouvez vous contenter de solutions plus light
comme on a cité au début pour gérer le reste des mots de passe.
Ça peut être aussi une manière d'éviter le problème, on va dire,
et de réduire le risque notamment dans les petites équipes.
Justement, en parlant de solutions plus light,
il y a certaines de ces solutions light qu'on a citées au début
qui ont une API ou un client en ligne de commande.
Et moi, je commence à me poser la question
pour aller un peu plus loin que juste ma gestion de secrète en guide,
mais sans aller vers DuVold, parce qu'on n'est pas une équipe extensible,
on est moins de 5, on est 3 en fait, donc 3, c'est pas beaucoup.
Est-ce qu'à partir du moment où justement, on a un gestionnaire de mots de passe
qui a une API ou un client en ligne de commande,
est-ce que ça peut être une alternative crédible,
justement, à ces besoins, et est-ce que vous avez déjà entendu parler de ça ?
Par exemple, je vais citer Bitwarden à un client en ligne de commande,
Passbolt à une API, un client en ligne de commande,
est-ce qu'on peut justement utiliser ces solutions en tant qu'offre-fort,
plus simplement en tant que gestionnaire de mots de passe ?
Moi, ce qui me marque, je pense que oui, après en fait,
il y a des points qui m'inquiètent notamment l'auditabilité des logs d'accès
ou des choses comme ça, ou les ACL qui seront beaucoup moins fines,
c'est des choses qui personnellement, en fait, m'inquiètent et l'intégration aussi.
C'est toujours le genre de choses où j'ai eu à le faire une fois avec OnePassword,
mais c'était une version assez ancienne,
et on se retrouve à devoir recréer des petits scripts pour un peu rentrer
dans ces use cases et des choses-là.
Donc j'ai toujours un peu cette peur perso,
et c'est pour ça que j'ai du mal à...
On va dire que je ne les considère pas forcément au même niveau, on va dire.
Plus comme des gestions de mots de passe, plus-plus, que des vrais vaults.
Moi, j'ai connaissance de clients qui utilisent, par exemple, on n'en a pas parlé,
mais LastPass qui est un équipement de OnePassword, je pense,
en SASS pour faire ce genre de choses.
Voilà.
Donc moi, je pense que ça peut,
c'est un peu...
Il ne faut pas s'attendre à la même chose que avec Vault, c'est pour des implements plus light.
Oui, c'est vraiment le but.
C'est pour des implements plus légères.
Justement, quand j'ai cherché des alternatives à Vault plus légères,
j'étais tombé sur un projet, mais que je ne connais pas,
qui s'appelle Psono, qui apparemment fait quelque chose d'équivalent,
mais en termes plus légers.
Et justement, c'est ce qui est sur la question que je me pose
pour des petites architectures avec, je ne sais pas,
une casaine de serveurs avec quelques services.
Est-ce que ces gestions de ModePass peuvent suffire ?
Je pense qu'on fera d'époque, un jour, pour savoir.
Je sais que Nicolas, tu as peut-être essayé OnePassword, justement, avec ça.
Oui.
Alors, côté OnePassword, il y a deux parties.
Il y en a une que je n'ai pas testé, mais qui est vraiment dédiée à l'infrastructure,
donc en plus, leur pricing est un petit peu bizarre.
Tu payes la récupération de ModePass, donc si tu en récupères 3 par jour,
tu vas payer 8€ et si tu en récupères 3000, tu vas payer plus cher.
C'est un petit peu bizarre, mais bon.
Mais ça permet de faire un équivalent de Vault,
sans avoir la complexité de Vault.
Donc a priori, c'est juste un contenu en docleur à mettre,
et puis après, tu vas avoir une appellie dans laquelle tu vas taper
pour aller chercher tes secrets, comme Vault,
avec l'intérêt de partager tes secrets avec ton OnePassword,
entreprise dans lequel tu mets tous tes secrets normaux.
Après, alors, c'est clairement pas du même niveau de Vault,
mais quand tu vas vouloir avoir des outils qui ont besoin de secrets,
et c'est marrant, parce qu'en plus, c'était pour délotier les Vault,
ce dont je parlais, les fameux Unsealed Token.
Moi, je les stockais dans un Password Store ou dans un OnePassword.
Donc j'ai fait les deux.
Et en fait, j'ai fait un utilitaire Python qui est lancé
l'utilitaire en ligne de commande Password Store ou OnePassword,
qui allait récupérer l'entrée par rapport à mon Vault,
et dans lequel j'avais mis toutes les informations
qui m'intéressaient au format YAML.
Et donc, je récupérais le fichier YAML.
Je le parçais pour récupérer les logins, les pastes, les machins, etc.
Et comme j'avais tous les secrets en mémoire,
j'allais faire le Unsealed de mon Vault et tout ça de manière automatique.
Donc le seul truc dont j'avais besoin, c'était un accès à mon OnePassword
et l'outil en ligne de commande.
Donc ça, je l'ai fait avec OnePassword et aussi avec Password Store,
dont Amir est un fervent utilisateur,
donc il va pouvoir nous en parler un petit peu plus tout à l'heure.
Mais en fait, il faut voir ça comme d'un côté,
on va avoir de l'Encibal Vault qui est une excellente solution
pour stocker tous vos secrets,
pour tout ce qui est gestion de configuration,
et pour tous les outils annexes,
plutôt que des secrets sur des machines,
stocker les dans votre gestionnaire de mode Pass,
outiller votre truc pour aller chercher les trucs dans votre gestionnaire de mode Pass
et utiliser des connexions SSH pour aller faire des trucs sur les différentes
composantes de vos infrastructures qui ont besoin de ce secret.
Vous avez des API, vous avez des trucs,
vous pouvez tout faire à distance.
Typiquement, ce que je fais pour OnePassword,
c'est que j'utilise un tunnel SSH qui ouvre un proxy SOX
et je déverrouille mes vaults via la paie à travers le proxy SOX.
Donc mes vaults sont hierment protégés,
ils ne sont pas visibles d'Internet,
mais j'arrive à les déverrouiller à partir de ma workset chaîne.
Si vous avez des questions là-dessus,
j'ai mis une partie du truc en open source,
et puis venez me poser des questions sur le forum,
je me ferai un plaisir de vous répondre.
Je vais laisser Damir présenter Password Store.
Je vais faire une petite présentation rapide.
Password Store à la base, c'est un outil qui est très antique,
il fait vraiment pas grand chose en soi, mais il le fait bien.
Pour le coup, ce qui est intéressant avec cet outil,
c'est qu'il se repose sur des standards,
donc c'est du repos sur du PGP, du guide pour faire de la synchro et du versioning des secrets,
dans Backend, donc ça, ça marche plutôt bien.
C'est simplement un gestoire de secret.
Pour l'info, j'avais pas eu de gestoire de secret avant,
moi gestoire de mot de passe secret,
avant celui-ci, celui-ci qui m'a aidé à franchir le pas.
Ce qui est intéressant, c'est qu'il est ultra extensible,
donc de base, il va juste faire un moteur pour gérer vos secrets,
possiblement il va vous fournir aussi un pseudo proxy à la commande dite
pour pousser ça sur un repo à vous en Backend.
Et ce qui est intéressant, c'est que vous allez avoir de base à un outil
qui est en ligne de commande, donc très facilement vous pouvez l'automatiser
pour récupérer des secrets ou des choses comme ça.
Pour info, typiquement, sur Skylway,
il n'y a pas d'outilitaire pour gérer les tokens de session.
Moi, je les ai stockés en fait dans Password Store,
et dès que je vais dans mon repo Skylway, sur mon ordinateur,
du coup, en fait, ça a fait un...
J'ai mon diranfe qui exécute automatiquement mon Password Store
pour récupérer mes tokens et les exposer en fait.
Donc, je n'ai même pas m'en préoccupé, c'est un exemple comme un autre.
Du coup, c'est très extensible là-dessus.
Et vous avez plein de choses que vous avez pour acheter.
Il y a des extensions navigateurs, il y a des clients en téléphone,
sur Android, sur iPhone.
Il y a bien sûr des clients aussi.
Moi, je sais que j'ai un client sur UGNOME
qui me permet de récupérer directement dans la barre de recherche UGNOME,
mes secrets.
Il y a plein de choses, il y a moins de faire vraiment ce que vous voulez avec.
Moi, j'aime bien ce côté très simple et extensible.
J'ai écrit un petit article dessus pour un peu vous montrer à quoi ça ressemble.
Avec le workflow, je disais,
moi, ma clé PGP typiquement, elle n'est pas sur mon PC,
elle est sur une clé physique à part.
Donc, j'avais expliqué un peu tout ça sur un petit article
qu'on vous mettra en commentaire, ça vous intéresse.
Et tout comme Nicolas, si vous avez des questions là-dessus,
je suis totalement ouvert à échanger avec vous
sur toutes vos questions et voir comment améliorer ça
ou trouver d'autres use cases.
Si j'ai bien compris,
j'avais une question à poser à Damir pour être sûr d'avoir bien compris.
Ton password store, il a un dépôt central qui est ton dépôt Git.
Par défaut, il n'en a pas.
C'est toi qui peux dire,
« Mes mots de passe, tu es sauvegarde sur Git ».
Et du coup, après, c'est le fonctionnement de Git.
En fait, tu peux faire la commande passe, espace, Git, POOL, Gitpush, etc.
Mais tu peux aussi tout simplement aller directement
dans l'endroit où il stock tes mots de passe et faire du Git POOL, Gitpush,
c'est du Git très simple derrière.
Moi, j'aime bien cet aspect de ne pas réinventer la roue,
mais ça fonctionne plutôt bien.
Ah, d'accord.
C'est pas password store qui va gérer ton dépôt Git,
c'est toi qui va le gérer en fait.
Alors, non, tu peux le gérer avec password store,
mais globalement, si tu fais gérer avec password store,
tu vas faire la commande passe qui est la commande de password store.
Espace, Git, espace, t'es commande Git.
En fait, c'est juste un alias pour éviter que tu es allé dans le dossier à chaque fois.
Mais oui, ça demande un peu.
Alors, ça, c'est en ligne de commande,
mais si jamais vous êtes moins à l'aise avec la technique, etc.
La plupart des clients, il y a plein de clients graphiques pour password store.
Là, typiquement, je suis sur mon ordite jeu qui est sous Windows,
j'utilise un client graphique.
Et c'est lui qui va charger de faire un Git POOL,
un Gitpush automatiquement, qui va charger de faire les commits automatiquement.
Donc, la plupart des clients intègrent tout ça automatiquement,
mais l'outil de base est ultra basique.
Ce qui est intéressant, derrière, c'est justement de pouvoir trouver le client qu'on aime bien, etc.
Du coup, ce client-là en ligne de commande,
tu peux l'intégrer dans un script au démarrage de ton serveur,
par exemple, qui va populariser dans des vagues d'environnement et tes secrets.
Totalement.
Ou au lancement de ton application.
Totalement.
Tu es trop au toit un peu dans le disque.
Est-ce que j'ai sur mon PC Pro,
ou quand je vais sur mes projets de Pox Callaway,
en fait, il va récupérer des secrets qui correspondent et il va les exposer.
Je vais compléter un petit peu.
En fait, quand je l'ai découvert,
j'étais dans une équipe où au début, on était deux,
et on avait un qui passe,
qui passe génial, qu'on est tout seul.
Mais à partir du moment où il n'est deux,
du coup, on l'avait foutu dans un repository Git.
Et puis, quand tu modifies, tu fais Git Add, Git Commit,
tu mets ce que tu as modifié.
Alors déjà, en termes de sécurité,
ce n'est pas terrible parce que tu sais qu'il y a l'entrée que tu as modifiée.
Donc si tu veux faire un petit peu de river sur la base,
j'imagine que ça te donne des indices.
Mais bon.
Et puis au bout d'un moment,
on a été trois, quatre, cinq, ça devenait ingérable.
Donc on est passés sur PassWord Store.
Et le gros intérêt, c'est que c'est basé sur GPG.
Et comme c'est basé sur GPG,
chaque personne peut avoir sa clé publique
dans le repository Git du PassWord Store.
Et en fait, au moment où tu chiffres un nouveau secret,
il va le chiffrer pour que ça soit lisible
pour tous les utilisateurs de la clé.
Et le truc de génial,
c'est que le jour où il y en a un qui part,
t'enlèves sa clé,
tu rechiffres l'intégralité du PassWord Store.
Je n'ai pas dit que c'était facile
parce qu'à chaque fois qu'il y en a un qui partait,
on mettait une demi-journée pour retrouver comment faire.
Mais comme c'est du Git,
tu risques de rien casser.
Et une fois que tout est rechiffré,
tu recommites, tu repousses.
Et comme ça, tout le monde peut avoir
la nouvelle base qui est rechiffrée correctement pour tout le monde.
Et par contre, pour ton utilisation,
Christophe, moi je ne mettrais pas forcément
le PassWord Store sur la machine.
Je le mettrai dans un script
qui préparait tout pour pouvoir aller le pousser sur le serveur.
Ou alors avoir un PassWord Store à part
pour spécifiquement ce serveur-là.
Parce que ça aussi, c'est un truc dont on n'a pas parlé,
mais c'est que PassWord Store permet d'avoir plusieurs repositories.
Moi, j'en avais un pour ma boîte
et j'en avais un perso.
Les deux coexistaient.
Alors, c'était pas simple
parce qu'il fallait aller à la main
pour aller faire certaines manipulations.
Par contre, l'édition de la création de nouveaux PassWords
et ainsi de suite fonctionnait très très bien.
Et je l'ai fait à l'époque
où il n'y avait pas de client frontaine
d'appareil vieux truc en QT tout moche.
Oui, alors du coup, ce que je comprends,
dans ce que vous dites, c'est que PassWord Store,
c'est bien mais en fait,
t'as qu'un seul niveau d'accès soit à accès,
soit t'as pas de gestion de groupe,
genre de choses.
Oui, c'est le problème.
C'est pour ça que, comme dit Nicolas,
si tu veux faire ça,
il faut que tu fasses des projets à part,
potentiellement, pour délimiter des scopes
et tu peux démiter avec les clés.
Mais ça devient assez vite,
difficile à maintenir en fait.
Moi, c'est pour ça que PassWord Store
utilise vraiment que pour mon guide...
mon mémo de passe perso en fait.
Mais si jamais,
demain je devais détendre une équipe,
j'avoue que je aurais temps,
ça a eu de ses peut-être d'autres outils.
Bitwardon a l'air très très bien pour faire ça.
Je pense qu'on essaiera ça
puisqu'on a déjà un Bitwardon
on fera d'époque avec.
Est-ce que tu veux...
Oui.
Juste pour terminer sur Bitwardon,
on est d'accord qu'il y a bien un client
en ligne de commande.
Oui, tout à fait.
Tu peux bien faire des coffres forts séparées.
Oui, tu peux faire des coffres et des accès.
Et donc tu peux créer un compte spécifique
pour ton serveur et mettre tes secrets
dans un coffre à part.
Exactement.
Ton serveur, ton application,
enfin, à partir du moment où...
enfin, tu as une infinité de partage au fait.
Donc ton secret, tu peux le partager
à ton infra A, à ton infra B, j'imagine.
Ça, ça fait partie des choses que je pense qu'on va tester.
Moi, je ferais comme ça.
Notez qu'il y a une alternative qui s'appelle Vaultwardon.
Oui, tout à fait.
Il y a une alternative codée en Rust.
Je vais le dire pour que ce soit par ordet qui le dise.
Il s'appelle Vaultwardon.
Tout à fait.
Je crois que juste un des avantages,
c'est que sur le site de Bitwardon,
il fallait, à un moment, il fallait...
Au début, il fallait rentrer les crédents de choses
où je me rappelle plus trop.
Il y avait une certaine imitation.
Et du coup, Vaultwardon, voilà.
Il y a passé l'imitation, enfin,
imitation, entre guillemets.
Alors je sais pas si c'est le partage
qui est désactivé dans Bitwardon version libre
ou si c'est...
si c'est le fait de pouvoir
avoir le client, je sais pas.
Mais en tout cas, Vaultwardon, c'est monté parce que...
Non, c'est ça.
Ou si c'est le fait d'avoir une authentification unique.
Et Vaultwardon, c'est...
a recodé, en fait, le client, le client,
le serveur, excusez-moi, le serveur en Rust,
pour justement pallier à ces limitations-là.
Je sais pas quelle limitation...
sont passées par là,
mais en tout cas, Vaultwardon,
permet de tout faire, c'est 100% compatible
avec tous les clients, en fait.
Alors moi, je vais essayer, ça marche.
Enfin, il y a déjà un bon moment,
ça marchait très très bien déjà à l'époque.
Donc j'imagine que ça s'est...
je dois améliorer.
Donc, à tester.
Eh bien, on arrive à la fin de cette émission.
C'est le moment de rappeler
notre cher auditeur, qu'il peut s'abonner
au podcast ou à la chaîne YouTube,
s'il veut voir nos petites boubouilles.
Le podcast, si...
si notre cher auditeur
tu veux le partager, je te le prie, fais-le.
Ça nous aidera à le faire découvrir,
parce que contrairement à YouTube,
il y a la partie découverte
sur le podcast, c'est un peu compliqué.
Enfin, ça marche surtout par boche à oreilles.
Et, je vous remercie
tous les trois encore de cet épisode,
fort intéressant et
encore une fois assez long et assez dense.
Je crois qu'on a pas soulé
notre auditeur, mais en tout cas qu'on lui a pris beaucoup de choses.
Et je vais donner le premier mot
de la fin à Damier.
Bah du coup, je conclurai par...
danser comme si personne ne vous regardait
et chiffrer vos données
et vos secrets comme si tout le monde les regardait.
Et, René, quel est ton mot de la fin ?
Je vais rester classique.
J'espère que l'épisode vous a plu
et que...
il y a eu plusieurs propositions
d'échanger sur le forum.
Donc, voilà, je pense que c'est la bonne place
pour avoir des infos de Damier et Nico.
Et, Nicolas, tu as le mot de la fin de la fin ?
Comme le disait Damier,
chiffrer comme si tout le monde regardait
et que vous écriviez tous vos secrets
sur des cas de postales.
Et puis,
chiffrer vos disques
parce que votre ordinateur aujourd'hui
sera l'ordinateur d'un autre plus tard.
Et chiffrer vos données dans vos bases
parce que de toute façon, elles vont liquer.
Donc, vous allez vous faire rendre sorbourgériser.
Donc, chiffrer, chiffrer, chiffrer.
Et vivre nu.
...