本文へスキップ
BecomeCoder

Kubernetesコース · 第5章 設定とストレージ ― 状態をどう持つか · レッスン25

Secret ― パスワードやトークンを扱う

ブラウザで完結

導入

DB のパスワード、外部サービスの API キー、認証トークン――漏れたら困る機密情報も、アプリには渡さないといけません。これを ConfigMap に平文で書くのは危険です。機密専用の入れ物として用意されているのが Secret(シークレット) です。

説明

Secret は、形は ConfigMap とよく似ていますが「機密を扱う」ことを明示するための別種のリソースです。値は base64(ベース64、バイナリを文字列に変換する方式) でエンコードして記述します。

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  # "s3cr3t" を base64エンコードした文字列
  DB_PASSWORD: czNjcjN0

Pod への渡し方も ConfigMap と同様です。

    env:
      - name: DB_PASSWORD
        valueFrom:
          secretKeyRef:
            name: db-secret
            key: DB_PASSWORD

ここで正直に注意しておきます。base64 は暗号化ではありません。ただの文字変換なので、値を知っている人はすぐ元に戻せます。つまり Secret は「それ自体で安全」なのではなく、次のような仕組みと組み合わせて守るものです。

  • RBAC(アクセス制御) … 誰が Secret を読めるかを制限する(第6章で扱います)。
  • 保存時の暗号化(encryption at rest)クラスタが Secret をディスクに保存する際に暗号化する設定を有効にする。
  • Secret の中身を Git などに平文でコミットしない運用。
graph LR
    S["Secret<br/>(base64は変換のみ)"] --> RBAC["RBACで<br/>読める人を限定"]
    S --> ENC["保存時暗号化で<br/>ディスク上を保護"]
    RBAC --> Safe["実運用での機密保護"]
    ENC --> Safe

「ConfigMap は設定、Secret は機密」と用途で使い分けます。中身が機密なら、たとえ形が同じでも Secret を選ぶ――これが基本の作法です。

実際に動かしてみよう

上がマニフェスト(YAML)エディタ、下が kubectl の端末です。エディタの内容は `manifest.yaml` として保存され、下で `kubectl apply -f manifest.yaml` を実行するとクラスタに反映されます(pod.yaml / deploy.yaml / service.yaml も最初から置いてあります)。`kubectl get pods` / `describe` / `scale` / `rollout` などで結果を確かめましょう(本物のKubernetesではなく、動きを再現した軽量なシミュレータです)。各レッスンは毎回まっさらな状態から始まり、「最初からやり直す」で戻せます。

kubectl(シミュレート)

マニフェスト(YAML)を書いて kubectl コマンドを試せる学習用クラスタを読み込みます(本物のKubernetesではなく、apply/get/describe/scale/rollout などの動きを再現した軽量な自作シミュレータです)。
スクロールして表示された時点でも自動で読み込まれます。