Kubernetes の ConfigMap とシークレット__HTMLTAG_1___
実稼働環境では、アプリケーションはコンテナー イメージに設定をハードコーディングするのではなく、外部環境から設定を読み取る必要があります。 Kubernetes は、一般的な構成データ用の ConfigMap と機密データ用の Secret という 2 つの特殊なメカニズムを提供します。このレッスンでは、保存時の暗号化と外部機密管理システムとの統合など、両方について詳しく説明します。
ConfigMaps: 構成データの管理
ConfigMap とは何ですか?
ConfigMap は、キーと値の構成データを保存する Kubernetes オブジェクトです。このデータはコンテナー イメージから完全に分離されているため、イメージを再構築せずに構成を変更できます。 ConfigMap には、単純な文字列、複数行の構成ファイル、さらにはファイルの内容全体を含めることができます。
ConfigMap の一致:
- アプリケーション環境変数 (データベース ホスト、ポート、機能フラグ)
- 設定ファイルの内容 (nginx.conf、application.properties)
- コンテナのコマンドライン引数__HTMLTAG_23___
- その他の機密性の低い構成__HTMLTAG_25___
リテラル値から ConfigMap を作成
コードブロック_0
ファイルから ConfigMap を作成
コードブロック_1
ConfigMap YAML 定義
コードブロック_2
Pod で ConfigMap を使用する方法
1. ConfigMap
からの環境変数コードブロック_3
2. ConfigMap からのボリューム マウント
コードブロック_4
3. ConfigMap
からのコマンドライン引数コードブロック_5
秘密: 機密データの管理
シークレットとは何ですか?Base64 が暗号化されないのはなぜですか?
Kubernetes の Secret には、パスワード、トークン、TLS 証明書などの機密データが保存されます。理解しておくべき重要な点が 1 つあります。シークレットは、デフォルトでは Base64 でのみエンコードされ、エンコードされていません。 Base64 は、テキスト チャネル経由でバイナリ データを送信するためのエンコードにすぎません。誰でも簡単にデコードできます。
コードブロック_6
これは、etcd または Kubernetes API 経由でシークレットを読み取る権限を持つ人は誰でも実際の値を確認できることを意味します。したがって、追加のセキュリティ層が必要になります。これについては後で説明します。
シークレット タイプ_
1.不透明 (汎用) シークレット
コードブロック_7
コードブロック_8
2. TLS シークレット
コードブロック_9
コードブロック_10
3. Docker レジストリ シークレット
コードブロック_11
コードブロック_12
ポッドでのシークレットの使用
シークレットを環境変数としてマウント__HTMLTAG_62___
コードブロック_13
_シークレットをボリュームとしてマウント
コードブロック_14
不変の ConfigMap とシークレット
なぜ不変なのか
数千の Pod を含む大規模なクラスターでは、ConfigMap/Secret が変更されるたびに、すべての kubelet に対する監視イベントがトリガーされます。これにより、kube-apiserver に大きな負荷がかかります。 Kubernetes 1.21 以降は、__HTMLTAG_70___不変の ConfigMap と Secrets をサポートしています。これは、実稼働クラスターにとって重要な最適化です。
不変の利点:
- kube-apiserver のオフロード: kubelet の変更を監視する必要はありません
- 安定性の向上: アプリケーションを破壊する可能性のある偶発的な更新を防止
- 多数のポッドによるパフォーマンスの大幅な向上__HTMLTAG_81___
コードブロック_15
コードブロック_16
コードブロック_17
保存時の秘密暗号化
デフォルトのストレージの問題
_デフォルトでは、シークレットは Base64 プレーン テキストとして etcd に保存されます。 etcd または etcd のバックアップを読み取る権限を持つユーザーはすべて、すべてのシークレット値を表示できます。これは運用環境では重大なセキュリティ リスクです。
暗号化構成
Kubernetes は、__HTMLTAG_92___EncryptionConfiguration を通じて保存時の暗号化をサポートします。これは、etcd に保存する前にリソースを暗号化する方法を指定する kube-apiserver の構成ファイルです。
コードブロック_18
コードブロック_19
外部シークレット演算子
外部シークレット オペレーターが必要な理由
保存時の暗号化により etcd のシークレットが保護されますが、問題はまだあります。シークレットは引き続き Kubernetes で管理されます。エンタープライズ環境では、シークレットは AWS Secrets Manager、HashiCorp Vault、GCP Secret Manager、Azure Key Vault で集中管理されることがよくあります。 外部シークレット オペレーター (ESO) は、外部システムから Kubernetes シークレットにシークレットを自動的に同期することで、この問題を解決します。
設定外部シークレット演算子
コードブロック_20
SecretStore および ClusterSecretStore CRD
ESO は、__HTMLTAG_108___SecretStore (名前空間スコープ) と ClusterSecretStore (クラスター全体) の 2 つの主要なタイプの CRD を使用します。ここで、外部シークレット バックエンドへの接続を構成します。
AWS Secrets Manager の ClusterSecretStore__HTMLTAG_114___
コードブロック_21
コードブロック_22
AWS Secrets Manager から同期する外部シークレット
コードブロック_23
すべての AWS シークレットを同期
コードブロック_24
HashiCorp Vault のシークレットストア
コードブロック_25
コードブロック_26
コードブロック_27
ConfigMap とシークレットのベスト プラクティス__HTMLTAG_122___
1.シークレットを Git
にコミットしないでくださいコードブロック_28
2.シークレット用の RBAC
コードブロック_29
3.シークレットローテーション
コードブロック_30
4.シークレット名前空間の分離
コードブロック_31
5.シークレット アクセスの監査ログ
コードブロック_32
概要
ConfigMaps と Secret は、Kubernetes の構成管理の基盤です。覚えておくべき重要な点:
- _ConfigMap (機密性のない構成用)、環境変数、ボリューム マウント、およびコマンド引数をサポート
- Secret デフォルトのみ Base64 エンコード — 暗号化ではなく、追加のセキュリティ層が必要
- 不変 ConfigMaps/Secret により、大規模クラスターのパフォーマンスが大幅に向上
- EncryptionConfiguration AES-GCM/AES-CBC を使用して、etcd に保存されているシークレットを暗号化します
- External Secrets Operator は本番環境に最適なソリューションです: Vault からの同期、AWS Secrets Manager、攻撃対象領域の削減__HTMLTAG_157___
- RBAC を常に厳密に適用し、シークレットを Git にコミットせず、ローテーション計画を立てます