Aqua EnterpriseのDrift Prevention機能でAmazon EKS環境における不正なコンテナ操作をブロックしてみた

とばち

2022.03.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

コンサル部のとばち（@toda_kk）です。

Aquaでは、クラウドネイティブなアプリケーションを対象としてContainer Runtime Policyを適用し、コンテナランタイムを保護する機能があります。

適用できる項目のひとつに「Drift Prevention」というものがあります。これは、実行中のコンテナを監視し、元のコンテナイメージにないファイルが作成されたり実行されたりするのを防止する機能です。

たとえコンテナイメージが内包している脆弱性を狙った攻撃によって実行中のコンテナに侵入されたとしても、コンテナ上で意図しない任意のファイルを実行を防止することによって、ゼロデイ攻撃であっても防ぐことができると考えられます。

Aqua公式の解説を邦訳した下記の記事によると、「Aqua はワークロードを開始から実行時まで追跡し、現在のペイロードを元の状態と比較、すべての違いを識別しそれらの実行を外科的にブロックする能力がある」ために、こうした強力なセキュリティ機能を実現しているようです。

本記事では、Amazon EKS環境にContainer Runtime Policyを適用しDrift Preventionを有効化することで、実際にファイルの実行をブロックできるのか動作確認してみます。

前提・注意点について

本記事における検証においては、Aqua社から提供いただいたトライアルアカウントを利用しています。Aquaのセットアップに必要なコンテナイメージや公式ドキュメントなどは、アクセス用のアカウントが必要となりますのでご留意ください。

なお、Amazon EKS環境にContainer Runtime Policyを適用する手順については、下記の記事をご参照ください。

また、Drift Prevention以外にContainer Runtime Policyで適用できる項目については、下記の記事をご参照ください。

Drift Preventionの有効化

まず、新たなContainer Runtime Policyを作成し、Drift Preventionを有効化します。

Controlsから「Drift Prevention」を選択し、有効化します。変更を許可するプロセスを指定できますが、今回は空のままにしておきます。

また、Enforcement Modeを「Enforce」にすることで、不正なファイルの実行を検知してAuditログに出力するだけでなく、操作をブロックできます。

不正なファイル実行をブロックしてみる

それでは実際に、実行中のコンテナ上で、元のコンテナイメージにないファイルを実行してみてブロックされることを確認してみます。

確認用に test-nginx という名前でNginxのPodを作成し、 kubectl exec コマンドでコンテナ上への操作を実行します。

$ kubectl run test-nginx --image=nginx:latest
pod/test-nginx created

$ kubectl get pods
NAME         READY   STATUS    RESTARTS   AGE
test-nginx   1/1     Running   0          70s

$ kubectl exec test-nginx -it sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
#

続いて、既存の実行ファイルを変更した上で実行した結果、期待通りブロックされるかを確認します。 /bin/ls をコピーした /bin/list を作成して実行してみます。

# ls
bin   dev                  docker-entrypoint.sh  home  lib64  mnt  proc  run   srv  tmp  var
boot  docker-entrypoint.d  etc                   lib   media  opt  root  sbin  sys  usr
# cd /bin
# cp ls list
# list
Permission denied

元の /bin/ls は正しく実行されますが、同じ内容であるはずの /bin/list は Permission denied となります。

Aqua Console（Aquaの管理コンソール）からAuditログを確認すると、ブロックされた不正な操作が出力されています。

他の操作も確認してみます。元のコンテナイメージには含まれていない wget コマンドをインストールして、実行を試してみます。

# apt update
Get:1 http://security.debian.org/debian-security bullseye-security InRelease [44.1 kB]
Get:2 http://deb.debian.org/debian bullseye InRelease [116 kB]
Get:3 http://security.debian.org/debian-security bullseye-security/main amd64 Packages [123 kB]
Get:4 http://deb.debian.org/debian bullseye-updates InRelease [39.4 kB]
Get:5 http://deb.debian.org/debian bullseye/main amd64 Packages [8182 kB]
Get:6 http://deb.debian.org/debian bullseye-updates/main amd64 Packages [2596 B]
Fetched 8507 kB in 2s (3549 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

# apt install wget
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  wget
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 964 kB of archives.
After this operation, 3559 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian bullseye/main amd64 wget amd64 1.21-1+deb11u1 [964 kB]
Fetched 964 kB in 0s (15.6 MB/s)
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package wget.
(Reading database ... 7815 files and directories currently installed.)
Preparing to unpack .../wget_1.21-1+deb11u1_amd64.deb ...
Unpacking wget (1.21-1+deb11u1) ...
Setting up wget (1.21-1+deb11u1) ...

# wget https://google.com
Permission denied

先ほどと同じように Permission denied となりました。やはり、正しくブロックされているようです。