2022年におけるKubernetesのシークレットマネジメントの状況（前半）

Kubernetesのシークレットマネジメントに関する記事です。

長い記事なので、前半と後半の２つに分けて投稿いたします。今回は前半です。

シークレットはすでに現代のソフトウェア開発ライフサイクル (SDLC) の基本的な構成要素になっています。アプリケーション、CI/CD システム、API アクセス、データベースなど、すべて何らかの形でシークレット/トークン/認証情報を必要とします。シークレットは、SDLC のすべての段階に関与しています。そして、セキュリティ上の理由から、バージョン管理システムにシークレットを置くことはできません（SOPSのように、ソースコード管理システムを使用してシークレットを共有することを可能にするツールはありますが）。こういった理由から、シークレットを適切は適切に管理すべきなのです。

一方、Kubernetes (K8s) は、特にThe Twelve-Factor App methodology の方法論に従って、できる限りクラウドネイティブに近づきたいウという場合に、コンテナ化したワークロードを実行するデファクトの場となっています。

この記事では、シークレットとK8sについて深く掘り下げます。具体的には、K8sのシークレット管理について概要を説明します。

それでは、始めましょう。

1 K8sシークレットの活用と課題

1.1 K8sシークレットに関して～おさらい～

簡単におさらいすると、基本的にK8s環境においてPod内のコンテナがシークレットを消費する方法は、大きく分けて2つあります。

- データボリュームとしてマウントされる

- 環境変数として公開される

そして、Pod内では、ファイルを読み込んでシークレットの内容を読み込む方法（シークレットをデータボリュームとしてマウントする場合）と、環境変数として読み込む方法（シークレットをenv varsとして公開する場合）のいずれかを選択することができます。

1.2 ファイルからコンフィグ/シークレットを読み込む

ファイルから読み込む方法は、使いやすく、ローカル開発に有利かもしれません。ローカルでのテストに必要なすべてのシークレットを含むローカルファイルを準備し、アプリに特別な修正を加えることなくK8sで同じように動作するからです。

しかし、これは比較的古い方法で、おそらく古いアプリだけが最初にこの方法で書かれており、12ファクターアプリの方法論に反しています。