【超待望アップデート】ECRに対する脆弱性スキャン機能が提供されました
「俺はこの日を待ち望んでいた…ほんまやで…」
コンテナセキュリティを考えるにあたり、一番最初に気をつけておきたい点がそのコンテナイメージで導入したパッケージに対する脆弱性の混入。今まででも、aquasecurity/trivyや、goodwithtech/dockleなど、フリーで利用できる優秀なツールは存在していましたが、それぞれCI/CDパイプラインへの組み込みなどは独自の仕組みの構築が必要か、もしくは有償のaquaなどのコンテナセキュリティ製品の導入が必須でした。
今回、AWSのECRに対して、AWSマネージドな仕組みで脆弱性スキャンを実行する仕組みがリリースされたので、まずは早速触ってみた様子をお届けいたします。コンテナセキュリティ対策の足固めとして、まずは皆さんのECRリポジトリ、軒並みスキャンしてみてはいかがでしょうか?使い方は非常に簡単。
AWSフルマネージド脆弱性スキャンきたか…!! ( ゚д゚) ガタッ / ヾ __L| / ̄ ̄ ̄/_ \/ /
ECRにあるイメージの脆弱性スキャンしてみた
というわけで、実際にスキャンしてみました。スキャン対象は、なんとなく脆弱性がてんこ盛りに思える以下のイメージです。
クライアントにpullします。
1 | $ docker pull piesecurity /apache-struts2-cve-2017-5638 |
今回のスキャン用に新しく、ECRリポジトリを作成します。リポジトリ名はecr-scan-sample
とします。
1 2 3 4 5 6 7 8 9 10 11 | $ aws ecr create-repository --repository-name ecr-scan-sample { "repository" : { "repositoryArn" : "arn:aws:ecr:ap-northeast-1:629895769338:repository/ecr-scan-sample" , "registryId" : "629895769338" , "repositoryName" : "ecr-scan-sample" , "repositoryUri" : "629895769338.dkr.ecr.ap-northeast-1.amazonaws.com/ecr-scan-sample" , "createdAt" : 1572245308.0, "imageTagMutability" : "MUTABLE" } } |
先程、プルしたイメージを作成したECRリポジトリにプッシュします。
1 2 3 | $ $(aws ecr get-login --no-include-email --region ap-northeast-1) $ docker tag piesecurity /apache-struts2-cve-2017-5638 629895769338.dkr.ecr.ap-northeast-1.amazonaws.com /ecr-scan-sample :latest $ docker push 629895769338.dkr.ecr.ap-northeast-1.amazonaws.com /ecr-scan-sample :latest |
Webコンソールを確認すると、リポジトリecr-scan-sample
に当該イメージがアップロードされているのが確認できます。
イメージを選択すると、「スキャン」ボタンがアクティブになるのでクリックします。
ステータスが進行中になります。
しばらくすると、ステータスが完了となり、脆弱性スキャン結果への詳細がリンクとして表示されます。
詳細をクリックすると、このイメージに含まれる脆弱性の一覧がCVEベースで表示されます。リンクは全てCVEデータベースへのリンクになっており、脆弱性の重要度で、並び替えができるようになってます。
イメージプッシュ時の自動スキャン設定
ECRに対して、イメージをプッシュしたときに自動的にスキャンする設定が追加されています。既存のリポジトリを選択した状態で、「編集」ボタンをクリックすると、「リポジトリの編集画面」に遷移します。ここに、「プッシュ時にスキャン」という項目が追加されており、これを有効にしておくと、ECRにイメージをプッシュするたびに自動で、脆弱性スキャンが実行されるというわけです。
「マネージドな仕組みで脆弱性スキャンができることの純粋な喜びに満ちあふれている!」
自分が導入しようとしているイメージの脆弱性をスキャンしておくのは、コンテナセキュリティ対策において、その足固めとして一番基本中の基本と言えます。本来は、この脆弱性スキャンした結果に対して、組織としてのポリシーを設定して「無視してよい脆弱性、CI/CDを必ず止めてリリースさせてはだめな脆弱性」まで踏み込んだ運用がコンテナセキュリティには求められます。
まだそこまでの機能はマネージドの仕組みとして対応されていないようですが、まずは今みなさんが運用されているイメージに対して、どのような脆弱性が潜んでいるのか理解するところから初めてみてはいかがでしょうか。脆弱性試験自体は非常に簡単に実施できます。
みなさんのコンテナワークロードを、セキュリティ観点で見直すきっかけとなれば良いですね。それでは、今日はこのへんで。濱田(@hamako9999)でした。
(参考)コンテナセキュリティ対策一般について
以前、書いた記事ですが、コンテナセキュリティ一般として必要なものがなにか、それらのドキュメントとフリーで利用できるツールをまとめた記事を公開しています。改めてこちらも参考にしていただければと思います。