Kubernetes の Secret を作成および使用する方法

Kubernetes 環境を常時保護したい場合には、Kubernetes Secret を安全な方法で操作する必要があります。Secret を不適切に管理すると、クラスターとワークロードの一方または両方で侵害が発生する可能性があります。

Secret データを暗号化する方法、Secret を作成および表示する方法、サードパーティの Vault をどういうときに使用するのが妥当かなど、この記事を読んでいくと、Kubernetes Secret の管理に関するヒントが得られます。

Kubernetes の Secret とは

Kubernetes の Secret は、パスワードやアクセスキーなど、Kubernetes 環境内で使用される機密情報です。

もちろん、Secret は Kubernetes に固有のものではありません。シークレットデータは、ほぼすべてのタイプの新しいアプリケーション環境やプラットフォームで使用されています。

ただし、Kubernetes の Secret の特徴は、管理者が Secret を安全な方法で操作するのに役立つツーリングがいくつか内蔵されていることです。このツーリングを使用することで、Pod との依存関係がない形で機密データを保存し、参照する必要があるときは Pod にアクセスできます。

Kubernetes Secret は安全ですか？

適切に管理されている Kubernetes Secret は、きわめて安全です。これが Secret の何よりの本質です。Kubernetes 内で実行されるアプリケーションが必要とするパスワードやアクセスキーなどの機密情報を安全に管理する手段を提供することです。

Kubernetes Secret の管理機能がなければ、多くのケースで、パスワードなどのデータを Pod の仕様やコンテナイメージにハードコーディングする必要があります。そのようにした場合、それらのデータを読み取ることができる人（またはネットワークを転送中のデータを傍受できる人）であれば、誰でも機密情報にアクセスできるため、安全性がきわめて低くなります。

Secret の管理機能は、不正にアクセスされる危険がない Kubernetes のキーバリューストアに Secret を保存できるようにすることで、この問題に対処しています。

Kubernetes Secret を暗号化して保護する方法

前述のとおり、Kubernetes Secret は、適切に管理されていれば安全です。キーワードは「適切に管理されている」です。Kubernetes 内でシークレットデータを適切に管理するには、いくつかの追加ステップが必要です。

デフォルトでは、Secret は特に安全というわけではありません。etcd 内に保存されることによって、Pod の仕様またはコンテナイメージにハードコーディングするより若干安全になります。一般的に、Pod またはコンテナイメージにアクセスする人よりも、etcd にアクセスする人またはマシンが少ないためです。

ただし、デフォルトでは、etcd に保存される Secret は暗号化されず、ロールベースアクセス制御で保護されません。したがって、etcd にアクセスする人（一般的には、Kubernetes クラスター API とやり取りできる人またはマシンエンティティを意味する）であれば、誰でも機密 Secret を簡単に見ることができます。つまり、Kubernetes マスターノードにオペレーティングシステムレベルでアクセスできる人であれば、潜在的に見ることができます。etcd はそれらのノード上で実行されるためです。

このリスクから保護するには、etcd の Secret を暗号化し、RBAC ルールを適用するという 2 つの重要なステップが必要になります。

Kubernetes Secret の暗号化

Secret を暗号化すると、Kubernetes は Secret をエンコードされた形で etcd に保存し、鍵を使ってデータを Pod から利用できるようにします。そのため、etcd にアクセスできる人は、暗号化された Secret を見ることができるだけで、実際のデータを見ることができなくなります。一方、Secret を見ることを承認した Pod からは、Secret データを利用できます。

このタイプの設定を適用するには、エンコードされた Secret と対応のアクセスキーが含まれる、暗号化構成ファイルを作成します。例:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: dGhpcyBpcyBwYXNzd29yZA==
      - identity: {}

暗号化構成ファイルを作成したら、Kubernetes API サーバーを再起動します。これにより、Kubernetes 内で作成したすべての新しい Secret は、デフォルトで暗号化されます。

RBAC ルールによる Secret の保護

Kubernetes の RBAC フレームワークを使って、Secret を見ることができる人を最初に制限することで、Kubernetes Secret の保護を強化できます。これは Secret 暗号化に代わるものではありません。それも実施してください。しかし、RBAC 制限は、何らかの理由で Secret が暗号化されない場合でも、承認されないユーザーが見ることができないことを保証するのに役立ちます。

Secret へのアクセスを制限するには、Secret を見ることを許可するユーザーまたはマシン向けの Role または ClusterRole を作成します。例:

