CACD2, l’entité Cloud Native

Une des missions de CACD2 est d’étudier les technologies de Cloud Computing aussi bien pour le déploiement d’éléments d’infrastructure, d’usine logicielle ou d’applications clientes. Lorsque l’on évoque le Cloud Computing, on ne peut s’empêcher de penser aux données sensibles dont le stockage et la sécurité doivent être étudiés attentivement dès les premières étapes de conception.

Celui qui cache son secret est maître de sa route.

Proverbe arabe

L’objectif n’est pas de ré-inventer la roue, la mise en place de solution maison en termes de sécurité étant quasi systématiquement vouée à l’échec. Nous avons préféré analyser un produit disponible sur le marché qui puisse remplir pleinement ces fonctions, en prenant en compte l’ensemble des bonnes pratiques de sécurité.

Nous avons ainsi identifié l’outil Hashicorp Vault, voici ce que nous en avons retiré.

On a tous nos petits secrets!

Un système d’information moderne contient une grande quantité de données secrètes :

  • Ces secrets sont de types divers: identifiants de connexion à une base de données, d’authentification, d’éléments d’infrastructure (Jenkins, Nexus, Sonarqube, …), clés de chiffrement, certificats divers (Kubernetes, intranet, bastion, …), API tokens d’applications ou de services tiers, identifiants AWS, …
  • Ces secrets varient en fonctions des différents environnements : développement, QA , pré-production, production…
  • Ces secrets sont aussi bien manipulés par des personnes qui appartiennent à des équipes différentes et qui ont des rôles différents, que par des machines ou par des applications.

Les problématiques fréquemment rencontrées pour la gestion des données secrètes concernent:

  • Le stockage de ces informations
  • Leur partage et leur distribution sécurisée
  • Leur accessibilité et les autorisations à accorder en fonction des rôles des utilisateurs (personnes, machines, applications)

 

Où stocker les secrets ?  (Sur un Post-It ? un fichier local ? le creux de la main ou un coin du cerveau ??? )

Les mauvaises pratiques liées au stockage des secrets sont les suivantes:

  • Dans un SCM (Source Control Management), bien que centralisé, les secrets stockés sont en clair dans le code source, des inconsistances peuvent survenir lors de changements, il y a ni contrôle d’accès, ni audit, ni révocation possible. Et pour finir, l’historique de la gestion de configuration n’oublie rien…
  • Les bases des données (relationnelle ou clé/valeur) n’ont pas été conçues à cet usage. Comme le cas précédent, le stockage est par défaut en clair, il y a ni audit, ni révocation possible, les contrôles d’accès sont limités.
  • Chez l’utilisateur, sur son poste ou sur tout autre dispositif, les accès et visibilités sont limités, il n’y a pas d’audit et souvent l’erreur est humaine.
  • Au sein des applications, le stockage des données sensible dans une image Docker est à proscrire, le transit de ces secrets par variables d’environnement (qui peuvent être dumpées) n’est pas recommandé.

 

Qui accède aux secrets et comment les partager ?

Les moyens de stockage précédemment énumérés présentent globalement des manquements par rapport aux contrôles d’accès, la distribution des secrets, la révocation en cas de compromission, la flexibilité et l’automatisation.

 

Implémentation chez CACD2

Etudions l’outil dans plus de profondeur

Avant même la construction de l’usine logicielle de CACD2, l’étude de l’outil Hashicorp Vault est un prérequis.

Trois semaines ont été consacrées à l’exploration, la mise en place et l’exploitation de l’outil, en suivant le plan de route ci-dessous :

  • Evaluer ses capacités, sa maturité et sa réponse aux besoins
  • Synthétiser une présentation pour les formations internes
  • Formaliser la manière dont cet outil sera administré et exploité au quotidien
  • Formaliser la gestion de configuration et des secrets d’applicatifs construits sur les technologies NodeJs et Java SpringBoot
  • Etudier la résolution des secrets applicatifs lors d’un déploiement sous Kubernetes

