スッキリ、繋げて、コンテナセキュリティを得意分野に！ #5 Kubernetes API と 認証認可＋α の話

1.Kubernetes API とその他のAPI、想定されるリスク

ユーザによるKubernetesの操作は、管理端末からkubectlコマンドにより、Kubernetes APIのリクエストを処理する形で行われます。
また、実際のKubernetes周りではその他のAPIも、いくつかドキュメントなどで散見されます。（公式のSecurity Checklistなどより）
ここでは、まず、以下３つのAPI について触れます。
・Kubernetes API：
Kubernetesクラスタ全般を操作する、主となるAPI（ドキュメントとして仕様公開）
・Kubelet API：
Kubernetes各ノードの主エージェントkubelet（後述）と直接やり取りするためのAPI（主に内部向け、ドキュメント非公開）
・クラウドインスタンスメタデータAPI：
クラウドインスタンス（ここではK8sノード）のメタデータを取得するAPI

それぞれ、インターネットからアクセス可能な状態にしない、アクセス元をフィルタ・制限することが推奨されています。（公式Security ChecklistのNetwork Security部分）
また、KubernetesのMaster／Nodesそれぞれの外部からのアクセスを制限することが対策になります。

今回は、KubernetesシステムのメインとなるKubernetes API について詳しく触れていきます。

2.Kubernetes API リクエスト処理の流れとユーザについて

Kubernetes API のリクエストはAPI Serverによって次のような流れで処理されます。
リクエスト発行　⇒　認証　⇒　認可　⇒　アドミッションコントロール　⇒　リクエスト実行

この流れの詳細は次章以降で見ていきます。ここでは、併せてKubernetesにおけるユーザについて見ていきます。
1章でも触れたように、Kubernetes APIを実行するのはユーザのみではありません。
Kubernetes APIリクエストに関わるユーザ関連の用語は以下の通りです。
・ユーザ
・サービスアカウント
・グループ

上記で、ユーザ、グループは、Kubernetesで管理対象ではないと記述している通り、Kubernetes上ではユーザリソース、グループリソースというものは存在していません。
次章以降で触れますが、Kubernetesの認証・認可は、それぞれモジュールとして選択式で利用することができます。
ユーザやグループは個々の認証モジュールによって管理されているため、Kubernetes本体では管理していない、というのが実体です。
Kubernetesの認証モジュールで、認証された後、ユーザ名やグループ名などの情報をKubernetes本体に連携して、それらの情報に基づいた認可～のフローに入っていくイメージです。
このあたりが少しややこしいポイントかと思います。

次章から、Kubernetesリクエスト処理の流れを詳しく見ていきます。

3.認証

認証では、リクエスト元のユーザやサービスアカウントの正当性を確認します。

認証モジュールに従い、ユーザやサービスアカウントを認証します。
ユーザの認証では、クライアント証明書や認証トークンを利用した認証、また、クラウドサービスにおけるIAM（ロールなど）と連携などがあります。
また、サービスアカウントの認証は証明書をベースとしたトークンなどをもとに実施します。
認証モジュールの一覧はKubernetesの公式ドキュメントで確認できます。

例えば、ユーザ認証のうちクライアント証明書を使用するケースでは、K8sが認証局となって発行したクライアント証明書をもとにユーザを認証します。

認証された場合、証明書の中のCN（Common Name）をKubernetesのユーザ名、O（Organizations）をKubernetesのグループ名として認証モジュールから返却されます。
また、サービスアカウントのトークンを利用したケースでは、サービスアカウントごとに発行されるトークンをもとに認証します。

各種クラウドサービスが提供するK8sサービスごとに認証・権限まわりの仕様は異なります。
そのため、それぞれのクラウドサービスのドキュメントを必ずご確認ください。（例：AWS：クラスター認証、サービスアカウントのIAMロール）

認証についての推奨としては、次のようなものがあります。
・アカウント情報を管理して奪取されないようにする（Kubernetes外部での管理）
・用途に応じてユーザやグループを分ける（ユーザの使い回しによる不要な権限付与に注意）
・認証トークンや証明書の期限などを設けて定期的に認証情報を更新する
・匿名リクエスト（他の認証方法で拒否されなかったリクエストが匿名リクエストとして扱われる）の機能を無効にする
・「system:masters」グループにユーザを割り当てない
など

4.認可

認可では、リクエストが認証された後、ユーザ／グループ／サービスアカウントが適切な操作権限を持っているかを評価します。

認可もモジュール式となっています。推奨されているRBACをここでは説明します。
RBAC（Role-Based Access Control）：
ロールベースのアクセス制御。ロールを対象に割り当てることで制御する。
他にも以下のような認可モジュールが標準で用意されていて、複数の認可モジュールを組み合わせて利用できます。
認可モジュールの一覧は、Kubernetesの公式ドキュメントで確認できます。

RBACは次の4つのリソースによって実装されます。
・Role：
Namespace内の各リソースに対して付与する権限を定義したリソース
・ClusterRole：
Kubernetesクラスタレベルでの各リソースに対する権限を定義したリソース
・RoleBinding：
Roleと、Roleを割り当てるユーザ／グループ／サービスアカウントとの紐づけを定義したリソース
・ClusterRoleBinding：
ClusterRoleと、ClusterRoleを割り当てるユーザ／グループ／サービスアカウントとの紐づけを定義したリソース

ロールには次を定義します。
・リソース（resource）：
PodやServiceといったKubernetesにおける各種リソース
・アクション（verb）：
各種リソースに対して実行可能な処理

