【AWS re:Invent 2022】EKS セキュリティな Builders’ Session 二本立て

re:Invent 2022 に現地参加しています、CI 事業部セキュリティセクションの村上です。
3日目はたまたま Amazon EKS 関連の Builders’ Session に連続して参加したので、まとめてレポートします。

1. Deploying repeatable, secure, and compliant Amazon EKS clusters (SEC308)
2. Kubernetes threat detection and incident response automation (SEC305-R)

1つ目のセッションでは、Kubernetes のリソースを Service Catalog から数クリックで起動する方法と、設定がベストプラクティスに沿っているか確認する方法を学びました。
2つ目のセッションでは、GuardDuty EKS Protection を使った、攻撃や不正操作の検出を体験しました。

Builders’ Session の形式については前回の記事に記載したので、割愛します。

Deploying repeatable, secure, and compliant Amazon EKS clusters (SEC308)

概要

In this builders’ session, learn how to deploy, manage, and scale containerized applications that run Kubernetes on AWS with AWS Service Catalog. Walk through how to deploy the Kubernetes control plane into a virtual private cloud, connect worker nodes to the cluster, and configure a bastion host for cluster administrative operations. Using AWS CloudFormation registry resource types, learn how to declare Kubernetes manifests or Helm charts to deploy and manage your Kubernetes applications. With AWS Service Catalog, you can empower your teams to deploy securely configured Amazon EKS clusters in multiple accounts and AWS Regions.
このビルダーズセッションでは、AWS Service Catalog を使用して AWS 上で Kubernetes を実行するコンテナ化したアプリケーションをデプロイ、管理、スケールする方法を学習します。Kubernetes コントロールプレーンを VPC にデプロイし、ワーカーノードをクラスターに接続し、クラスター管理操作のための踏み台ホストを構成する方法を説明します。AWS CloudFormation のレジストリリソースタイプを使用して、Kubernetes マニフェストまたは Helm チャートを宣言して、Kubernetes アプリケーションを展開および管理する方法を学びます。AWS Service Catalog を使用すると、複数のアカウントと AWS リージョンで安全に構成されたAmazon EKS クラスタを展開することができます。

これだけ読んでもよく分かりませんでしたが、とりあえず一式デプロイするらしい。
“安全に” はどう担保するのでしょうか…？

スピーカー

• Kiran Lakkireddy, Principal Solutions Architect
• Cher Simon, Principal Partner Solutions Architect
• Vanishree Eswarappa, Principal Solution Architect
• Devi Paulvannan, Sr. Solutions Architect
• Welly Siauw, Principal Partner Solutions Architect

ハンズオン前の解説

最初の説明をテーブルごとではなく、中央の1名が行なうスタイルで始まりました。
スライドは各テーブルのモニターで見つつ解説を聞きました。

EKS における責任共有モデル。
コントロールプレーンは AWS の責任範囲になります。

EKS におけるセキュリティ要素の一覧。
今回は主に左側を見ていきます。

ハンズオン

1. CloudFormation で Service Catalog の Product を作成する
2. Product を起動する
3. 裏で CloudFormation が動き、リソースが作成される

上記1~3の流れを、クラスターやノードグループ、helm chart で管理されたアプリなどについてそれぞれ行ないます。
リソースを作成したら、随時、踏み台サーバからクラスターに接続し、kubectl でリソース確認やログ確認を行なっていきます。

Service Catalog から数クリックでリソースを起動できるので、Kubernetes や EKS に詳しくないユーザーでも簡単に利用できそうです。

その後、オープンソースツール kube-bench を使用して、設定チェックを行ないました。
https://github.com/aquasecurity/kube-bench

上記は CIS EKS Benchmark に準拠しているかチェックした結果です。
EKS 用の Benchmark は、CIS Kubernetes Benchmark に含まれるコントロールプレーン関連の項目がないなど、EKS 環境に適したガイドラインになっています。

最後に、サービスアカウントに IAM ロールを使用するクラスターも同様に作成し、ノード追加操作など行ないました。

ハンズオン後のデモ

Service Catalog に登録した Product や、Portfolio (Product をまとめたカタログのようなもの) は、別の AWS アカウントや、同一 Organization 内で共有することができます。共有された側では、import 処理が必要です。
ここは複数アカウントが必要なため、講師によるデモを見ました。
複数のシステムで共通で使えるコンポーネントのテンプレートを配布するのに便利そうです。

