Configmapを使用してKubernetesに機密データを保存してはいけない理由 #aqua #セキュリティ #コンテナ #k8s

本ブログは「Aqua Security」社の技術ブログで2021年4月28日に公開された「 Why You Shouldn’t Use Config Maps to Store Sensitive Data in K8s 」の日本語翻訳です。

Configmapを使用してKubernetesに機密データを保存してはいけない理由

---

コンテナ化された環境を管理する上での課題の1つに、その環境で動作するアプリケーションの運用に必要な機密データをどのように保存するか、があります。Kubernetes には Secrets というオブジェクトタイプが組み込まれていますが、これについてよく言われるのは、技術的には ConfigMap などの他のオブジェクトタイプと変わらないということです。では、なぜ Secrets を特別に使う必要があるのでしょうか。

クラスタの作業者やディストリビューションプロバイダが、「ConfigMap を使って機密情報を保存したことがある」という言説を見たことがあります。

技術的なレベルで Secrets と ConfigMap の仕組みを見てみると、多くの類似点があります。どちらのオブジェクトタイプも Kubernetes API を介してアクセスされ、RBAC や他の認証システムを介してアクセスが制御され、データは最終的には etcd に保存されます。

ではなぜ、すべての設定情報をより汎用的なオブジェクトに配置するのではなく、専用の Secrets タイプを使用する必要があるのでしょうか。それは「データの意図を明確に示す」という事でしょう。これにより、この情報を慎重に扱うべきだということが、誰の目にも明らかになるからと言えるでしょう。

RBACによる情報へのアクセス制御

シークレットデータと一般的なアプリケーション構成データの主な違いは、その情報への読み取りアクセスを許可することがどれだけ安全かということです。一般的に、アプリケーション設定データへの読み取りアクセスは、クラスタのユーザや、クラスタのアプリケーション状態を監視または管理する内部システムへ提供するのに十分な安全性を備えている必要があります。

一方、機密データは広く共有すべきでありません。機密データへの読み取りアクセスはしばしば特権昇格攻撃を可能にするため、一般的には「知る必要がある」ベースで制限されるべきです。つまり、RBAC の要件は大きく異なります。

ConfigMap に機密データを配置すると問題が発生する良い例として、Kubernetes の一般的なクラスタロールを使用する場合が挙げられます。Kubernetes は「view」というクラスタロールを提供しており、ユーザはこれを使ってクラスタリソースへの読み取り専用のアクセスを提供できます。私の経験では、view clusterrole は、開発者やクラスタを操作する必要のある他のユーザにクラスタリソースへの読み取り専用のアクセスを提供する方法として比較的よく使用されています。

提供された権限を見ると、ConfigMap への読み取りアクセスは可能ですが、Secrets へのアクセスはできません。

これが、クラスタディストリビューションの開発者、アドオンの開発者、クラスタのユーザ等のいずれの場合であっても、機密データを Secrets としておくべき
最初の正当な理由です。機密データに不用意にアクセスするリスクを回避し、その情報を慎重に扱うべきだというあなたの意図が明確になります。

プラットフォームによる Secrets の取り扱い

機密データに Secrets を使用する2つ目の理由は、基盤プラットフォームに対してもデータの意図を伝えることです。ほとんどのシステムでは、診断ログやその他の形式の出力に機密データを不用意に含めず、必要以上に多くの人に見られることを避けるのが一般的な目標です。特に、多くの企業が外部の SaaS ベースのログ・監視システムを使用している場合、機密データが流出しないようにすることは重要です。

このアプローチに沿って、Kubernetes は一般的に機密データと認証情報のロギングを避けようとしています。シークレットデータのロギングを避けるための複数の KEP があります。例えば、シークレットデータのログ出力を防ぐために静的解析を使用したり、シークレットデータのロギングを避けるためにログのサニタイズを検討したりします。

ここで注意すべき重要な部分は、Kubernetes がこれらのリスクを軽減するための措置を取ることができるのは、機密データであるという意図を明確に示している場合に限られるということであり、ここでも意図が重要となります。

ConfigMap や他のオブジェクトタイプが機密データの保存に使用されている場合、Kubernetes はデータの機密性を理解し、それが適切に処理されているかどうかを確認する方法がありません。そのため、ConfigMap が使用された場合、その内容はログやダンプデータに入ってしまう可能性があります。

まとめ

---

クラスタの機密データ関わる優れたセキュリティを維持することは、クラスタ全体のセキュリティの重要な部分です。クラスタの運用者であれば、ここからいくつかの重要なポイントを知ることができます。

• 1つのオプションは、Kubernetes の機密データを保護するために外部システムを使用することです。機密データを扱うための多くの機能を備えている、既存のエンタープライズシークレットストアとの統合などです。
• 外部のシークレットシステムを使用していない場合は、すべての機密データが他のオブジェクトタイプではなく Kubernetes のSecrets オブジェクトを使用していることを確認してください。
• Kubernetes ディストリビューションとクラスタにインストールしたサポートソフトウェアが機密データをどのように扱うかを確認します。
• Kubernetes の Secrets を使用している場合は、Kubernetes オプションの Secrets オブジェクトの暗号化が有効になっていることを確認してください。これはデフォルトでは有効になっておらず、あなたの etcd データベースが侵害されたり公開されたりした場合にはリスクがあります。Kubernetes のサイトに機密データを暗号化する方法についての良いドキュメントがあります。