【ITニュース解説】ConfigMaps and Secrets: Managing Configuration in Kubernetes

アプリケーションを開発し、それをインターネット上に公開する基盤としてKubernetesのようなコンテナ管理システムを使う際、設定データをどう扱うかは重要な課題である。データベース接続情報やAPIキー、あるいは開発環境、ステージング環境、本番環境といった異なる環境でアプリケーションの挙動を変えるための設定などを、どこに、どのように配置するかは、システムエンジニアを目指す初心者が最初に直面する疑問の一つである。Kubernetesは、この設定管理の課題を解決するため「ConfigMaps（コンフィグマップ）」と「Secrets（シークレット）」という二つの仕組みを提供する。これらを活用することで、アプリケーションのコードから設定情報を切り離し、より安全で柔軟、そして管理しやすいシステムを構築できる。

まず、設定情報をアプリケーションのソースコードの中に直接書き込んでしまう「ハードコード」の問題点を見ていこう。パスワードやAPIキーのような機密情報がコードに埋め込まれていると、もしコードが第三者の手に渡った場合、情報が丸ごと流出するセキュリティリスクが高まる。また、開発、ステージング、本番といった異なる環境ごとに設定が違う場合、コードを修正し、アプリケーション全体を再構築し直す手間が発生し、環境変更への柔軟性が失われる。機密情報がGitのようなバージョン管理システムのリポジトリやDockerイメージの中に含まれてしまうリスクもあり、設定を変更するたびに再構築・デプロイが必要になるため、運用が複雑になる。

これらの問題を解決するため、Kubernetesではアプリケーションのコードと設定情報を分離する考え方を取る。そのための主要なリソースがConfigMapsとSecretsである。ConfigMapsは、機密情報ではない一般的な設定データ（例えば、データベースのホスト名、ポート番号、ログレベル、デバッグモードのオンオフなど）を保存するために使われる。一方、Secretsは、パスワード、APIキー、認証トークン、TLS証明書のような機密性の高い情報を安全に扱うために設計されている。どちらもアプリケーションのPod（Kubernetesで動く最小のデプロイ単位）に設定情報を提供する共通の目的を持つ。

ConfigMapは、キーと値のペアとして設定データを保存するKubernetesのAPIオブジェクトである。これはプログラミング言語でいう辞書やハッシュマップのようなものだと考えると良い。アプリケーションは、実行時にこのConfigMapを参照して必要な設定値を取得する。ConfigMapを作成する方法はいくつかある。kubectl create configmapコマンドを使って、コマンドライン上で直接キーと値を指定したり、設定ファイルをあらかじめ用意しておき、そのファイルを読み込んでConfigMapを作成したりできる。そして最も推奨されるのは、YAML形式のマニフェストファイルでConfigMapを定義し、kubectl apply -fコマンドで適用する方法である。作成されたConfigMapをアプリケーション内で利用する方法も主に三つある。一つは、設定値をPodの環境変数として渡す方法である。Deployment（複数のPodを管理するKubernetesオブジェクト）のYAMLファイル内で、ConfigMapから特定のキーの値を環境変数として読み込むように設定したり、ConfigMap内のすべてのキーと値をまとめて環境変数として読み込むように指定したりできる。アプリケーションコードでは、process.env.設定名のように環境変数を参照するだけで設定値を取得できるため、非常にシンプルである。二つ目の方法は、ConfigMapをPodのボリュームとしてマウントする方法である。この場合、ConfigMapの各キーと値は、コンテナ内の特定のパスにファイルとして配置され、アプリケーションはこれらのファイルを読み込むことで設定値を取得する。三つ目は、コマンドライン引数として設定値をアプリケーションに渡す方法である。

次に、機密情報を扱うためのSecretsについて説明する。SecretはConfigMapと似ているが、その目的と扱われ方において重要な違いがある。Secretは機密データを扱うため、ConfigMapよりも強力なセキュリティ機能が備わっている。Secretに保存されるデータは、Kubernetes内部ではBase64という形式でエンコードされている。これは直接人間が読めないようにすることで、誤って内容が露出するのを防ぐ。さらに、Kubernetesクラスターのetcdという基盤データベースに保存される際、暗号化が有効になっていれば暗号化された状態で保存され、必要なPodが稼働するノード上でもディスクには書き込まれず、メモリ（tmpfsという一時的なファイルシステム）に一時的に保存されるだけである。アクセス権についても、RBAC（Role-Based Access Control）という仕組みを使って、どのユーザーやPodがどのSecretにアクセスできるかを細かく制御できる。Secretの作成方法もConfigMapと似ており、kubectl create secret genericコマンドを使ったり、YAMLマニフェストファイルで定義したりできる。YAMLマニフェストでSecretを定義する場合、dataフィールドに値を記述する際はBase64エンコードされた文字列を指定する必要があるが、stringDataフィールドを使えばBase64エンコードを意識することなく直接平文の文字列を記述できるため、マニフェストの可読性が高い。アプリケーションでのSecretの利用方法も、ConfigMapと同様に環境変数として、またはボリュームとしてマウントする形が一般的である。

