設定と秘密の保存

Question

私はアプリケーション（複数のマイクロサービスで構成されています）をグラフにまとめる予定です。

現在、マイクロサービスごとに、deployment.yamlファイルに直接ハードコードされた秘密と設定値が格納されます（...containers[].env）。すべてのyamlファイルはgit repoに保存されています。

私はいくつかの人気のチャートがConfigMap（1、2）とSecret（1、2）がそれぞれ設定値と秘密を格納するオブジェクトをKubernetes使うことに気づきました。

はConfigMapとSecretオブジェクトを使用するのでは、それは人間工学および/またはセキュリティの向上も、いくつかの利点は何ですか？

私たちが持っているすべてのファイルyamlからテンプレートを作成して、ヘルムのテンプレートコンパイル時にすべてのハードコードされた値を設定可能にすることができます。 Kubernetesは、店舗構成に&秘密を、特殊なオブジェクトを提供するので

はしかし、私はdeployment.yamlファイルを既存からそれらへの参照を追加するだけでなく、configmap.yamlとsecrets.yamlテンプレートファイルを追加することを正当化したいです。

Answer 1

設定マップは非常に一般的な設定ファイルです。それらはキー値のペアのリストで構成できますが、汎用ファイルでもあります。たとえば、nginx設定ファイルnginx.confをconfigmapに保存し、nginxデーモンが読むための適切な場所にロードすることができます。

秘密は機密データを保存するために使用されるはずですが、残念ながら現在の秘密は暗号化されていません。したがって、暗号化されていないハードコードされた値をマニフェストから削除するのに役立ちますが、暗号化にはまったく役立ちません。 v1.7

secretsまたはconfigmapsの特定の値を指すように、展開マニフェストの環境変数を設定できます。どちらも簡単に例えばkubectlで生成されます。

• kubectl create secret generic foobar --from-literal=password=foobar
• kubectl create configmap foobar --from-file=foobar.conf

ヘルムチャートのベストプラクティスがmariadb chartを参照し、両方を使用することです。

個人的には、Podでファイルを読み込む必要があるときはconfigmapを使います。機密env変数を扱うときは、暗号化されていないことを覚えておいて秘密を使います。