Pour résoudre ces problèmes liés aux secrets, la société californienne HashiCorp propose un coffre fort numérique Open Source sous le nom de Vault.

Quelques chiffres sur l’outil et la société :

  • Hashicorp: fondée en 2012 (San Francisco), 166 employés, CA de 3.6M$ (fin 2017), spécialisée dans les outils DevOps (virtualisation, déploiement, éléments d’infrastructure Cloud … tels Vagrant, Nomad, Consul, Terraform, Vault ..)
  • https://github.com/hashicorp/vault (8920 stars, Avril 2018) (codé en GoLang)
  • https://www.vaultproject.io/

Vault est une solution de coffre fort numérique conçue et réfléchie pour la gestion de secrets.

Ses principales caractéristiques sont :

  • La centralisation, le partage et la distribution sécurisée des secrets
  • La gestion fine des permissions d’accès (Access Control List, restrictions IP)
  • Une API unifiée pour lire/écrire les secrets (CLI ou HTTP)
  • Audit: Monitoring/Logs détaillés des activités sur le coffre-fort et des appels d’API
  • Un support de nombreux backend de stockage (etcd, dynamoDB, zookeeper, consul, mySQL, postgreSQL, AWS S3, Google cloud Storage, Azure, Swift, Filesystem, memory …) et un chiffrement des données sur ces supports
  • Un support de nombreux backend d’authentification (LDAP, AWS EC2, GitHub, Certificats TLS, Username/password ou Tokens par défaut)
  • Une génération des secrets, la gestion de leur révocation et du renouvellement renouvellement des token d’accès
  • Une conception Cloud-ready avec la gestion d’un déploiement en haute disponibilité
  • Le code est Open Source et visible de tous (pour ceux qui maîtrisent le Go, pas le jeu mais bien le langage de Google 😉 )

 

Architecture logique

https://www.vaultproject.io/docs/internals/architecture.html

Sur son schéma d’architecture interne, on identifie les principales briques fonctionnelles (authentification, gestion des permissions, identifiants, audit, révocation, ..) au sein de la « barrière de sécurité » qui délimite le modèle de sécurité de Vault

