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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/39615/f70b767d-22cf-f3f4-8214-2696f5cf532d.png "イメージです。NSAじゃなくてMI6ですが...")


数か月前(2021年8月)に米国のNational Security Agency (NSA)とCybersecurity and Infrastructure Security Agency(CISA) が共同で公開した["Kubernetes Hardening Guidance"](https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF) と題した、Kubernetesクラスタに対する脅威とリスクを低減するためのクラスタ設定に関するレポートをご存じでしょうか。

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

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

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

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

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

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

# 評価対象

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/39615/f3402f81-cf41-577a-498f-399d872cba7f.png)

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/39615/0ae3b74c-63f2-1cdc-2d6b-bec9448a6d67.png)


# まずは今何点？

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/39615/3236baa2-ea13-e937-4ec5-94183dbf474c.png)


**６７点！**

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

# まずは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に追加する必要があるみたい。

```diff
 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のカリキュラムと突き合わせ

* [CTR_KUBERNETES HARDENING GUIDANCE.PDF](https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF)
* [curriculum/CKS_Curriculum_ v1.22.pdf at master · cncf/curriculum](https://github.com/cncf/curriculum/blob/master/CKS_Curriculum_%20v1.22.pdf)

上記の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クラスタの設定周りに関する観点の紹介だけでなく、ノード側の観点・対策も一例紹介したかったところです。次回に期待。
※トラブルに見舞われてタイムアップになった個所は解消次第アップデートしていきたい

# リンク

* [CTR_KUBERNETES HARDENING GUIDANCE.PDF](https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF)
* [armosec/kubescape: kubescape is the first tool for testing if Kubernetes is deployed securely as defined in Kubernetes Hardening Guidance by to NSA and CISA](https://github.com/armosec/kubescape)
* [A Closer Look at NSA/CISA Kubernetes Hardening Guidance | Kubernetes](https://kubernetes.io/blog/2021/10/05/nsa-cisa-kubernetes-hardening-guidance/)
* [Process ID Limits And Reservations | Kubernetes](https://kubernetes.io/docs/concepts/policy/pid-limiting/)
* [A Closer Look Into the NSA Kubernetes Hardening Guide](https://blog.aquasec.com/nsa-kubernetes-hardening-guide)