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

SHARE:

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 の設定方法は、選んだツールによって異なりますが、一般的には次のような手順です。

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

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

まとめ

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


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