各リソースに対する操作する主なアクション（verb）一覧

クラスタロールにはいくつか事前定義されているものがありますが、ユーザ向けのClusterRoleには以下があります。

ロールバインディングは、対象のロールと、ロールを割り当てるユーザ／グループ／サービスアカウントを定義します。
ロールバインディングでは、1つのロールを、複数のユーザ／グループ／サービスアカウントに同時に定義可能です。
2章でもお伝えしたように、ユーザ／グループは認証モジュールによって返却された情報が利用されます。

ロールバインディングはNamespaceごとに定義されるため、対象Namespaceの指定も必要です。
一方で、クラスタロールバインディングは、クラスタ共通のルールとなります。

Kubernetesクラスタにおいて事前定義されている「system:masters」グループには、「cluster-admin」クラスタロールがバインディングされているため、「system:masters」グループにユーザを割り当てないことが推奨されています。
このように、デフォルトのRoleとRoleBindingについても公式ドキュメントに記載があります。

認可についての推奨としては、次のようなものがあります。
・最小権限の原則でロールを定義する
・不必要なユーザ／グループ／サービスアカウントにロールを割り当てないようにする
・定義されているロールやその割り当て、また、それらの使用状況を、定期的に確認・見直しを実施する
など

ここまでを踏まえて、「default」サービスアカウントの認証・認可を見てみます。
各Namespaceにおいて、「default」のサービスアカウントが存在します。
各Podは、サービスアカウントを紐づける必要があり、明示的に指定が無い場合、Podが配置されるNamespaceの「default」サービスアカウントが割り当てられます。
では、「default」サービスアカウントの権限はどうなっているでしょうか？
デフォルトでは、一般のPodが割り当てられる「default」Namespace の「default」サービスアカウントには何のロールも紐づいていません。
そのため、デフォルトでは、各Podは、Kubernetes APIのリクエストは失敗するため、Kubernetesクラスタ内を探索することはできません。
たとえば、「default」サービスアカウントに何かしらのKubernetes APIを操作する権限を与えるロールを割り当てると、上記の限りでなくなってしまいます。

システムとしてKubernetes APIを操作する権限を与える場合には、最小権限を個別のシステムに割り当てるのを良しとするため、
「default」でなく、個別のサービスアカウントを作成して割り当てることを検討ください。

5.アドミッションコントロール

アドミッションコントロールは認証・認可をクリアしたリクエストに対して、さらに細かい制御を実施可能とするものです。

アドミッションコントロールは、プラグイン形式になっており、Kubernetesが標準で提供するものの他、3rdParty製品が用意するものを含む独自のWebhookで拡張することができます。
アドミッションコントロールには大きく二つの役割があります。
・validating：
リクエスト内容に対して細かい制御ルールに基づいて評価するコントロール
・mutating：
リクエスト内容を修正してデフォルト設定を埋め込むなどの操作をするコントロール

アドミッションコントロールが処理される流れとしては、mutating系が処理された後に、validating系が処理されるようになっています。
現在利用可能な（推奨されている）アドミッションコントロールの一覧はKubernetesの公式ドキュメントにありますので、K8sバージョンを確認の上ご参照ください。

例えば、LimitRangerは、リクエストが、Namespaceで設定した「LimitRange」のCPUやメモリの制限を超えていてないかをチェックします。
また、PodSecurityではリクエストのPodの「SecurityContext」と「Pod Security Standards」をもとにしてリクエストを評価しています。
ServiceAccountアドミッションコントローラは、Pod生成時にサービスアカウントを自動的に付与（デフォルト設定の埋め込み）を実施しています。

このように、リクエストが受信されてから実行されるまでの流れを見ていただきました。

6.まとめ

以下、本ブログのまとめです。
Kubernetes APIのリクエストの流れは以下のようになります。

正規のユーザ以外がKubernetesクラスタへ攻撃を試みるといったリスクを緩和するには、1章で見たように、K8sのマスター／ノードおよびAPIのアクセス制御を実施しつつ、認証情報を奪取されないように管理していくことが重要です。
また、侵害されたコンテナが横展開する際にKubernetesクラスタの情報探索を試みるケースでは、4章で見たように、デフォルトの設定では、Pod（サービスアカウント）に、K8sリソース探索の権限は与えられていませんでした。
デフォルトからの変更有無のチェックや、最小権限かつ限定的な割り当ての実施、定期的な権限まわりの確認・見直しが重要です。
各種クラウドベンダによるK8sマネージドサービスによっても、認証・権限まわりの仕様が異なるため、
それぞれの詳細は、Kubernetesの公式ドキュメントおよび各種クラウドベンダのドキュメントを参考にしてみてください。

なお、弊社Trend Micro Cloud One - Container Security™（以下、Container Security）の次の機能では、今回扱ったテーマに関連する保護が可能です。
Container Securityのアドミッションコントロール機能にて、コンテナイメージのスキャン結果やroot実行／特権コンテナの設定がされたPodの作成を検出またはブロック（デプロイ制御）します。
Container Securityのランタイムセキュリティ機能にて、侵害されたコンテナ内部からKubernetes APIの実行などの不審な挙動を捉える（検出、当該Podの削除／隔離）制御が可能です。

主な参考情報：
Kubernetesドキュメント
MITRE ATT＆CK®フレームワーク
AWS Amazon Elastic Kubernetes Serviceドキュメント