91 votes

Kubernetes Secrets vs ConfigMaps

J'ai utilisé les secrets de Kubernetes jusqu'à présent. Maintenant, nous avons aussi des ConfigMaps.

Quelle est la meilleure solution : secrets ou cartes de configuration ?

P.S. Après quelques itérations, nous nous sommes stabilisés sur la règle suivante :

  • les configMaps sont par domaine de solution (peuvent être partagées entre microservices au sein du domaine, mais sont en fin de compte des entrées de configuration à usage unique)

  • les secrets sont partagés entre les domaines de la solution et représentent généralement des systèmes ou des bases de données de tiers

179voto

Paul Morie Points 6956

Je suis l'auteur de ces deux articles. L'idée est que vous devriez :

  1. Utilisation Secrets pour les choses qui sont en fait secrètes comme les clés API, les informations d'identification, etc.
  2. Utilisation ConfigMaps pour les données de configuration non secrètes

À l'avenir, il y aura probablement des éléments différenciateurs pour les secrets, comme la rotation ou la prise en charge de l'API secrète avec des HSM, etc. En général, nous aimons les API basées sur l'intention, et l'intention est définitivement différente pour les données secrètes par rapport aux configurations ordinaires.

J'espère que cela vous aidera.

8 votes

Une question qui, je l'espère, sera clarifiée. Car il semble que les secrets soient toujours stockés en texte brut (base64), donc la dénomination peut être un peu trompeuse pour l'instant si vous voulez mon avis. Ou pourriez-vous nous en dire plus à ce sujet ? Je suis d'accord pour dire que l'API basée sur l'intention est la voie à suivre.

28 votes

Est-il possible d'utiliser un secret à l'intérieur d'une carte de configuration ? Il est fréquent qu'un fichier de configuration d'application contienne à la fois des données secrètes et non secrètes. Par exemple, le fichier tomcat server.xml contient à la fois les numéros de port (non secret) et le mot de passe d'arrêt (secret)... Il serait intéressant de représenter cela sous la forme d'une ressource unique...

1 votes

Chaque chaîne de connexion doit-elle avoir son propre secret, ou dois-je avoir quelque chose comme un secret "ConnectionStrings" qui les contient toutes ?

9voto

Michael Cole Points 351

Une différence notable dans la mise en œuvre est que kubectl apply -f :

  • Les ConfigMaps sont "inchangées" si les données n'ont pas changé.
  • Les secrets sont toujours "configurés" - même si le fichier n'a pas changé

-7voto

Mohsin Points 89

Les ConfigMaps et les Secrets stockent tous deux les données sous la forme d'une paire clé-valeur. La principale différence est la suivante, Les secrets stockent les données en base64 format entre-temps Les ConfigMaps stockent les données dans un texte brut .

Si vous possédez des données critiques telles que des clés, des mots de passe, des identifiants de comptes de service, des chaînes de connexion à une base de données, etc. Secrets plutôt que des Configs.

Si vous souhaitez configurer une application à l'aide de variables d'environnement que vous ne souhaitez pas garder secrètes, comme le thème de l'application, l'url de la plate-forme de base, etc. ConfigMaps

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X