La description de son modèle de sécurité (https://www.vaultproject.io/docs/internals/security.html), sa manière de se prémunir contre des failles externes et internes et ses limitations de responsabilité démontrent la prise en compte des aspects sécuritaires par ses concepteurs.

 

Principe

Son principe de fonctionnement s’appuie sur une authentification des utilisateurs (personnes, machines, applications) associés à des permissions leur permettant d’accéder à des secrets (espaces modélisés sous forme de chemins comme un système de fichiers) stockés de manière chiffrée dans un backend de stockage de type AWS S3 par exemple.

L’utilisation quotidienne de son API via la CLI peut se résumer aux quelques commandes login, read et write:

(Car les autres commandes avancées pour exploiter, configurer et gérer les tokens d’accès sont réservées à l’administration du Vault)

export VAULT_ADDR= »https://VaultServerHostname » && vault login $VAULT_TOKEN

vault read -field=value secret/path/to/application/secretkey

vault write secret/path/to/application/secretkey value=secretvalue

(Ou avec Curl:

curl -s -H « X-Vault-Token: VAULT_TOKEN » https://VaultServerHostname/v1/ecret/path/to/application/secretkey )

 

Un travail de spécification a été effectué pour répertorier et mapper l’ensemble des secrets possibles pour les besoins de CACD2, ainsi que pour définir un jeu de permissions pour chaque rôle utilisateur (deployer, developer, developer-readonly )

 

Shamir Secret Sharing

Une des particularités dans la conception de Vault est l’utilisation du principe du partage de clés de Shamir ( https://en.wikipedia.org/wiki/Shamir’s_Secret_Sharing )  pour reconstruire la clé maître permettant de déchiffrer le contenu des secrets.

Au démarrage de Vault, le coffre est scellé (on ne peut ni lire, ni écrire); il faut le desceller avec 3 des 5 clés partagées.

 

Brisez la glace en cas d’urgence …

La procédure du « Break Glass Procedure » est appliquée en cas de compromission.

Les traces d’audit permettent d’identifier le token défaillant, Vault révoque le token pour l’application, le service ou l’opérateur et en régénère un autre.

 

Intégration de Kubernetes avec HashiCorp Vault

Cette partie a nécessité la revue de la gestion des configurations et des secrets applicatifs, il est en ressorti les points suivants:

  • La configuration logicielle spécifie la manière de gérer le paramétrage des applications
  • La configuration logicielle doit aussi résoudre les problèmes de complexité liés à la diversité des environnements et des plateformes de déploiement (local, test, développement, QA, production)
  • L’application de bonnes pratiques et nos réflexions d’équipe font émerger que la configuration:
    • Doit être séparée du code source (pour éviter une compilation du composant logiciel ou de l’image Docker lors d’un changement de paramètre)
    • Doit être centralisée et hiérarchisée
    • Doit être séparée pour chaque environnement (local, test, développement, QA, production)
    • Doit permettre la surcharge par variables d’environnement (permettant de traverser le module, le containeur Docker et son déploiement sous Kubernetes)
  • La configuration des secrets applicatifs est similaire et séparée de la configuration applicative
  • Le passage des secrets sur la couche Kubernetes est préférable en montage de volumes qu’en surcharge par variables d’environnement

 

Un premier jet pour cette résolution a été mise en place:

  • En s’inspirant de la solution de BootSport ( https://github.com/Boostport/kubernetes-vault ) avec un degré de complexité moindre
  • En remontant le plus d’intelligence côté déploiement pour rendre la tâche transparente pour le développeur
  • En évitant toute dépendance forte sur Vault dans les modules applicatifs (SDK, client vault …)
  • un module CACD2 « secret-resolver » a été écrit pour remplir cette fonction

L’InitContainer « secret-resolver » (exécuté avant le démarrage des conteneurs applicatifs) via son Token Vault va accéder au coffre fort numérique et résoudre les chemins des secrets contenus dans le fichier source sous  /secretref. Le résultat de la résolution est partagé en volume /run/secrets pour l’application dédiée.

 

Mise en pratique

Retour d’expérience depuis début Février 2018

  • La popularité et le niveau de documentation détaillée de Vault donnent un bon niveau de confiance sur l’outil
  • Son installation (binaire seul) et son évaluation locale n’a pas posé de soucis
  • Son installation sous AWS ECR et la configuration de son stockage sur un Bucket AWS S3 sont aisées
  • Son principe d’utilisation est à la portée de tous (notre équipe qui déploie des éléments d’infrastructure l’utilise au quotidien)
  • Tout est centralisé, hiérarchisé et associé à des permissions dédiées par rôle
  • Ses traces audit sont redirigées sur le service CloudWatch d’AWS
  • Son administration est maîtrisée par au moins 2 personnes de l’équipe CACD2
  • Les équipes de développement commencent à se familiariser avec l’outil pour la gestion des secrets applicatifs
  • Le TTL max d’un token est de 32 jours; cela demande un renouvellement régulier des tokens
  • Si jamais le serveur Vault redémarre, il faut être réactif pour refaire la phase de descellement avec les clés partagées

 

Axes d’améliorations possibles

  • Affiner les rôles et permissions suivant l’évolution des besoins
  • Mieux sensibiliser les équipes de développement sur le stockage des secrets applicatifs
  • Simplifier le mécanisme de « secret-resolver » encore un peu complexe sur certains aspects Kubernetes

 

Références

Sites officiels

Slideshares

 

Online training (avec un container)

 

Autres solutions du marché pour la gestion des secrets