Kubernetes Secret管理のベストプラクティス
2022年11月16日
0 分で読めますKubernetesでは、OAuthトークン、Secure Shell（SSH）キー、パスワードなどの機密データを保存するために、Secretと呼ばれるSecretオブジェクトを使用します。Kubernetes SecretをPodとは別に作成することで、機密データをアプリケーションコードから分離できます。この分離と、適切に設定されたロールベースアクセス制御（RBAC）を組み合わせることで、Podとのやり取り中にSecretが露出し、悪用されるリスクを低減し、セキュリティを強化できます。
Kubernetes Secretは意図しないデータ漏えいの防止に役立ちますが、悪意のあるサイバー攻撃からクラスターのデータを保護できるとは限りません。たとえば、etcdクラスターへのアクセス権を持つ未承認のユーザーは、すべてのKubernetes Secretにアクセスできます。そのため、Kubernetes Secretの安全性を確保するには、慎重な管理が必要です。
この記事では、Kubernetes Secret管理のベストプラクティスを紹介します。セキュリティリスクとベストプラクティスについては、Kubernetesセキュリティの記事をご覧ください。
Kubernetes Secretの仕組み
Kubernetes Secretを使うと、ユーザーはSecretオブジェクトにデータを保存し、Kubernetesクライアントからアクセスしたり変更したりできます。Secretは、Secret IDと認証情報を含むキーと値のペアです。KubeletはSecret IDを使って、Podの作成時にアプリケーションコンテナへ提供する必要がある認証情報を特定します。
Kubeletはクラスター内の各ノードで動作し、Podとそのコンテナを管理します。Secretにアクセスできるのは、明示的にマウントされたボリュームの一部として指定されているPod、またはkubeletがPodで使用するイメージを取得する時点に限られます。
Kubernetes APIサーバーはKubernetes Secretを保存します。アクセスできるのは、Kubernetes APIサーバーへのアクセス権を持つ特定のユーザーだけです。Kubernetes APIサーバーはアプリケーションの単一障害点となるため、データを安全に保護する必要があります。
Kubernetes Secretには次のような用途があります。
kubeletとPodの間のように、コントローラーとワーカー間で構成データを安全に共有する
外部アプリケーションへのアクセスに必要な認証情報など、機密データをKubernetesクラスターに保存する別の方法を提供する
新しいデプロイや名前空間など、Kubernetesクラスター上にリソースを簡単に作成する
Kubernetes Secretのベストプラクティス
キー、パスワード、トークンなどのSecretやその他の構成値は、適切に保存する必要があります。Kubernetesクラスターが侵害された場合でも、Secretは安全でなければなりません。攻撃者がSecretを悪用して機密データを侵害したり、ボットネットを構築したり、コマンド＆コントロール（C2）サーバーを操作したりできないようにする必要があります。
Kubernetes Secretを安全に保つための方法をいくつか紹介します。
保存時の暗号化を有効にする
RBACルールを設定する
etcdデータを暗号化する
一元管理しやすいSecretストアを使用する
保存時の暗号化を有効にする
Kubernetes SecretのデータはBase64形式でエンコードされ、etcdにプレーンテキストで保存されます。etcdは、Kubernetesクラスターの状態や構成データを支えるキーバリューストアです。Secretがetcdにプレーンテキストで保存されていると、攻撃者に簡単に侵害され、システムへのアクセスに悪用されるおそれがあり、危険です。
etcdデータベースはデフォルトでは暗号化されていないため、攻撃者の手に機密情報が渡らないよう、Secretデータを保存時に暗号化する必要があります。ファイルシステムにアクセスできる攻撃者は、ファイルからSecretを読み取ることができます。
また、Kubernetesには保存時の暗号化機能があり、Kubernetes APIを使ってSecretを暗号化してからetcdに保存できます。KMSConfiguration、IdentityConfiguration、SecretboxConfiguration、AESConfigurationなどの暗号化プロバイダーを使用して、保存中のSecretを保護することもできます。
Kubernetesクラスターは複数のノードで構成され、各ノードは暗号化と復号に固有の認証情報を持ちます。EncryptionConfigurationオブジェクトでは、ノードごとの暗号化と復号に使用するキーマテリアルを指定します。暗号化プロバイダーの設定はEncryptionConfigurationオブジェクトに記述し、ローカルで管理するキーを使ってSecretをローカルに暗号化できます。
RBACルールを設定する
Kubernetes Secretを保存時に暗号化するだけでは、Secretを安全に保つために十分ではありません。KubernetesのRBACルールを使って、Secretへのアクセスも制御する必要があります。Secretへのアクセスを許可するセキュリティポリシーは、タスク、時間、またはロールに基づいて設定できます。
Kubernetes SecretとRBACルールは密接に連携します。Kubernetes Secretオブジェクトが存在する主な理由の一つは、ConfigMapとは異なるRBACアクセス権を付与できることです。
ClusterRolesオブジェクトを使ってクラスター内でユーザーが実行できる操作を定義し、Roleを使って名前空間内で実行できる操作を定義できます。RBACにより、Secretの作成、削除、変更を特定のユーザーのみに制限できます。たとえば、特定の名前空間では開発者がSecretを作成できないようにし、他の名前空間では許可するポリシーを設定できます。
Kubernetesに組み込まれたRBACフレームワークを使うと、最小権限の原則（PoLP）を適用し、ユーザーやプログラムのアクセスを、割り当てられたタスクの実行や正常な動作に必要なリソースや情報のみに制限できます。これにより、特権アカウントとコンテナだけがSecretにアクセスできるようになります。攻撃者がコンポーネントを侵害した場合も、PoLPによって権限の昇格や他のコンポーネントの侵害を防ぎやすくなります。
etcdデータを暗号化する
etcdクラスターへのアクセス権があればSecretにもアクセスできるため、自動的なキーのローテーション、キーの経過期間の把握、監査ログなど、機密データの保護には細心の注意が必要です。最善の方法は、このデータをetcdで利用できないようにすることです。etcdのデフォルトのストレージドライバーはローカルで、暗号化キーは構成ファイルにローカル保存されます。そのため、マルウェアなどの悪意ある脅威に対して脆弱になる可能性があります。
etcdデータのセキュリティを強化する方法の一つは、Secretを保存前に暗号化することです。キーとSecretの保存には、キー管理サービス（KMS）などの暗号化プロバイダーを使用しましょう。多くのマネージドKubernetesプロバイダーでは、クラスター作成時にetcdのSecretストレージがデフォルトで暗号化され、etcdデータの保護に役立ちます。
もう一つのセキュリティ対策は、APIサーバーだけがetcdにアクセスできるようにすることです。etcdクラスターの利用は、アクセスが必要なノードのみに許可します。Kubernetes APIサーバーを通じてetcdへのアクセスを許可し、特定のユーザーまたはグループだけに読み取りと書き込みの権限を付与できます。
一元管理しやすいSecretストアを使用する
Kubernetes Secretはアプリケーションの動作に不可欠であり、複数の場所に保存できます。Secretをさまざまな場所に保存すると、安全な管理が難しくなります。特に、複数のクラスターでSecretを管理する場合や、秘密鍵と公開鍵のペアが混在する場合は困難です。一元管理システムがなければ、Secretが各所に分散し、未承認ユーザーに対する攻撃対象領域が広がります。
Secretを一元管理すると、特に複数のインスタンスで使用する場合に多くのメリットがあります。一元管理ソリューションを使えば、Kubernetesのセキュリティ状況を統合的に把握できます。Secret、アクセス制御、監査を簡単に管理できるほか、中央監査証跡によって重要なセキュリティイベントを把握できます。
サードパーティープロバイダーは、Kubernetes Secret管理のための、より安全で高度な機能を提供しています。以下に、よく利用されるサードパーティー製Secret管理サービスを紹介します。
AWS Secrets Manager
AWS Secrets Managerは、Secretを安全かつ簡単に保存し、ローテーションする方法を提供します。Amazon Web Services（AWS）のすべてのリソースを一元管理できるコンソールを備えています。AWS Secrets ManagerはKubernetesと統合されているため、暗号化されたSecretをKubernetesに安全に保存できます。実行時にはKubernetes API経由でSecretにアクセスできるので、コード内での露出を心配する必要がありません。
このSecret管理サービスを使うと、AWSの認証情報やSecretを安全な一か所で取得、表示、管理できます。AWS Secrets Managerは、AWS Identity and Access Management（IAM）、AWS Key Management Service（AWS KMS）、AWS Simple Storage Service（S3）など、他のAWSサービスと併用できます。
Azure Key VaultとAzure Kubernetes Service
Microsoft Azure Key Vaultは、暗号化キーを保存して利用できるSecret管理サービスです。削除したVaultオブジェクトのバックアップと復元、Secretのログ記録と監視、Key Vaultを使ったユーザー認証が可能です。
さらに、Azure Kubernetes Service（AKS）では、Azure RBACとKubernetes RBACによる認可を利用できます。Azure RBACを使って、ロール割り当てを通じたリソースアクセスの制御も可能です。グループとユーザーを認可できるほか、Kubernetesに組み込まれたRBACではKubernetesサービスアカウントを使用できます。
HashiCorp Vault
HashiCorp Vaultは、Secretの保存と管理、機密データの保護に使えるオープンソースのSecret管理ツールです。機密データへのユーザーアクセスを管理し、セキュリティ上の脅威が発生した場合には、機密データをローテーションしたり、アクセス権を取り消したりできます。
HashiCorp Vaultを使うと、データの暗号化、IDベースのアクセス制御、Secret管理など、さまざまなKubernetesセキュリティ対策を実施できます。HashiCorp Vaultは、転送中と保存中のデータをそれぞれ保護するために、TSLとAES 256ビット暗号化を使用します。
まとめ
Secretはユーザーやサービスを認証し、リソースや他のSecretへのアクセスを制御します。Kubernetes Secretを使うと、Secretオブジェクトにデータを保存し、Kubernetesクライアントからアクセスしたり変更したりできます。Secretにはトークン、キー、パスワードなどの機密データが含まれるため、安全を保つベストプラクティスに従うことが不可欠です。
Secretを保護する方法はいくつかあります。まず、保存時の暗号化を有効にしましょう。保存時にSecretを暗号化すると、セキュリティが向上します。ただし、Kubernetes Secretオブジェクトを保存時に暗号化するだけでは、Secretを安全に保つには不十分です。RBACルールを使ってSecretへのアクセスも制御する必要があります。Kubernetesに組み込まれたRBACフレームワークを使えば、ユーザーやプログラムのアクセスを制限し、必要なリソースや情報だけを利用できるようにできます。また、前述のようなサードパーティー製Secret管理サービスを使うことも、Secretの保護に役立ちます。
Secretを適切に管理するには、開発者とKubernetesクラスター管理者の双方が機密情報のセキュリティを注意深く監視する必要があります。ここで紹介したベストプラクティスに加え、Secretを安全に保つために、開発者とクラスター管理者の両方を対象としたKubnernetesのSecret管理ガイドもぜひご確認ください。
認証情報などのSecretを安全に保つことは、より安全なアプリケーションを運用するための第一歩にすぎません。ソフトウェア開発ライフサイクルの各段階を安全にする必要があります。Snyk CodeとSnyk Open Sourceを活用して、作成したコードや利用するオープンソースプロジェクトに潜む脆弱性を特定し、対処しましょう。Snyk Containerを使えば、より安全なベースイメージから始め、ビルドプロセスで新たに持ち込まれる脆弱性も特定できます。最後に、Snyk IaCでデプロイするコードにセキュリティ上の欠陥が含まれていないことを確認しましょう。
関連記事：
ソースコードの段階からインフラを保護
Snykはワークフロー内のIaCセキュリティとコンプライアンスを自動化し、構成ドリフトや不足しているリソースを検出します。