この記事は AWS Advent Calendar 2020 14日目の記事です。

はじめに

2020/12/4 に AWS Security Hub に統合可能な 3rd Party パートナーの製品として
Aqua Security の kube-bench が追加されたことが発表されました。

AWS Security Hub adds open source tool integrations with Kube-bench and Cloud Custodian
https://aws.amazon.com/jp/about-aws/whats-new/2020/12/aws-security-hub-adds-open-source-tool-integration-with-kube-bench-and-cloud-custodian/

この統合により kube-bench で実行した CIS Kubernetes Benchmark および
CIS Amazon EKS Benchmark のチェック結果を AWS Security Hub で集中管理できるようになりました。

EKS クラスターで kube-bench を実行し、Security Hub に結果を取り込んでみましたのでご紹介します。

CIS Benchmark とは

CIS Benchmark は米国の非営利団体である CIS (Center for Internet Secuirty) が公開している
各種 OS、サーバー、クラウド環境などを強化するためのガイドラインです。
CIS は 140 以上の CIS Benchmark を発行しており、PCI DSS などのコンプライアンス要件で
業界で認められているシステム強化標準との記載があった場合などに参照されます。

CIS Benchmark は CIS のサイトから PDF 形式でダウンロードできます。
https://www.cisecurity.org/cis-benchmarks/

kube-bench とは

kube-bench は対象の環境が CIS Kubernetes Benchmark に記載されている推奨事項に
準拠しているかどうかをチェックすることができる Go 製のアプリケーションです。
Aqua Security 社が開発、OSS として公開しています。

CIS Kubernetes Benchmark だけでなく、CIS Amazon Elastic Kubernetes Service (EKS) Benchmark や
CIS Google Kubernetes Engine (GKE) Benchmark のチェックもサポートしています。

AWS Security Hub とは

AWS Security Hub は AWS 環境全体の様々なセキュリティデータを集約して
一元的に管理するためのサービスです。
Amazon GuardDuty や Inspector, Macie などの AWS サービスはもちろんのこと
多くの 3rd Party セキュリティ製品と統合されており、対応する製品のデータを Security Hub に
送信したり、逆に Security Hub のデータを製品側で受信するといったことが可能です。

内部的には AWS Security Finding Format (ASFF) と呼ばれる JSON 型のフォーマットで結果情報が
管理されているため、この形式に準拠していれば独自のデータをインポートすることもできます。

前提条件

以下のバージョンで実施しています。

Amazon EKS: 1.17
eksctl: 0.30.0
kube-bench: 0.40.0

CIS Amazon EKS Benchmark v1.0 のチェックを EKS クラスター内で実行します。
EKS クラスターの構築、Security Hub の有効化といった手順は割愛します。

統合の有効化

Security Hub コンソールの統合から kube-bench を検索し、結果を受け入れる をクリックすると
調査結果を Security Hub に送信するために必要な IAM ポリシーに関する情報が表示されます。

確認画面で再度結果を受け入れるを選択すると、ステータスが有効になります。

IAM ロールの設定

kube-bench を EKS クラスター内で実行するため、実行される Pod が Security Hub へ
チェック結果を送信する権限を持っている必要があります
Pod に対して AWS リソースへのアクセス権限を割り当てる方法は 2 通りあります。

IRSA を使用すると、IAM ロールを Kubernetes のサービスアカウントに関連付けることができます。
これにより、kube-bench が起動する pod にのみ Security Hub へのアクセス許可を提供できます。
ノードグループに設定する IAM ロールを使用した場合、そのグループ配下で起動するすべての Pod に
Security Hub へのアクセス権限が割り当てられてしまう点にご注意ください。

今回は IRSA を使用します。
IRSA を使用するために、IAM OIDC Provider を作成していない場合は先に作成しておきます。

$ eksctl utils associate-iam-oidc-provider --cluster {CLUSTER_NAME} --approve --region ap-northeast-1

次に以下のポリシーをアタッチした IAM ロールを作成します。
リージョンは適宜読み替えてください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "securityhub:BatchImportFindings",
            "Resource": [
                "arn:aws:securityhub:ap-northeast-1::product/aqua-security/kube-bench"
            ]
        }
    ]
}

