Kubernetesにおける認証の改善：「system:masters」は避けましょう #aqua #コンテナ #セキュリティ #k8s

本ブログは「Aqua Security」社の技術ブログで2021年5月20日に公開された「 Improving Your Kubernetes Authorization: Don’t Use system:masters 」の日本語翻訳です。

Kubernetesにおける認証の改善：「system:masters」は避けましょう

---

Kubernetesクラスターを運用する際に重要なのは、認証モデルを適正にして、ユーザが役割を果たすために必要な最小限の権限を提供することです。そのため、cluster-admin 権限は決して使用すべきではなく、組み込みグループ system:masters の使用は特に避けるべきです。

system:mastersとは

ほとんどの Kubernetes ディストリビューションには、デフォルトでいくつかの ClusterRole と Role が含まれています。これらの Role は、システムのユーザに一般的なパーミッションのセットを提供し、コントローラや他のコントロールプレーンコンポーネントで使用されるパーミッションも提供します。

しかし、これらに加えて、Kubernetes で使用されるいくつかの組み込みグループがあります。最初の2つは比較的わかりやすいもので、system:unauthenticated は Kubernetes API に対する匿名の権限を提供するために使用され、system:authenticated はすべての認証済みユーザに権限を提供するために使用されます。

ここで、3つ目の組み込みグループである system:masters について説明しますが、これは少し異なる扱いになります。system:masters は、Kubernetes API サーバのソースコードにハードコードされているグループで、Kubernetes API サーバに対する無制限の権限を持っています。

なぜ system:masters の利用を避けるべきなのか

このグループのメンバーであるユーザは、クラスターに対する完全なクラスター管理者の権限を持ちます。すべての ClusterRole や Role がクラスターから削除されても、このグループのメンバーであるユーザはクラスターへの完全なアクセス権を保持します。

これらのクラスタのデフォルトユーザは system:masters のメンバーであるため、kind でこのアクセスを実演できます。(※破壊しても問題ないテスト環境以外では実行しないでください)まず、次のコマンドですべての ClusterRole を削除します。
kubectl delete clusterroles.rbac.authorization.k8s.io --all

そして、次のコマンドを使って、念のために kube-system ネームスペースのすべての Role を削除します。
kubectl -n kube-system delete roles --all

この時点では、クラスターに対する権限を与える RBAC オブジェクトはありませんが、権限を確認するためにコマンドを実行すると、クラスターに対する全ての権限が残っていることがわかります。
kubectl auth can-i --list

また、Kubernetes 内蔵の RBAC システムの代わりに、Webhook による認証を使用している場合でも、このグループのメンバーによるアクセス要求は Webhook に送信されないため、同じ状態となります。

system:masters のメンバーシップは、Kubernetes のクライアント証明書認証モデルと組み合わせた場合に特に危険です。というのも、Kubernetes は現在、クライアント証明書を失効させるメカニズムを提供していないからです。つまり、system:masters のグループ名で発行されたクライアント証明書ベースのクレデンシャルは、簡単には削除できない Kubernetes API へのフルアクセスを持つことになります。攻撃者がこのクレデンシャルにアクセスした場合、彼らは環境への長期にわたるクラスター管理者レベルのアクセス権を持つことになります。

system:mastersをどう取り扱うべきか

クラスターで取るべきアクションの最初のステップは、すべてのユーザをこのグループのメンバーにしないことです。誰かにクラスター管理者の権限を与える必要がある(これは慎重に使用すべきですが)場合、組み込みの cluster-admin ClusterRole に ClusterRoleBinding を作成できます。これは system:masters を使用するのと同じ効果がありますが、必要に応じて ClusterRoleBinding からユーザを削除することで、これらの権利を削除できます。

次に確認すべきポイントは、使用している Kubernetes ディストリビューションがどのように system:masters を利用しているかということです。多くのディストリビューションでは、クラスターのセットアップの一環として bootstrap ユーザが作成され、このグループのメンバーとなります。

例えば、kubeadm やそれをベースにしたディストリビューションでは、インストールの一環として admin.conf というファイルが作成されます。これは、クライアント証明書ベースのクレデンシャルで、system:masters グループに属しています。このファイルへのアクセスを慎重に制御することが非常に重要です。このファイルは、デフォルトの有効期間が1年の一般的なバックドアユーザであるためです。kubeadm のドキュメントに記載されているように、このファイルはフル権限が与えられているので、一般的なクラスター管理にて安易に使用してはいけません。

まとめ

---

Kubernetes の認証・認可モデルには、クラスターを設計・運用する際に理解しておくべきケースが数多くあります。クラスターへの不正アクセスのリスクを低減するためには、system:masters グループのメンバーとして作成されたものなど、高い権限の認証情報を慎重に管理することが重要です。