2
Help us understand the problem. What are the problem?
Organization

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

image.png

数か月前(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と同一クラスタ上にデプロイ)

image.png

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

image.png

まずは今何点?

image.png

67点!

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

まずは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であるため一旦ここまで。トータルスコアは 67⇒69点 にアップ!

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

おわりに

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

リンク

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Sign upLogin
2
Help us understand the problem. What are the problem?