Kubernetes threat detection and incident response automation (SEC305-R)

概要

In this hands-on builders’ session, learn how to use Amazon GuardDuty and Amazon Detective to effectively analyze Kubernetes audit logs from Amazon EKS and alert on suspicious events or malicious access such as an increase in “403 Forbidden” or “401 Unauthorized” logs. Correlate information to quickly answer questions such as: Which Kubernetes API methods were called by a Kubernetes user account showing signs of compromise? Also learn how to automate incident responses for streamlining workflows and remediation using sample Amazon GuardDuty Kubernetes findings with Amazon EventBridge, and perform root cause analysis with Amazon Detective.
このハンズオンでは、Amazon GuardDuty と Amazon Detective を使用して、Amazon EKS からの Kubernetes 監査ログを効果的に分析し、「403 Forbidden」または「401 Unauthorized」ログの増加などの疑わしいイベントや、悪意のあるアクセスについてアラートを上げる方法を学習します。情報を関連付けることで、侵害の兆候がある Kubernetes ユーザーアカウントによって、どのKubernetes API メソッドが呼び出されたのか？といった質問に素早く回答します。また、Amazon EventBridge と Amazon GuardDuty の Kubernetes の検出結果サンプルを使用して、ストリーミングワークフローや修復のためインシデント対応を自動化する方法および、Amazon Detectiveを使用して根本原因を分析する方法を学習します。

先ほどのセッションでは、クラスターがセキュアな設定になっているかをチェックしましたが、今回は不正な操作を検知するというものです。

スピーカー

• Mathieu Bruneau, Containers Specialist SA
• Changsu Lee, sr container specialist solutions architect
• John Lee, Solutions Architect
• Sushanth Mangalore, Sr. Solutions Architect
• Aaron Miller, Principal Specialist SA

ハンズオン前の解説

Kubernetes API Server の API 呼び出しログは、EKS の control plane logging を有効化すれば、 CloudWatch Logs に出力して、内容を精査することができます。
ただし、生のログを解析するのは大変です… (特にクラスターが多数ある場合)

GuardDuty EKS Protection を使うと、上記の logging を有効化しなくても、API 呼び出しを GuardDuty が自動でモニタリングし、疑わしい操作を検知してくれます。

上記はこちらのイベント一覧を一枚にまとめたもの。

更に、Detective と組み合わせると、検出結果を関連付けて確認することができ、原因調査が効率よく行なえます。
例えば同じ IP アドレスからの複数の API 呼び出しを並べて見ることが可能です。

EventBridge を経由して Lambda に GuardDuty の検知結果を送れば、だいたいどんな処理でもできます。
(自動対応は今回のハンズオン対象外のため、具体的な対応方法には踏み込みませんでした。)

ハンズオン

1. クラスター・ノードグループを作成
2. RoleBindings の編集や Pod の security context 編集を実施
3. GuardDuty で検知結果が表示されるのを確認
4. SNS＋EventBridgeで通知設定
5. kubectl exec コマンドを namespace=kube-system で実行し、再度 GuardDuty で検知
6. SNS からのメール受信を確認

上図が今回発生させた疑わしいイベントです。
Cloud9 からコマンドを実行し、2分ほどで GuardDuty コンソールに表示されました。

通知メールはその後数分で届きました。
JSON が未整形で記載されており、可読性に欠けるため、フィルタリングや整形を行なった方が良さそうです。

今回のハンズオンでは触れませんでしたが、追加機能もいくつか発表され、どんどん強化されていく GuardDuty。

今後の展開が気になります。

ハンズオン後のデモ

Detective は情報収集に時間がかかるため、ハンズオンではなく講師のデモを見ました。

おわりに

Kubernetes は業務ではあまり触る機会がないのですが、ここ１ヶ月ほど re:Invent のために勉強してきたおかげで、話についていきやすかったです。 (5分の1ぐらい本当です)

静的な設定チェックと動的な不正検知、両者を学べて良い機会になりました。
まだ触れられていない領域もあるので、今後更に Kubernetes や AWS の関連サービスの理解を深め、より効果的なセキュリティ対策を提案できるようにしたいと思います。