Kubernetes RBAC：CSRによる権限昇格を回避する方法 #aqua #セキュリティ #k8s #rbac
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは「Aqua Security」社の技術ブログで2022年4月6日に公開された「 Kubernetes RBAC: How to Avoid Privilege Escalation via Certificate Signing 」の日本語翻訳です。
Kubernetes RBAC：CSRによる権限昇格を回避する方法
前回の記事「Kubernetes RBACにおけるNode/Proxy権限からの権限昇格」に続き、今回は Kubernetes の CSR(Certificate Signing Request) API の権限を持つユーザが、それを使ってクラスター内で権限を昇格する可能性について見ていきます。注意すべき潜在的なセキュリティリスクを明らかにするとともに、この Kubernetes の機能がどのように機能するのかを説明します。
CSR API の紹介
Kubernetes は、kubelet と API サーバ間の通信など、いくつかの場所でクライアント証明書認証を使用しているため、新しい証明書を発行して署名する何らかの方法が必要です。そこで登場するのが CSR API です。
クライアント証明書認証を使用するためには、生成された証明書が信頼できる認証局によって署名されている必要があります。これは、あなたがアクセスするウェブサイトの証明書を見ると、ブラウザに組み込まれた認証局のいずれかによって署名されているのと同じことです。もし署名されていなければ、信頼できない旨の警告が表示されます。Kubernetes CSR API は、認証局のキーファイルに直接アクセスすることなく、署名が行われる仕組みを提供します。
基本的にこの API では、適切なロールベースアクセス制御(RBAC)権限を持つユーザが CSR を Kubernetes に送信し、そこで適切な権限を持つ別のユーザによって承認されるようにします。
この API にはいくつかの署名者がいて、さまざまな目的のために証明書に署名できます。kubernetes.io/kube-apiserver-client-kubelet のように、Kubernetes 内部のコンポーネントが使用する証明書を提供するものもあります。これらの署名者は、署名するリクエストの内容がかなり制限される傾向にあり、セキュリティの観点からはそれほど興味深いものではありません。
ここで特に注目したいのは、kubernetes.io/kube-apiserver-client という署名者です。これは、Kubernetes API サーバへの認証に使用される証明書へ署名でき、含めることができるものにほとんど制約がありません。
CSR APIを利用した権限昇格
では、CSR を作成し、証明書を承認する権限しか持たないユーザは、クラスター内でどのように権限を拡大するのでしょうか。攻撃者が最初に思いつくのは、system:masters グループで新しい証明書を作成することでしょう。これはハードコーディングされたクラスター管理者グループであり、その権限は取り消されないので、攻撃者にとって格好のターゲットです。
しかし、Kubernetes のデフォルトでは、このグループを使った証明書の発行はできないはずです。というのも、デフォルトのセットには CertificateSubjectRestriction という AdmissionController があり、その唯一の目的は、このユースケースをブロックすることだからです。
このようにブロックされた状態で、攻撃者が取ることのできる他の選択肢は何でしょうか。1つの良い方法は、クラスターですでに定義されているユーザ名を調べて、どれが高いレベルの権限を持つかを確認し、そのうちの1つに一致する新しい証明書を流用することです。Kubernetes には、あるユーザに対してどの特定の証明書が有効であるかを示す仕組みはありません。つまり、システムアカウント用の新しいクライアント証明書を作成し、それを使ってクラスターを認証しても、Kubernetes がそのシステムユーザの権限を与えるので、何の制約もありません。
クラスターにどのユーザとグループが存在するかは、使用しているディストリビューションに依存します。しかし、kubeadm クラスターでのセットアップを見ると、いくつかの可能性の高いターゲットが見えてきます。クラスター内のユーザの明確なリストを得ることはできませんが、この目的に必要な RBAC パーミッションをすでに定義しているユーザを確認できます。
このリストを見ると、system:kube-controller-manager がターゲットになりそうです。これは、クラスター運用の中核となる Kubernetes Controller Manager コンポーネントが使用するアカウントであり、それなりの権限を持っている可能性があります。このユーザに与えられた権限を見ると、secret リソースに与えられた権限を見ることができます。
クラスターレベルで secret を取得する権限を持つことは、その環境への攻撃成功に等しく、その権限を持つユーザが攻撃者に重要なのは明らかです。攻撃者がクラスター管理者レベルまでたどり着きたい場合、その権限を使用して clusterrole-aggregation-controller の ServiceAccountToken の secret を取得する方法があります。この特定の ServiceAccount は "escalate" 権限を持っており、これによって要求に応じて自身の権限を効果的に cluster-admin にまで引き上げることができます。
CSR APIの権限昇格の検出と緩和策
では、CSR API を介した権限昇格が可能であることを知った上で、それを検知し緩和する最善の方法は何でしょうか。
- Kubernetes の Audit はすべてのクラスターで有効にし、CSR API に関連するすべてのイベントを注意深く監視する必要があります。システムサービスによる利用があるレベルではありますが、予期せぬ証明書が作成されていることに気づくことができるはずです。注意点としては、攻撃者がシステムアカウントと同じ名前のクライアント証明書を作成できた場合、Kubernetes の Audit では認証元が記録されず、ユーザ名だけが記録されるため、あまり意味のない可能性があることです。
- この API に対する RBAC 特権は、クラスターのユーザと管理者の特権、およびクラスターにインストールされるソフトウェア(Operator など)に与えられる権限を含めて制限する必要があります。クラスター内の CSR オブジェクトへの特定のアクセス、または CSR オブジェクトへのアクセスを含む一般的なワイルドカードアクセスが要求された場合、それらの権限が悪用されるリスクを減らすために、要求を慎重にレビューする必要があります。
- もう1つの防御の層は、AdmissionController を使用することです。たとえば、CSR API へのアクセスが必要な場合、AdmissionController を使用して、io/kube-apiserver-client signer を使用するリクエストの停止、system:kube-controller-manager などのアカウントに対する証明書の発行のブロックが可能です。
まとめ
これも Kubernetes RBAC の複雑さと、Kubernetes クラスターにおける過剰な権限付与のリスクを示す一例と言えるでしょう。Kubernetes を環境の一部として使用している場合、権限を慎重に制御し、追加の検出および予防制御を導入して、Kubernetes API への不正アクセスによるリスクを管理することが重要です。
