Génération automatique de secrets dans Helm

Génération automatique de secrets dans Helm

Équipe Kubernetes aaS de Mail.ru traduit une courte note sur la façon de générer automatiquement des secrets Helm lors de la mise à jour. Ce qui suit est un texte de l'auteur de l'article - directeur technique d'Intoware, une société qui développe des solutions SaaS.

Les conteneurs sont cool. Au début, j'étais anti-conteneur (je suis gêné de l'admettre), mais maintenant je soutiens pleinement l'utilisation de cette technologie. Si vous lisez ceci, nous espérons que vous avez réussi à naviguer dans les mers de Docker, à réaliser les avantages de Kubernetes et à vous rendre la vie beaucoup plus facile avec Helm.

Cependant, certaines choses sont clairement plus difficiles qu’elles ne devraient l’être.

Comment générer automatiquement des secrets lors de la mise à jour ?

Un secret Kubernetes est une ressource qui contient des paires clé/valeur que vous souhaitez utiliser dans votre code. Il peut s'agir de chaînes de connexion à une base de données, de mots de passe de messagerie, etc. En utilisant des secrets, vous créez une séparation claire entre le code et les paramètres, ce qui vous permet de personnaliser facilement différents déploiements sans modifier la base de code.

Une situation courante est celle où deux modules doivent communiquer à l'aide d'une clé commune. Personne en dehors du cluster ne doit connaître cette clé, car elle est destinée à la communication individuelle au sein du cluster.

Faire des secrets

En règle générale, pour créer un secret dans Helm, vous devez :

  • décrire le secret dans le fichier de valeurs ;
  • le redéfinir lors du déploiement ;
  • faites-y référence dans le déploiement/pod ;
  • ... profit!

Cela ressemble généralement à ceci :

apiVersion: v1
kind: Secret
metadata:
  name: my-super-awesome-api-key
type: Opaque
stringData:
  apiKey: {{ .Values.MyApiKeySecret | quote }}

Un simple secret Kubernetes utilisant les valeurs de values.yml

Mais disons que vous ne souhaitez pas spécifier votre secret dans le fichier de valeurs.

Il existe de nombreuses options lorsque le déploiement nécessite une clé partagée, qui doit être générée lors de l'installation.

Dans l’exemple de communication module à module ci-dessus, il n’est pas souhaitable de partager le secret en dehors du déploiement. Par conséquent, il est hautement souhaitable que Helm dispose de mécanismes permettant de générer automatiquement un secret sans avoir à le spécifier directement.

Crochets

Les hooks vous permettent d'exécuter du code à des emplacements spécifiques pendant le processus d'installation. Il se peut qu'un travail de configuration doive être exécuté après la première installation, ou peut-être qu'un nettoyage doive être effectué avant d'effectuer une mise à jour.

Pour résoudre notre problème d’ajout d’une clé générée lors de l’installation, les hooks de pré-installation sont idéaux. Mais il y a un hic : vous ne pouvez pas générer automatiquement le secret une fois lors d'une mise à jour. Les hooks fonctionneront à chaque mise à jour.

Si vous avez généré votre secret et que votre première installation n'a pas encore eu lieu, arrêtez de lire, le hook de pré-installation fonctionnera très bien pour vous.

Mais si le secret fait partie d'une mise à jour (peut-être une nouvelle fonctionnalité qui n'était pas présente lors de l'installation), alors il est dommage que vous ne puissiez pas créer un hook de pré-installation qui ne fonctionne qu'une seule fois.

fonctions

Les fonctions Helm vous permettent d'ajouter divers éléments de script à vos scripts de déploiement.

apiVersion: v1
kind: Secret
metadata:
  name: my-super-awesome-api-key
type: Opaque
stringData:
  apiKey: {{ uuidv4 | quote }} #Generate a new UUID and quote it

Cet exemple montre que la valeur du secret apiKey sera le nouvel UUID généré lors de l'installation.

Helm comprend une bibliothèque de fonctionnalités vraiment complète qui exploite les étonnantes fonctionnalités du modèle GO et la bibliothèque de fonctionnalités de Sprig pour créer des déploiements personnalisés.

Fonction de recherche

Ajouté dans Helm 3.1 Fonction de recherche, qui permet de demander un déploiement existant et :

  • vérifier l'existence des ressources ;
  • renvoie la valeur d'une ressource existante pour une utilisation ultérieure.

En utilisant ces deux fonctionnalités, nous pouvons créer un secret unique généré dynamiquement !

# 1. Запросить существование секрета и вернуть в переменной $secret
{{- $secret := (lookup "v1" "Secret" .Release.Namespace "some-awesome-secret" -}}
apiVersion: v1
kind: Secret
metadata:
  name: some-awesome-secret
type: Opaque

# 2. Если секрет существует, взять его значение как apiKey (секрет использует кодирование Base64, так что используйте ключ "data")
{{ if $secret -}}
data:
  apiKey: {{ $secret.data.apiKey }}

# 3. Если секрет не существует — создать его (в этот раз используйте "stringData", так как будет обычное значение)!
{{ else -}}
stringData:
  apiKey: {{ uuidv4 | quote }}
{{ end }}

Chaque fois qu'une nouvelle mise à jour est appliquée au serveur, Helm générera une nouvelle valeur secrète (s'il n'y a pas encore de secret) ou réutilisera la valeur existante.

Bonne chance!

Quoi d'autre à lire sur le sujet:

  1. Trois niveaux d'autoscaling dans Kubernetes et comment les utiliser efficacement.
  2. Kubernetes dans l'esprit du piratage avec un modèle de mise en œuvre.
  3. Notre chaîne Autour de Kubernetes dans Telegram.

Source: habr.com

Ajouter un commentaire