Kubernetes Secret とは？概要と作成・運用方法を解説

Kubernetes の Secret とは
Kubernetes Secret は安全か？
Kubernetes Secret の暗号化とその保護方法
Kubernetes Secret の操作方法
Secret Vault の使用方法

まとめ

Kubernetes 環境の安心安全なセキュリティを実現するためには、Secretの取り扱いにも注意しなくてはなりません。

Secretの管理が不適切だと、クラスターやワークロードで侵害が発生し、重大なリスクを招く恐れがあります。
この記事では、Kubernetes Secretを使用するために知っておきたい基本として、Secretの概要、暗号化や操作の方法などを詳しく解説します。

関連記事

Kubernetesとは？	Kubernetesセキュリティの基礎	Kubernetesアーキテクチャの設計方法
AWSのEKS （Elastic Kubernetes Service）	Kubernetesのクラスターとは？	Kubernetes のノードとは？
KubernetesのPodとは？	KubernetesのHelmとは？	クラウドセキュリティとランタイムインサイト

Kubernetes の Secret とは

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

なお、Secret は Kubernetes に固有のものではなく、ほぼすべてのアプリケーション環境やプラットフォームで使用されています。

ですが、Kubernetes の Secret は、クラウドネイティブ環境での安全管理を想定し設計されたリソースであり、他の環境にない特徴が見られます。そのひとつが内蔵された操作ツールで、Podとの依存関係がない形で機密データを保存し、参照の必要があるときはPodにアクセスできるなど、安全な管理に役立つものです。

Kubernetes Secret は安全か？

適切に管理されてさえすれば Kubernetes Secret は、きわめて安全です。これが Secret の存在意義でもあり、Kubernetes 内で実行されるアプリケーションが必要とするパスワードやアクセスキー等の機密情報を安全に管理します。

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

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

Kubernetes Secret の暗号化とその保護方法

Kubernetes Secretの適切に管理し、安全性を高めるには、暗号化が必須です。

デフォルト状態では、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 を見ることができるだけで、実際のデータを見ることはできません。対して、承認された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」も使用できます。Kubernetes Secretデータ（場合によっては他のシステムのSecretも含む）を保存するサードパーティツールで、必要に応じて Pod から利用できます。

活用できる場面として、主に次があります。

etcd に Secret を保存しない時: etcd は、クラスターの管理に必要なあらゆるデータを格納する汎用のキーバリューストアです。Secretデータを効果的に保存できますが、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 を Kubernetes にデプロイします。通常、これは Helm チャートを使用して実行できます。
Kubernetes クラスターを Secret Vault に接続します。
必要に応じて、構成をカスタマイズします。

PKubernetes をサポートする Vault としては、HashiCorp Vault や CyberArk Conjur があります。

まとめ

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

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