IAM ロールの信頼関係に以下のようなポリシーを追記します。
<ACCOUNT_ID>, <OIDR_PROVIDER_ID>, リージョンはご自身のものを設定してください。
Namespace に kube-bech を使用する想定で記述しています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<ACCOUNT_ID>:oidc-provider/oidc.eks.ap-northeast-1.amazonaws.com/id/<OIDC_PROVIDER_ID>"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringLike": {
          "oidc.eks.ap-northeast-1.amazonaws.com/id/<OIDC_PROVIDER_ID>:sub": "system:serviceaccount:kube-bench:*",
          "oidc.eks.ap-northeast-1.amazonaws.com/id/<OIDC_PROVIDER_ID>:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}

コンテナイメージの作成

kube-bench のコンテナイメージをビルドし、ECR に push しておく必要があります。
最初にイメージを格納するための ECR リポジトリを作成します。

$ aws ecr create-repository --repository-name k8s/kube-bench --image-tag-mutability MUTABLE
{
    "repository": {
        "repositoryArn": "arn:aws:ecr:ap-northeast-1:123456789012:repository/k8s/kube-bench",
        "registryId": "123456789012",
        "repositoryName": "k8s/kube-bench",
        "repositoryUri": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/k8s/kube-bench",
        "createdAt": 1607747704.0,
        "imageTagMutability": "MUTABLE",
        "imageScanningConfiguration": {
            "scanOnPush": false
        },
        "encryptionConfiguration": {
            "encryptionType": "AES256"
        }
    }
}

kube-bench のソースコードを GitHub から clone します。

$ git clone https://github.com/aquasecurity/kube-bench.git
Cloning into 'kube-bench'...
remote: Enumerating objects: 4115, done.
remote: Total 4115 (delta 0), reused 0 (delta 0), pack-reused 4115
Receiving objects: 100% (4115/4115), 7.69 MiB | 5.28 MiB/s, done.
Resolving deltas: 100% (2644/2644), done.

$ cd kube-bench

Security Hub に実行結果を連携する場合、イメージをビルドする前に cfg/eks-1.0/config.yaml を編集し
実行対象の AWS アカウントおよびリージョン、クラスター名を書き換えておく必要があります。

cfg/eks-1.0/config.yaml

---
AWS_ACCOUNT: "123456789012"
AWS_REGION: "ap-northeast-1"
CLUSTER_ARN: "arn:aws:eks:ap-northeast-1:123456789012:cluster/{YOUR_CLUSTER_NAME}"

コンテナイメージをビルドし、ECR に push します。

$ aws ecr get-login-password | docker login --username AWS --password-stdin https://123456789012.dkr.ecr.ap-northeast-1.amazonaws.com
Login Succeeded

$ docker build -t k8s/kube-bench .
...
Successfully built 6ad073f96455
Successfully tagged k8s/kube-bench:latest

$ docker tag k8s/kube-bench:latest 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/k8s/kube-bench:latest
$ docker push 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/k8s/kube-bench:latest
The push refers to repository [123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/k8s/kube-bench]
bd6c279efeaa: Pushed 
3032a8c3bf7a: Pushed 
b0efa7564210: Pushed 
fe4cf80d4f2c: Pushed 
31c3d3db74eb: Pushed 
d2e36eff2b5d: Pushed 
f4666769fca7: Pushed 
latest: digest: sha256:da95de0edccad7adb6fd6c80137a65b5458142efe14efa94ac44cc5c6ce6b2ef size: 1782

kube-bench の実行

サービスアカウントの作成

以下のマニフェストファイルで IAM ロールを関連付けたサービスアカウントを作成します。

sa.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: kube-bench-sa
  namespace: kube-bench
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/<IAM_ROLE_NAME>

Namespace kube-bench を作成し、apply します。

$ kubectl create ns kube-bench
kubectl create ns kube-bench

$ kubectl apply -f sa.yaml
serviceaccount/kube-bench-sa created

$ kubectl get sa -n kube-bench
NAME            SECRETS   AGE
default         1         6m32s
kube-bench-sa   1         11s

ジョブの実行

GitHub から clone した jobs-eks.yaml を開き、image, command を編集します。
command に --asff フラグを追加することで、Security Hub へ結果の送信が行われます。
更に先ほど作成したサービスアカウント名を追記します。
編集後のファイルは以下のようになります。

job-eks.yaml

---
apiVersion: batch/v1
kind: Job
metadata:
  name: kube-bench
spec:
  template:
    spec:
      hostPID: true
      serviceAccountName: kube-bench-sa
      containers:
        - name: kube-bench
          image: 123456789012.dkr.ecr.region.amazonaws.com/k8s/kube-bench:latest
          command: ["kube-bench", "node", "--benchmark", "eks-1.0", "--asff"]
          volumeMounts:
            - name: var-lib-kubelet
              mountPath: /var/lib/kubelet
              readOnly: true
            - name: etc-systemd
              mountPath: /etc/systemd
              readOnly: true
            - name: etc-kubernetes
              mountPath: /etc/kubernetes
              readOnly: true
      restartPolicy: Never
      volumes:
        - name: var-lib-kubelet
          hostPath:
            path: "/var/lib/kubelet"
        - name: etc-systemd
          hostPath:
            path: "/etc/systemd"
        - name: etc-kubernetes
          hostPath:
            path: "/etc/kubernetes"

Kubernetes の job として kube-bench を実行し、正常終了することを確認します

$ kubectl apply -f job-eks.yaml -n kube-bench
job.batch/kube-bench created

$ kubectl get all -n kube-bench                                                                                                                                                    
NAME                   READY   STATUS      RESTARTS   AGE
pod/kube-bench-q4sbd   0/1     Completed   0          55s

NAME                   COMPLETIONS   DURATION   AGE
job.batch/kube-bench   1/1           5s         55s

Pod のログに以下のようなメッセージが出力され、ジョブがエラーとなる場合は
cfg/eks-1.0/config.yaml の記載内容が正しいか確認してください。

failed to output to ASFF: finding publish failed: MissingEndpoint: 'Endpoint' configuration is required for this service

Security Hub の検出結果を確認

通常、kube-bench の実行結果は Pod のログに出力されます。

出力例 (クリックで展開します)

$ kubectl logs -f pod/kube-bench-2j2ss -n kube-bench
[INFO] 3 Worker Node Security Configuration
[INFO] 3.1 Worker Node Configuration Files
[PASS] 3.1.1 Ensure that the proxy kubeconfig file permissions are set to 644 or more restrictive (Scored)
[PASS] 3.1.2 Ensure that the proxy kubeconfig file ownership is set to root:root (Scored)
[PASS] 3.1.3 Ensure that the kubelet configuration file has permissions set to 644 or more restrictive (Scored)
[PASS] 3.1.4 Ensure that the kubelet configuration file ownership is set to root:root (Scored)
[INFO] 3.2 Kubelet
[PASS] 3.2.1 Ensure that the --anonymous-auth argument is set to false (Scored)
[PASS] 3.2.2 Ensure that the --authorization-mode argument is not set to AlwaysAllow (Scored)
[PASS] 3.2.3 Ensure that the --client-ca-file argument is set as appropriate (Scored)
[PASS] 3.2.4 Ensure that the --read-only-port argument is set to 0 (Scored)
[PASS] 3.2.5 Ensure that the --streaming-connection-idle-timeout argument is not set to 0 (Scored)
[PASS] 3.2.6 Ensure that the --protect-kernel-defaults argument is set to true (Scored)
[PASS] 3.2.7 Ensure that the --make-iptables-util-chains argument is set to true (Scored) 
[PASS] 3.2.8 Ensure that the --hostname-override argument is not set (Scored)
[WARN] 3.2.9 Ensure that the --event-qps argument is set to 0 or a level which ensures appropriate event capture (Scored)
[PASS] 3.2.10 Ensure that the --rotate-certificates argument is not set to false (Scored)
[PASS] 3.2.11 Ensure that the RotateKubeletServerCertificate argument is set to true (Scored)

== Remediations node ==
3.2.9 If using a Kubelet config file, edit the file to set eventRecordQPS: to an appropriate level.
If using command line arguments, edit the kubelet service file
/etc/systemd/system/kubelet.service on each worker node and
set the below parameter in KUBELET_SYSTEM_PODS_ARGS variable.
Based on your system, restart the kubelet service. For example:
systemctl daemon-reload
systemctl restart kubelet.service


== Summary node ==
14 checks PASS
0 checks FAIL
1 checks WARN
0 checks INFO

== Summary total ==
14 checks PASS
0 checks FAIL
1 checks WARN
0 checks INFO

--asff フラグを指定して、Security Hub に結果を送信した場合は
Security Hub にインポートされた件数のみがログに記載されています。

$ kubectl logs -f pod/kube-bench-q4sbd -n kube-bench
2020/12/12 14:51:07 Number of findings that were successfully imported:1

今回の環境の場合、1件であることが確認できます。

Security Hub に結果が送信されるのはチェック結果が FAIL または WARN となった
項目のみであることに注意してください。
(全てのチェックを PASS した場合、Security Hub 側には結果は生成されません。)

Security Hub コンソールの検出結果を確認すると、送信された 1 件の結果が
正常に取り込まれていることを確認できます。

カスタムインサイトの活用

Security Hub には特定のグループ化条件とフィルタを使用して、リソースや環境毎に
データを集約することができる、カスタムインサイトという機能が用意されています。
作成方法はコンソールのインサイトから任意のグループ化条件、フィルタを設定し、保存するだけです。

例えば Security Hub をマルチアカウント構成で利用している場合、マスターアカウントでは
メンバー AWS アカウントごとに検出結果を集約するような使い方ができます。

以下はグループ化条件を AWS アカウント ID に設定し、製品名 Kube-bench をフィルターに
設定したカスタムインサイトの例です。アカウント ID をクリックして、対象アカウントの
kube-bench の結果を即座に確認できるようになります。

また単一アカウントで運用している場合でも、グループ化条件をリソース ID に設定すれば、
EKS クラスター毎の検出結果を一覧化するといった使い方も可能です。

複数アカウントやクラスターを運用している環境では、カスタムインサイトの活用で
より結果を管理しやすくなるのでおすすめです。

参考

Integrating kube-bench with AWS Security Hub
https://github.com/aquasecurity/kube-bench/blob/master/docs/asff.md
Managing custom insights
https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-custom-insights.html

以上です。
参考になれば幸いです。