Comment déployer un serveur de développement Vault vers Kubernetes avec Helm.
La première étape vers le stockage, l’accès et le déploiement sécuritaire, dans le nuage ou sur place, d’informations sensibles relatives aux applications.
Dans le monde d’aujourd’hui, qui est orienté API et plateforme infonuagique, nous, opérateurs, développeurs et architectes, sommes placés devant le défi de taille que représentent la gestion des secrets d’application, le cryptage et l’accès à toute application ou infrastructure infonuagique. Sécuriser et faire la rotation de secrets régulièrement et correctement, tant dans le nuage que sur place, représente tout un défi. Il est pourtant essentiel de le faire pour que votre équipe DevOps puisse adopter l’Infrastructure en tant que Code.
Les secrets sont des renseignements sensibles relatifs à la configuration d’une application. Ils incluent des éléments tels que les clés API d’AWS, les mots de passe de bases de données, et les clés privées SSL et SSH. Contrairement aux secrets statiques qui sont définis à l’avance et sont partagés, les secrets dynamiques sont générés sur demande et sont uniques à chaque client. Comme ils n’existent pas tant qu’ils ne sont pas lus, les secrets dynamiques ne courent pas le risque d’être volés et sont plus en sécurité. Vault associe chaque secret dynamique à un bail et détruit automatiquement les identifiants du secret lorsque le bail expire. HashiCorp Vault donne aux développeurs et aux opérateurs la responsabilité de stocker, d’accéder et de déployer l’information délicate de façon sécuritaire, vers les applications et les infrastructures, en utilisant un flux de travail central qui garde en sécurité, par le cryptage des données en mouvement et au repos, les secrets et les données d’application. Cela élimine l’étalement des secrets et permet la rotation, la révocation d’accès et la portabilité des secrets.
L’étalement des secrets – HashiCorp Vault place tous vos secrets en un seul endroit. Dorénavant, plus besoin de coder les identifiants en dur dans le code source. La plupart du temps, ces identifiants codés en dur finissent éparpillés parmi les fichiers de configuration et les outils de gestion de configuration et stockés en texte clair en contrôle de version, wikis ou volumes partagés. Vault fournit un endroit sécuritaire pour stocker ces identifiants et assurer qu’ils soient cryptés et que leur accès soit enregistré par audit et donné uniquement aux clients autorisés. Cela élimine l’étalement des secrets et facilite l’identification de fuites potentielles dans votre infrastructure.
Rotation des secrets – Avec Vault, vous ne verrez plus comme statique l’information sensible dans votre environnement multinuages. La création, la rotation et le cryptage de secrets sont automatisés dans votre pipeline CI/CD. Comme les secrets sont fréquemment en rotation, un pirate qui une semaine, obtiendrait l’accès à vos secrets, le perdrait la semaine suivante.
Vault associe chaque secret dynamique à un bail. Lorsque le bail expire, les identifiants du secret sont automatiquement détruits. Comme ils n’existent pas tant qu’ils ne sont pas lus, les secrets dynamiques ne courent pas le risque d’être volés. Tout secret généré de façon dynamique est associé à un bail et Vault révoquera automatiquement ces secrets, une fois le bail expiré.
Révocation d’accès – Les politiques de contrôle d’accès fournissent un contrôle strict de l’accès aux secrets. Vault inclut des mécanismes de révocation dans leurs secrets dynamiques. Ils peuvent donc être révoqués immédiatement après l’usage ce qui minimise le temps d’existence des secrets. Vault garde les secrets dynamiques plus en sécurité et leur permet d’être déployés sur de multiples environnements infonuagiques.
Déploiements portatifs – Le déploiement de secrets dynamiques se fait traditionnellement par un fournisseur infonuagique à grande échelle. Vault permet le transport des secrets entre les nuages privés ou publics, ainsi que leur soutien sur toutes sortes de serveurs et de bases de données. Voici quelques exemples de moteurs de secrets soutenus par Vault :
Bases de données (PostgreSQL, MySQL, MSSQL, Oracle, etc.)
NoSQL (Cassandra, MongoDB, etc.)
File d’attente des messages (RabbitMQ, etc.)
Fournisseurs infonuagiques
SSH
PKI
Vault vous donne accès au meilleur des deux mondes et vous permet de transporter vos secrets dynamiques vers de multiples environnements en stockant vos secrets dans un système HashiCorp qui soutient les déploiements multinuages.
Dans cet article, nous allons créer dynamiquement des clés d’identité et de gestion d’accès AWS (AWS Identity and Access Management IAM) avec un serveur de développement Vault déployé dans Kubernetes avec Helm.
Cas d’utilisation pour la série : Un ex-employé, un pirate ou un voleur avec un accès API obtient des secrets par une application ayant des identifiants API
De nombreuses entreprises stockent leurs secrets sur des variables d’environnement ou sur un fichier config (comment l’API ou le CLI d’AWS fonctionnent du premier coup), ou les codent en dur directement dans le code source de contrôle de version. Ne faites pas ça. Vault offre une meilleure solution.
Imaginons qu’un employé ayant des privilèges d’utilisateurs avancés, ou similaires, chez un fournisseur de services infonuagiques est congédié ou se fait voler son ordinateur portable dans un café. Le voleur ou l’ex-employé pourrait obtenir l’accès aux données sensibles en utilisant les clés API utilisées auparavant comme variables environnementales pour connecter les différentes API infonuagiques. Il pourrait ensuite supprimer des données et des sauvegardes, mettre fin à des serveurs et causer des dommages importants à l’infrastructure infonuagique de l’organisation.
Ça n’a rien à voir avec Console ou avec un accès API qui est lié à un fournisseur d’identité, comme Active Directory. Maintenant que vous devez désactiver manuellement et faire la rotation des clés API individuelles, les temps d’arrêt qui en découlent causeront des maux de tête à l’équipe des opérations.
HashiCorp, non seulement résout ce problème, il vous permet aussi de révoquer (par une seule commande) les clés API (particulièrement celles pouvant être accédées par un ex-employé ou un employé dont l’ordinateur portable a été volé) et en générer de nouvelles pour l’utilisation de l’application. Essentiellement, l’application fera automatiquement la requête d’une nouvelle clé API générée par l’interface API bien documentée de HashiCorp Vault.
Le pouvoir de révoquer et de renouveler automatiquement l’accès aux secrets est une fonctionnalité importante. De plus, chacune de ces requêtes est enregistrée et peut être vérifiée et archivée pour des raisons de conformité. D’autres techniques de stockage de secrets n’offrent pas ce type de capacité d’enregistrement et de vérification, surtout lors de requêtes individuelles d’API, d’une clé API ou d’accès à un service qui utilise une clé API.
Vault élimine l’étalement des secrets et gère leur cycle de vie en révoquant et en effectuant automatiquement un roulement des clés API ou des mots de passe de base de données. Il fournit, à l’équipe ou à l’organisation qui a accès à la création de secrets, à la lecture des secrets et au renouvellement ou à la révocation des secrets d’application, des enregistrements d’audits détaillés avec contrôle d’accès granulaire.
Tutoriel — comment déployer un serveur de développement Vault sur Kubernetes avec Helm.
Dans ce tutoriel, nous allons déployer un serveur de développement Vault sur Kubernetes avec Helm et avec l’incubateur Helm Chart. Le serveur dev stocke toutes ses données en mémoire (mais quand même cryptées) et lorsque la requête est faite, il descelle et présente automatiquement la clé Vault pour desceller et la clé d’accès root. Vous ne devriez jamais exploiter un serveur dev mode en production.
Qu’est-ce que Helm et Helm charts ?
Helm aide à gérer les applications Kubernetes. Helm Charts aide à définir, installer et mettre à niveau les applications Kubernetes les plus complexes. C’est un paquet qui contient toutes les définitions de ressources nécessaires à l’exécution d’une application, d’un outil ou d’un service dans une grappe Kubernetes. Considérez-le comme l’équivalent Kubernetes d’une formule homebrew, d’un Apt dpkg ou d’un fichier Yum RPM. Nous allons utiliser le diagramme (chart) incubateur « Vault » de Kubernetes.
Ce qu’il vous faut
https://github.com/kubernetes/helm#install.
Avant de commencer ce tutoriel, assurez-vous d’utiliser une grappe Kubernetes de version 1.6 ou supérieure. Assurez-vous que Helm soit installé sur votre machine client et que kubectl est installé et configuré pour se connecter à votre grappe Kubernetes. Si vous avez plus d’une grappe, utilisez la grappe de développement pour ce tutoriel.
Déployer Vault sur Kubernetes avec Helm
Une fois que Helm est prêt, initialisez le CLI local et installez Tiller dans votre grappe Kubernetes en une étape :
$ helm init
Si vous tapez :
$ helm version
Vous devriez voir :
Client: &version.Version{SemVer:"v2.8.1",
GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2",
GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.8.1",
GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2",
GitTreeState:"clean"}Cela signifie que Helm et ses composants du côté serveur (Tiller) sont installés et prêts à être utilisés. Ajoutons maintenant le dépôt incubateur à Helm.
$ helm repo add incubator http://storage.googleapis.com/kubernetes-charts-incubator
Actuellement, votre Chart utilise l’image docker Vault de Docker Hub avec une version vault 0.9.0.
image: repository: vault tag: 0.9.0 pullPolicy: IfNotPresent
Afin de déployer une version de développement de Vault running, exécuter la commande suivante :
$ helm install incubator/vault --name vault-dev
Cela provisionnera automatiquement un service, un déploiement, un pod et une ConfigMap Kubernetes comme ci-dessous :
NAME: vault-dev LAST DEPLOYED: Wed Mar 14 17:13:43 2018 NAMESPACE: default STATUS: DEPLOYEDRESOURCES: ==> v1/ConfigMap NAME DATA AGE vault-dev-vault-config-1 1 0s
==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE vault-dev-vault ClusterIP 100.68.247.74 8200/TCP 0s
==> v1beta1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE vault-dev-vault 1 0 0 0 0s
==> v1/Pod(related) NAME READY STATUS RESTARTS AGE vault-dev-vault-764c78cd94-xqxfn 0/1 ContainerCreating 0 0s
Helm fournit un ensemble de notes que vous pouvez utiliser pour vous connecter au serveur Vault avec les capacités de redirection de port de kubectl.
NOTES:
- Get the application URL by running these commands: export POD_NAME=$(kubectl get pods –namespace default -l “app=vault” -o jsonpath=”{.items[0].metadata.name}") echo “Use http://127.0.0.1:8200 as the Vault address after forwarding.” kubectl port-forward $POD_NAME 8200:8200
À l’instant, le serveur Vault est exposé à la grappe Kubernetes à l’interne seulement. Seuls les services Kubernetes peuvent communiquer entre eux, et non les utilisateurs externes. Vous devriez pouvoir vous connecter au serveur Vault à partir de n’importe quelle application en utilisant le service déployé par Helm.
http://vault-dev-vault:8200
Il existe une façon de l’exposer, en dehors de la grappe, par un contrôleur et des ressources Ingress. Cela dépasse le cadre de cet article de blogue. Dans le cas qui nous intéresse, nous allons exécuter la première commande « exporter » dans la section NOTES afin d’obtenir le nom du pod qui a été déployé.
$ export POD_NAME=$(kubectl get pods –namespace default -l “app=vault” -o jsonpath=”{.items[0].metadata.name}")Pour voir le Root Token important et nécessaire pour procéder à la génération de secrets dynamiques AWS qui fait partie du présent article de blogue, exécutez :
$ kubectl logs $POD_NAME
Vous devriez voir apparaitre ceci sur votre terminal :
Le Root Token est surligné ici. Veuillez le noter quelque part puisque vous en aurez besoin plus tard.
Ensuite, redirigez le port au pod exploité sur notre grappe Kubernetes en exécutant la dernière commande NOTES ci-dessous :
$ kubectl port-forward $POD_NAME 8200:8200
Cela permettra à votre adresse IP locale (127.0.0.1:8200) d’agir comme mandataire pour le serveur Vault.
Ensuite, ouvrez un nouvel onglet ou une nouvelle fenêtre terminal. Après avoir ouvert le nouveau terminal, tapez ceci pour exporter la variable environnementale :
$ export VAULT_ADDR='http://127.0.0.1:8200'
Nous avons maintenant besoin de télécharger le système binaire Vault sur notre machine de client afin de communiquer et d’exécuter les commandes Vault CLI. Vault est une multiplateforme alors elle devrait fonctionner sur n’importe quelle plateforme.
Vous devriez être capable de mettre en vault l’exécutable Unix pour Linux/Mac. Ouvrez votre terminal et changez votre répertoire vers le chemin où est stocké et typé l’exécutable vault.
$ vault status
Ensuite, connectez-vous au serveur vault en collant le Root token obtenu de la section logs :
$ vault login
On peut maintenant se féliciter. Nous avons réussi à déployer un serveur de développement Vault sur Kubernetes avec Helm.
Pour activer les secrets dynamiques d’AWS sur Vault, tapez la commande suivante dans votre terminal :
$ vault secrets enable -path=aws aws
Avant de procéder, configurons d’abord notre compte AWS pour qu’il utilise les secrets.
Allez à IAM Management Console et créez un nouvel Utilisateur avec les permissions suivantes : ne lui donnez que l’accès : Programmatic Access.
Créez une politique et joignez-la à l’utilisateur. Nommez-la “ hashicorp-vault-lab ”. Assurez-vous de remplacer votre ID de compte dans » Resource « . Ainsi, quand Vault crée dynamiquement les utilisateurs, le nom d’utilisateur commence par le préfixe » vault- « .
On trouve le numéro de compte dans AWS Support Dashboard:
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“iam:AttachUserPolicy”,
“iam:CreateAccessKey”,
“iam:CreateUser”,
“iam:DeleteAccessKey”,
“iam:DeleteUser”,
“iam:DeleteUserPolicy”,
“iam:DetachUserPolicy”,
“iam:ListAccessKeys”,
“iam:ListAttachedUserPolicies”,
“iam:ListGroupsForUser”,
“iam:ListUserPolicies”,
“iam:PutUserPolicy”,
“iam:RemoveUserFromGroup”
],
“Resource”: [
“arn:aws:iam::ACCOUNT_ID:user/vault-*”
]
}
]
}Vous devriez avoir un utilisateur avec la politique jointe comme ceci :
Vous devriez aussi recevoir un fichier .csv avec les clés “Access Key ID” et “Secret Access Key.” Seules ces clés devraient être utilisées pour configurer Vault. Pour des raisons de sécurité, supprimez-les de votre ordinateur immédiatement après, car Vault gère le cryptage de ces clés de façon interne. Elles ne peuvent être lues après avoir été configurées, on ne peut que les écraser.
Voici un exemple de ce qu’il faut faire pour les configurer : veuillez remplacer “ access_key ” et “ secret_key ” par vos clés.
$ vault write aws/config/root
access_key=ACCESS_KEY_ID
secret_key=SECRET_ACCESS_KEY
Ensuite, créez un rôle à utiliser avec Vault pour que, au besoin, votre application ait un utilisateur associé à ce rôle. Par exemple, votre application pourrait nécessiter un rôle qui peut faire n’importe quelle opération CRUD sur S3. Créons-en un maintenant. Vous pouvez le restreindre autant que vous le désirez. Joignez une politique à ce rôle en utilisant un relevé direct EOF (End-Of-File).
Si votre application infonuagique sur place ou sans serveur a besoin d’obtenir un accès S3 et d’utiliser une clé » API access key « , vous pouvez simplement utiliser un » Vault token » pour vous connecter par l’interface Vault RESTful API. Dans ce cas-ci, votre Vault token devrait être autre chose que vos identifiants root en production, vous les créez spécialement pour permettre à votre application de créer des clés d’accès et d’être incapable de lire toutes les autres clés d’accès. Vous trouverez de plus amples informations sur RESTful API ici. Le point particulier relatif à l’utilisation dans votre application se trouve ici.
Dans le cadre de ce tutoriel, nous allons le réaliser en utilisant à la place, l’outil CLI Vault pour générer un utilisateur IAM temporaire avec Vault :
$ vault read aws/creds/s3-all-crud-role
Vous pouvez aussi l’exporter en format JSON. Par défaut, il est en format table, donc vous pouvez l’éditer avec jq en utilisant le paramètre -format=json.
$ vault read -format=json aws/creds/s3-all-crud-role
Comme vous pouvez le constater, il a généré 2 identifiants complètement différents ; les deux identifiants ont une durée de bail de 768 heures. Cela signifie que Vault supprimera automatiquement les utilisateurs dans AWS après 768 heures.
Si vous allez à AWS IAM et recherchez “vault-”, vous devriez pouvoir les trouver.
La génération de secrets dynamiques de Vault est pratique, car elle a pris le rôle, a généré l’utilisateur, joint la politique et vous a redonné la clé d’accès et la clé de secret :
Il serait peut-être bon d’augmenter la sécurité en configurant un bail de 24 heures en ajoutant à la configuration une valeur-clé dans Vault comme ceci :
$ vault write aws/config/lease lease=24h lease_max=24h
Les clés générées avec les nouveaux utilisateurs IAM un une durée de bail de 24 heures :
Après 24 heures, Vault supprimera automatiquement l’utilisateur.
Idéalement, vous devriez utiliser l’ID de bail » lease_id » afin de renouveler l’utilisateur, ainsi, l’application n’est pas constamment en train de créer de nouveaux utilisateurs IAM. Pour ce faire, utiliser L’ID de bail » lease_id » fourni par Vault afin de renouveler simplement le bail.
Vous pouvez aussi utiliser le RESTful API de Vault ici :
Renouvelons la licence pour une heure seulement en utilisant le » lease_id » et 3600 secondes :
$ vault lease renew aws/creds/s3-all-crud-role/e928e56d-0261-5e03-d0ee-bce23c3005a4 3600
Houston, nous avons un problème. Nous avons été piratés.
Supposons que vous utilisez vos outils de surveillance pour attraper quelqu’un essayant d’obtenir l’accès à l’une de vos applications. Toutefois, ils ont pu copier une de vos variables environnementales contenant les clés : AWS API Key et Secret Access Keys générées avec Vault par votre application.
Comment pouvons-nous arrêter le pirate avant qu’il ne cause de sérieux dommages à votre organisation ?
Vous n’avez simplement qu’à révoquer les baux qui ont ces identifiants en utilisant, soit la CLI ou la RESTful API :
$ vault lease revoke -prefix aws/creds/s3-all-crud-role
Comme vous pouvez le constater, Vault a pu utiliser : » -prefix of s3-all-crud-role » pour révoquer tous les baux associés à ces rôles.
Vault est un outil fantastique qui simplifiera la sécurité de votre infrastructure. Cela éliminera l’étalement des secrets et facilitera la découverte de vulnérabilités. Il fera automatiquement la rotation des secrets et révoquera l’accès non autorisé. Les secrets dynamiques sont bien, en tant que tels, mais avec HashiCorps, ils deviennent fantastiques.
Jetez un œil sur mon repos pour plus d’idées de façons d’ajouter de la sécurité à votre Infrastructure en tant que Code.
Pour en apprendre plus sur l’utilisation de Docker et Kubernetes dans AWS, inscrivez-vous à l’un de nos <https: www.cloudops.com=”” fr=”” ateliers-docker-kubernetes=”” “=”” target=”_blank">ateliers. Nous offrons une gamme d’ateliers pratiques de trois jours pour vous aider à adopter les pratiques DevOps.</https:>
À propos de l’auteur – Adrian Todorov
Adrian Todorov est architecte de solutions de conteneur chez CloudOps. Il travaille de près avec Kubernetes, AWS, GCP et HashiCorp pour faire avancer la modernisation d’applications. Ce qu’Adrian aime par-dessus tout, c’est d’amener les clients vers les technologies et les processus de développement infonuagiques modernes, il espère guider les lecteurs à travers l’utilisation des projets de logiciel libre dans leur application.
