Secrets | Kubernetes

Les informations contenues dans ce document peuvent être obsolètes
Ce document a une date de mise à jour antérieure à celle de l'original, les informations qu'il contient peuvent donc être obsolètes. Si vous comprenez l'anglais, consultez la version anglaise pour obtenir les informations les plus récentes : Secrets
Les objets secret de Kubernetes vous permettent de stocker et de gérer des informations sensibles, telles que les mots de passe, les jetons OAuth et les clés ssh. Mettre ces informations dans un secret est plus sûr et plus flexible que de le mettre en dur dans la définition d'un Pod ou dans une container image. Voir Document de conception des secrets pour plus d'informations.
Un secret est un objet qui contient une petite quantité de données sensibles telles qu'un mot de passe, un jeton ou une clé. De telles informations pourraient autrement être placées dans une spécification de pod ou dans une image; le placer dans un objet secret permet de mieux contrôler la façon dont il est utilisé et réduit le risque d'exposition accidentelle.
Les utilisateurs peuvent créer des secrets et le système crée également des secrets.
Pour utiliser un secret, un pod doit référencer le secret. Un secret peut être utilisé avec un pod de deux manières: sous forme de fichiers dans un volume monté sur un ou plusieurs de ses conteneurs, ou utilisé par kubelet lorsque vous récupérez des images pour le pod.
Kubernetes crée automatiquement des secrets qui contiennent des informations d'identification pour accéder à l'API et il modifie automatiquement vos pods pour utiliser ce type de secret.
La création et l'utilisation automatiques des informations d'identification de l'API peuvent être désactivées ou remplacées si vous le souhaitez. Cependant, si tout ce que vous avez à faire est d'accéder en toute sécurité à l'apiserver, il s'agit de la méthode recommandée.
Voir la documentation des Compte de service pour plus d'informations sur le fonctionnement des comptes de service.
Supposons que certains pods doivent accéder à une base de données. Le nom d'utilisateur et le mot de passe que les pods doivent utiliser se trouvent dans les fichiers ./username.txt et ./password.txt sur votre machine locale.
La commande kubectl create secret regroupe ces fichiers dans un secret et crée l'objet sur l'Apiserver.
Les caractères spéciaux tels que $, \, *, et ! seront interprétés par votre shell et nécessitent d'être échappés. Dans les shells les plus courants, le moyen le plus simple d'échapper au mot de passe est de l'entourer de guillemets simples ('). Par exemple, si votre mot de passe réel est S!B\*d$zDsb, vous devez exécuter la commande de cette façon:
Vous n'avez pas besoin d'échapper les caractères spéciaux dans les mots de passe des fichiers (--from-file).
Vous pouvez vérifier que le secret a été créé comme ceci:
Voir décoder un secret pour voir le contenu d'un secret.
Vous pouvez également créer un secret dans un fichier d'abord, au format json ou yaml, puis créer cet objet. Le secret contient deux table de hachage: data et stringData. Le champ data est utilisé pour stocker des données arbitraires, encodées en base64. Le champ stringData est fourni pour plus de commodité et vous permet de fournir des données secrètes sous forme de chaînes non codées.
Par exemple, pour stocker deux chaînes dans un secret à l'aide du champ data, convertissez-les en base64 comme suit:
Écrivez un secret qui ressemble à ceci:
Maintenant, créez le secret en utilisant kubectl apply:
Pour certains scénarios, vous pouvez utiliser le champ stringData à la place. Ce champ vous permet de mettre une chaîne non codée en base64 directement dans le secret, et la chaîne sera codée pour vous lorsque le secret sera créé ou mis à jour.
Un exemple pratique de cela pourrait être le suivant: vous déployez une application qui utilise un secret pour stocker un fichier de configuration. Vous souhaitez remplir des parties de ce fichier de configuration pendant votre processus de déploiement.
Si votre application utilise le fichier de configuration suivant:
Vous pouvez stocker cela dans un secret en utilisant ce qui suit:
Votre outil de déploiement pourrait alors remplacer les variables de modèle {{username}} et {{password}} avant d'exécuter kubectl apply.
stringData est un champ de commodité en écriture seule. Il n'est jamais affiché lors de la récupération des secrets. Par exemple, si vous exécutez la commande suivante:
La sortie sera similaire à:
Si un champ est spécifié à la fois dans data et stringData, la valeur de stringData est utilisée. Par exemple, la définition de secret suivante:
Donnera le secret suivant:
Où YWRtaW5pc3RyYXRldXI= décode en administrateur.
Les clés de data et stringData doivent être composées de caractères alphanumériques, '-', '_' ou '.'.
Encoding Note: Les valeurs JSON et YAML sérialisées des données secrètes sont codées sous forme de chaînes base64. Les sauts de ligne ne sont pas valides dans ces chaînes et doivent être omis. Lors de l'utilisation de l'utilitaire base64 sur Darwin / macOS, les utilisateurs doivent éviter d'utiliser l'option -b pour diviser les longues lignes. Inversement, les utilisateurs Linux devraient ajouter l'option -w 0 aux commandes base64 ou le pipeline base64 | tr -d '\ n' si l'option -w n'est pas disponible.
Kubectl prend en charge la gestion des objets à l'aide de Kustomize depuis 1.14. Avec cette nouvelle fonctionnalité, vous pouvez également créer un secret à partir de générateurs, puis l'appliquer pour créer l'objet sur l'Apiserver. Les générateurs doivent être spécifiés dans un kustomization.yaml à l'intérieur d'un répertoire.
Par exemple, pour générer un secret à partir des fichiers ./username.txt et ./password.txt
Appliquez le répertoire de personnalisation pour créer l'objet secret.
Vous pouvez vérifier que le secret a été créé comme ceci:
Par exemple, pour générer un secret à partir des littéraux username=admin et password=secret, vous pouvez spécifier le générateur de secret dans kustomizat