kubectl create clusterrole secretadmin \
          --verb=get --verb=list --verb=create --verb=update  \
          --resource=secret \
          --namespace=mysuperprojectCode language: PHP (php)

このコマンドによって、Secret を見ることができる、secretadmin と呼ばれるユーザー向け ClusterRole が作成されます。

次に、このルールを適用する RoleBinding または ClusterRoleBinding を作成します。例:

kubectl create clusterrolebinding canadminsecret \
          --role=secretadmin \
          --serviceaccount=mysuperproject:thepowerfulapp \
          --namespace=mysuperprojectCode language: PHP (php)

Kubernetes Secret の操作

Secret が暗号化されて、RBAC ルールで保護されているかどうかにかかわらず、Secret を作成、表示、管理するためのコマンドはほとんど同じです。基本は次のようになります。

Kubernetes Secret の新規作成

新しい Secret を作成して etcd に保存するには、次のようなコマンドを使用します:

kubectl create secret generic secret-name

これにより、「Opaque」型と呼ばれる Secret（汎用のユーザー定義 Secret）が作成されます。サービスアカウント用トークンなど、他のタイプの特別な Secret も定義されます。

また、YAML を使用して Secret を宣言できます。例:

apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm

Kubernetes Secret の表示

既存の Secret を表示するには、以下のコマンドを使用します:

kubectl get secret secret-nameCode language: JavaScript (javascript)

kubectl は、base64 エンコード形式で Secret を出力します。この Secret を完全にデコードするには、外部の base64 デコーダー（Linux ユーティリティ base64 など）で、次のようなコマンドを使用する必要があります:

echo $encoded_secret | base64 -dCode language: PHP (php)

Secret を見ることができる人に関する RBAC 制限を作成した場合は、必要なアクセス権を持つユーザーのみがこの方法で Secret にアクセスできます。

Secret Vault の使用

etcd に Secret を保存する代わりに、Secret Vault と呼ばれるものを使用できます。Secret Vault は、Kubernetes Secret データ（場合によっては他のシステムの Secret も含む）を保存するサードパーティツールで、必要に応じて Pod から利用できます。

Secret Vault を使用するのは、主に次の場合です:

• etcd に Secret を保存しない:  etcd は Secret データを効果的に保存できますが、そのように設計されているものは etcd だけではなく、etcd をまず使用する必要もありません。etcd は、クラスターの管理に必要なあらゆるデータを格納する汎用のキーバリューストアです。したがって、Secret Vault を使うことで、Secret と他の関連性のないデータを分離できます。
• Secret をデフォルトで安全に保存する:  ほとんどの Secret Vault は、デフォルトで強力なセキュリティ制御付きで構成されています。etcd では前述のとおり、そのように指示するまでデータが暗号化されません。
• Secret 管理を一元化する:  ほとんどの Secret Vault は、Kubernetes Secret だけでなく、他のさまざまな環境の Secret を管理できます。また、Kubernetes をサポートする Vault のほとんどは、単一の Vault インスタンスを使用して複数のクラスターの Secret を管理できます。そのため、外部 Secret Vault を使用して、IT 環境全体の Secret 管理を一元化し、それらをすべて一貫した方法で管理できます。

比較的小規模な Kubernetes 環境の場合は、Secret Vault では過剰かもしれません。しかし、数百の Secret を管理する必要がある大規模な環境の場合は、Secret Vault を使うことで、通常は etcd と比べて効率性と安全性を高めることができます。

Kubernetes への Secret Vault のインストール

Secret Vault の設定プロセスは、選択した Secret Vault によって異なります。しかし、ほとんどの場合、主なステップは次のようになります:

1. Secret Vault を Kubernetes にデプロイします。通常、これは Helm チャートを使用して実行できます。
2. Kubernetes クラスターを Secret Vault に接続します。
3. 必要に応じて、構成をカスタマイズします。

PKubernetes をサポートする Vault として一般的なものには、HashiCorp Vault や CyberArk Conjur があります。

まとめ

Kubernetes は、etcd を使用して Secret を安全に管理するための、相対的に堅牢な機能を提供します。ただし、etcd のみで Secret を管理する場合は、大きなセキュリティ上の欠陥が生じないように、暗号化や RBAC 制御を必ず有効する必要があります。

大規模または複雑な Kubernetes Secret 管理が必要な場合は、etcd より安全性と効率性に優れたサードパーティの Secret Vault の使用を検討しましょう。