GuardDuty security agent for Amazon EKS clusters が v1.2.0 から Bottlerocket に対応していたので試してみた

EKS 環境のランタイム保護が可能な GuardDuty EKS Runtime Monitoring ですが、発表当時は OS は Amazon Linux 2 のみ、 CPU アーキテクチャは AMD のみをサポートしていました。

しかし、エージェントのバージョンが上がるにつれて、複数の OS, CPU アーキテクチャで利用可能になっています。

v1.2.0： ARM64 サポート、Bottlerocket サポート
v1.3.0： Ubuntu サポート
GuardDuty agent release history

特に Bottlerocket OS はコンテナの実行に必要な必須ソフトウェアのみを含んでいることから、セキュリティを強く意識した際に選択肢に入りやすいのではないでしょうか。
今回は EKS on EC2 を Bottlerocket OS で構築しつつ、 GuardDuty EKS Runtime Monitoring を試してみました。

やってみた

GuardDuty EKS Runtime Monitoring のセットアップ方法については上記ブログに記載されている通りなので飛ばします。
下記設定ファイルを利用して、eksctl create cluster -f cluster.yaml で EKS クラスターを作成します。

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: bottlerocket
  region: ap-northeast-1
  version: "1.27"

availabilityZones: ["ap-northeast-1a", "ap-northeast-1c"]

iam:
  withOIDC: true

nodeGroups:
  - name: ng-bottlerocket
    instanceType: m5.large
    desiredCapacity: 2
    amiFamily: Bottlerocket
    iam:
      attachPolicyARNs:
        - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
        - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
        - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
        - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
    bottlerocket:
      settings:
        motd: "Hello from eksctl!"

addons:
  - name: aws-guardduty-agent
    resolveConflicts: overwrite

GuardDuty security agent for Amazon EKS clusters は特にバージョン指定しなかったので、最新の v1.3.1 がインストールされました。
busybox イメージを利用して、 pod 内からテスト用ドメイン (guarddutyc2activityb.com) をクエリします。

kubectl run busybox --image=amd64/busybox --command -- nslookup guarddutyc2activityb.com

正しく検知されました。

インスタンス周りの情報も取れてます。

ドメインやプロセス等の情報も取れました。

EKS on EC2 の Node でも検知させてみた

GuardDuty EKS Runtime Monitoring ですが、エージェントを入れるとコンテナランタイムだけでなく EKS Node のランタイム保護も可能です。
今回は EKS Node に SSM Session Manager で接続して検知させてみました。
Bottlerocket ではインスタンスの設定や管理をコントロールコンテナ経由で行いますが、このコンテナ内で先程のテスト用ドメイン (guarddutyc2activityb.com) にアクセスしてみます。
nslookup や dig はインストールされていなかったので curl で実行しました。

[ssm-user@control]$ curl http://guarddutyc2activityb.com
curl: (6) Could not resolve host: guarddutyc2activityb.com

上記コマンドを実行後、 Pod 内から実行した時同様に検知されました。
Kubernetes リソースが検知対象の場合は Resource type が EKSCluster, Node が検知対象の場合は Resource type が Instance になるようです。

Pod の時同様、クエリ先のドメインや検知されたプロセス名なども確認できます。

まとめ

気づいたら GuardDuty EKS Runtime Monitoring の対象 OS が大分増えてました！
当初はサポート外の OS を利用されていた方も是非活用を検討してみて下さい。