ConfigMapsとSecretsを組み合わせて実際のアプリケーションで利用する例を見てみよう。Node.jsアプリケーションがMySQLデータベースに接続する場合を考える。データベースのホスト名やログレベルといった機密性の低い設定はConfigMapに、データベースのユーザー名やパスワード、APIキーといった機密性の高い設定はSecretに定義する。これらをKubernetesクラスターに適用した後、アプリケーションをデプロイするDeploymentのYAMLファイル内で、ConfigMapとSecretの両方から設定値を環境変数としてPodに読み込ませる。これにより、アプリケーションコードは環境変数を読み込むだけで必要な設定情報を安全に取得でき、コード自体はどの環境でも変更せずに再利用可能となり、設定値だけを環境に応じて変更できるため、デプロイや管理が非常に柔軟になる。

さらに高度な利用パターンとセキュリティに関するベストプラクティスも理解しておくべきだ。例えば、開発、ステージング、本番といった環境ごとに異なる設定を持たせる場合、それぞれの環境向けに個別のConfigMapやSecretを作成し、デプロイ時に適切なものを適用する。また、アプリケーション内で取得した設定値が正しい形式であるか、必須の項目がすべて揃っているかなどを検証する「設定のバリデーション」を実装することも重要で、これにより不正な設定値が原因でアプリケーションが予期せぬ動作をするのを防ぐ。機密情報であるSecretは、定期的に内容を更新する「Secretローテーション」が推奨される。この際、一時的に古いSecretと新しいSecretの両方をアプリケーションが受け入れる期間を設けるなど、サービスへの影響を最小限に抑えるための工夫が必要になることもある。セキュリティの観点からは、「最小権限の原則」に従い、Podには実際に必要なConfigMapやSecretへのアクセス権のみを与えるべきである。KubernetesのRBAC機能を使ってこれを実現できる。また、アプリケーションのログには、パスワードやAPIキーのような機密情報を絶対に出力してはならない。もしログに機密情報が出力されてしまうと、ログファイルが流出した際に情報が漏洩するリスクがあるため注意が必要である。

ConfigMapsやSecretsを使う上で遭遇しがちな問題とその解決策も押さえておこう。ConfigMapを更新したのに、Podで古い値しか見えないという場合がある。環境変数として設定値を読み込んでいる場合、環境変数はPodが起動する際に一度だけ設定されるため、ConfigMapを更新してもPodを再起動しない限り反映されない。kubectl rollout restart deployment/<デプロイメント名>コマンドでPodを再起動する必要がある。ボリュームマウントの場合、更新がPodに伝播するまでに最大で60秒程度のタイムラグが発生することがある。また、Secretの値がBase64エンコードされたままアプリケーションに渡されてしまうという問題が発生することもあるが、Kubernetesは環境変数やボリュームとして渡す際に自動的にデコードするため、アプリケーション側で手動でBase64デコードを行う必要はない。もしエンコードされた値が渡ってくる場合は、設定の読み込み方が間違っている可能性が高い。PodがConfigMapやSecretを読み取れない「Permission denied（権限拒否）」エラーが発生した場合は、Podが使用しているサービスアカウントと、そのサービスアカウントに付与されているRBACの権限設定を確認する必要がある。

ConfigMapsとSecretsはそれぞれ1MBというサイズ制限があるため、非常に大きな設定ファイルを扱う場合は、初期化コンテナ（Init Container）を使って設定ファイルを外部から取得したり、専用の外部設定管理サービスを利用したりするなどの別の方法を検討する必要がある。また、更新がPodに伝播する速度も考慮する必要があり、環境変数はPodの再起動が必要だが、ボリュームマウントは時間がかかる。アプリケーションの要件に応じて、適切な設定値の取得方法を選択することが重要である。

結論として、ConfigMapsとSecretsは、Kubernetesで動くアプリケーションの設定を管理するための強力な基盤である。これらを適切に利用することで、アプリケーションのコードと設定を明確に分離し、セキュリティを強化し、異なる環境で同じコンテナイメージを柔軟に利用できるようになり、運用を大幅に簡素化できる。システムエンジニアを目指す初心者にとっては、ConfigMapsを非機密データに、Secretsを機密データに使うという基本的な使い分けを理解し、環境変数やボリュームとして設定値をPodに渡す方法を習得することが重要である。さらに、RBACを使った適切なアクセス制御や、機密情報をログに出力しないといったセキュリティ上のベストプラクティスを常に意識しながら、より堅牢なシステム構築を目指すことが推奨される。Kubernetesにおける設定管理の知識を深めることは、保守性、セキュリティ、拡張性に優れたアプリケーションを開発するために不可欠なスキルとなるだろう。