数か月前(2021年8月)に米国のNational Security Agency (NSA)とCybersecurity and Infrastructure Security Agency(CISA) が共同で公開した"Kubernetes Hardening Guidance" と題した、Kubernetesクラスタに対する脅威とリスクを低減するためのクラスタ設定に関するレポートをご存じでしょうか。

レポート概要

このレポート内では以下のトピックにフォーカスをあててThreat modelを利用した脅威の洗い出しをしています。

サプライチェーンリスク
- コンテナイメージを構成する複雑かつ幾重もの依存関係内に紛れ込むマルウェアによるリスク
悪意ある脅威アクター
- 既知の脆弱性や設定ミスを突いてKubernetesのControl Planeやノード等のアクセス権を奪取しようとする人たち
内部の脅威
- 管理者やユーザ、サービス／インフラプロバイダーのオペレータによる悪さ

以下の観点で脅威・リスクの低減方法について本レポート内で紹介しています。

コンテナ／Podに混入した既知の脆弱性および設定ミスのスキャン
攻撃者の侵入に備えLeast privilege設定の徹底
攻撃者の侵入に備え園法を防ぐためのネットワークの分離
ファイアウォールによる不必要な接続の制限
秘匿情報の暗号化
攻撃者はもちろんユーザ／管理者のアクセスを制限するための認証認可設定
攻撃を早期検出するためのログ監視
継続的なリスクのアセスメントとパッチ適用の確認

これらの観点に沿ったControlについて、50数ページにおよぶ英語のレポートを読むのがベストです。が、本ブログでは、このレポートで紹介されたプラクティスに自分のKubernetes環境がどれだけ準拠してるのかを評価してくれるkubescapeというOSSプロジェクトを利用して、本レポート内でNSAが推奨するプラクティスを準拠していない箇所から順に見ていきたいと思います。kubescapeを使うと、準拠状況が評価スコアという形で数値化されるので、この評価スコアを上げていくという、のをモチベーションにして進めてみます。

またレポートで紹介されている観点の把握がCKS取得を目指すうえで必要な知識にどれだけマッピングされているか、についても見ていきます。

評価対象

Raspberry Pi 4 x 3台で構成したおうちクラスタ
Argo Events/Workflows/CDベースのCI/CD環境をデプロイ
バックエンドとフロントエンドを含むAPIサーバで構成される簡単な2 Tierなアプリケーション（CI/CDと同一クラスタ上にデプロイ）

3ノード上の6個のNamespace上で計44個のPodが動いている状態。

まずは今何点？

６７点！

うむ、悪くないが良くもない。合格ラインギリギリといったところか。

まずは0点のところから見ていく

`Automatic mapping of service account`

+--------------------------------------+------------------+--------------------+---------------+-----------+
|         CONTROL NAME                 | FAILED RESOURCES | EXCLUDED RESOURCES | ALL RESOURCES | % SUCCESS |
+--------------------------------------+------------------+--------------------+---------------+-----------+
| Automatic mapping of service account |        63        |         0          |      63       |    0%     |

観点と対処方法
- デフォルトではKubernetesクラスタはポッドを生成・起動する際にPod上にサービスアカウントのトークンを自動でマウントしてくれる。きっとコレ /var/run/secrets/kubernetes.io/serviceaccount/token のことだと思う。Pod内のアプリケーションが乗っ取られた場合、攻撃者がこのサービスアカウントを利用してクラスタに攻撃範囲を広げるリスクがある。基本的にPod上のコンテナ化されたアプリケーションがサービスアカウントを直接利用することはないので、PodのautomountServiceAccountToken設定を無効にしておこうね、というプラクティスです。
実際にやってみる
- automountServiceAccountToken: falseの設定をPodもしくはServiceAccountに追加する必要があるみたい。

 apiVersion: v1
 kind: ServiceAccount
 metadata:
   name: argo-events-sa
   namespace: argo-events
+automountServiceAccountToken: false

結果

+--------------------------------------+------------------+--------------------+---------------+-----------+
|         CONTROL NAME                 | FAILED RESOURCES | EXCLUDED RESOURCES | ALL RESOURCES | % SUCCESS |
+--------------------------------------+------------------+--------------------+---------------+-----------+
| Automatic mapping of service account |        51        |         0          |      63       |    19%     |

63件未対処から51件未対処に改善! 残りは主にkube-systemのServiceAccountであるため一旦ここまで。トータルスコアは ６７⇒６９点 にアップ！

Resource policies

+--------------------------------------+------------------+--------------------+---------------+-----------+
|         CONTROL NAME                 | FAILED RESOURCES | EXCLUDED RESOURCES | ALL RESOURCES | % SUCCESS |
+--------------------------------------+------------------+--------------------+---------------+-----------+
| Resource policies                    |        29        |         0          |      35       |    17%    |

観点と対処方法
- コンテナが予期せずCPUやメモリをたくさん消費して、ノードのリソースを食いつぶすのを防ぐために、コンテナレベル(LimitRange)とNamespaceレベル(ResourceQuota)で各々クオータ制限を設定しましょうというプラクティスになります。これに加えてkubernetesの公式ブログでは、PODによるPIDの発行数にも制限を設ける and/or 予めノード用(ホストのOS用やデーモン用)にPID利用範囲を予約しておく事も更なるリソース制限として推奨しています。
実際にやってみる
- 以下のLimitRangeの設定をNamespaceに追加すると、、、（ここでおうち環境がトラブルに見舞われる。。。）

CKSのカリキュラムと突き合わせ

上記のkubescapeの観点(NSAガイドライン)とCKS試験カリキュラムのドメインを見比べると以下のようなマッピングになる。NSAガイドラインの観点がCKS試験ドメインを全体的にカバーしているように見えます。ただ「③System Hardening」と「⑤Supply Chain Security」あたりのNSAガイドラインにおけるカバーが薄く見えます。アウトライン同士の突き合わせなので正確なところは、それぞれ詳細を確認頂ければと思います。

#	CKS試験ドメイン	割合
①	Cluster Setup	10%
②	Cluster Hardening	15%
③	System Hardening	15%
④	Minimize Microservice Vulnerabilities	20%
⑤	Supply Chain Security	20%
⑥	Monitoring, Logging and Runtime Security	20%

NSA観点 Lvl 1	NSA観点 Lvl 2	CKS試験カリキュラム
Kubernetes Pod security	"Non-root" containers and "rootless" container engines	⑥
	Immutable container file systems	⑥
	Building secure container images	⑤
	Pod Security Policies	④
	Protecting Pod service account tokens	①
	Hardening container engines	③
Network separation and hardening	Namespaces	①
	Network policies	①
	Resource policies	①
	Control plane hardening	②
	Worker node segmentation	①
	Encryption	④
	Secrets	④
	Protecting sensitive cloud infrastructure	③
Authentication and authorization	Authentication	②
	Role-based access control	②
Log auditing	Logging	⑥
	SIEM platforms	⑥
	Alerting	⑥
	Service meshes	⑥
	Fault tolerance	⑥

おわりに

あまり各プラクティスに対する実際の対処方法には触れられませんでしたが、このガイドラインをよりどころにして学習を進めるのは１つの選択肢として使えそうである、というところは見えてきたかと思います。個人的にはKubernetesクラスタの設定周りに関する観点の紹介だけでなく、ノード側の観点・対策も一例紹介したかったところです。次回に期待。
※トラブルに見舞われてタイムアップになった個所は解消次第アップデートしていきたい

NSAでCKSを学ぶ：アメリカ国家安全保局が推すセキュアなKubernetesクラスタのすゝめ