runc脆弱性に対応するためにうっかりECSからFargateにしました

こんにちは、ソーシャルゲーム事業部ゲーム技研チームの谷脇です。今日は一石n鳥の話、もしくは桶屋が儲かる話をします。

この記事はTech KAYAC Advent Calendar 2019 Migration Trackの2日目の記事です。1日目はMongoDBであるメリットが無くなってしまったのでMySQLに移行したはなしでした。

TL;DR

カヤック社内で内製の開発版スマホアプリを配るための配信プラットフォーム「alphawing」を開発・運用してます
alphawingはEC2上で動くAmazon ECS(以下ECS)で動いていました
コンテナランタイムruncでの脆弱性 CVE-2019-5736 がでてきたのでどうしようどうしようとなりました
そのあと様々な検討があり、えいやっとAWS Fargate(以下Fargate)に持っていきました

背景

ゲーム技研チームではソーシャルゲーム事業部内で使われる開発に便利なグッズを作ったり、運用が必要であれば運用を行うことをやっています。

OTAツール、alphawingもその一つです。自動ビルドされる開発版アプリのアップローダとしての機能、スマートフォンから閲覧してダウンロード及びインストールをする機能を持ったWebアプリです。

f:id:mackee_w:20191202120824p:plain

こういった、開発に便利な社内サービスを集積して運用するために、カヤックではAmazon ECSを使っています。細かい生活の知恵グッズを多数運用するときにもこういった本番コンテナサービスは便利です。

runc脆弱性 CVE-2019-5736

以下の記事が詳しいです。

runcの脆弱性情報(Important: CVE-2019-5736) - OSS脆弱性ブログ

要約すると、Dockerなどで使われるコンテナランタイムruncにホスト側rootでコマンド実行出来る脆弱性です。

そこそこ簡単に特権昇格できる脆弱性なのでさっさと対応してしまいたいところです。ゲーム技研チームで対応を検討し始めました。

terraform管理していたはずだがtfstateが失われたので...

alphawing自体は2015年頃から運用されているアプリケーションです。私も2代目ぐらいの開発担当者で、開発当初の状況はあまり知りません。とはいえ、昨年にアプリケーションコードを全面的に書き直して移行も成功したため、大体の構成の把握はできていると自負していました。それが間違いだったのですが。

runc脆弱性対応を行う手法としてまず検討したのは、正攻法ですが、コンテナインスタンスのAMIを脆弱性対応済みのものに入れ替える手法です。そして、社内で動き続けているサービスの性として、できるだけ停止時間を短くする必要もあります。そこで、別のコンテナインスタンスを新しく立ててECSクラスタに入れた上で、新しいインスタンスの方にコンテナを立てた上で、古いインスタンスを停止という方向に持っていく算段でした。

が、しかし...

手で新しいEC2インスタンスを立てようとしたら古いインスタンスのタグにmanaged by terraformという文字列を見つける
terraformで使う状態管理ファイル.tfstateを探すがS3のバケットにもGitHubのリポジトリにもない

というわけで、インフラの管理方法は失われてしまっていたようです。

新しいAMIを起動するだけのはずなので、おそらくterraformも簡単に作り直せるはずです。ただ、そっちにいくのではなく...

f:id:mackee_w:20191202121305p:plain

と、SREチームの組長に背中を押されてFargateに切り替えるぞとなりました。

理由として、AWS Fargateがある今、このサービスでEC2を使うECS構成を作るメリットが見出だせなかったことがあります。

ECSとFargateの違い

次のスライドの始めの方に詳しいことが図解されています。

第1回 AWS Fargate かんたんデプロイ選手権 #AWSDevDay

ECSを使う場合は、ECSのコンテナの管理の他にEC2インスタンスの管理も必要です。EC2インスタンスの管理の中には今回のような脆弱性対応も含まれます。

一方、AWS Fargateを使う場合は、EC2インスタンスに当たるような実行環境は使う側からは見えなくなり、AWSの管理に委ねられます。いわゆるフルマネージドサービスと呼ばれるものです。そして、AWSが行う「管理」とは、脆弱性に対応するためのパッチ当ても含まれます。

その違いを、今回の脆弱性に対応する人向けにAWSから出された文章から抜き出してみます。

ソース

Amazon Elastic Container Service (Amazon ECS)

Amazon ECS Optimized AMIs, including the Amazon Linux AMI, the Amazon Linux 2 AMI, and the GPU-Optimized AMI, are available now. As a general security best practice, we recommend that ECS customers update their configurations to launch new container instances from the latest AMI version. Customers should replace existing container instances with the new AMI version to address the issue described above. Instructions to replace existing container instances can be found in the ECS documentation for the Amazon Linux AMI, the Amazon Linux 2 AMI, and the GPU-Optimized AMI.

ECSの場合は使っているAMIを入れ替えてねと書かれています。

AWS Fargate

Customers running Fargate Services should call UpdateService with "--force-new-deployment" enabled to launch all new Tasks on the latest Platform Version 1.3. Customers running standalone tasks should terminate existing tasks, and re-launch using the latest version. Specific instructions can be found in the Fargate update documentation.

AWS Fargateの場合は、aws-cliで--force-new-deploymentをつけてserviceを更新すれば、勝手にアップデートされるよと書かれています。alphawingであればecspressoを使っているので、単にデプロイを行えば同じような効果が得られます。

というわけで、ある程度マネージドなサービス(ECS)と、フルマネージドサービス(Fargate)の違いが実感できます。

今回の脆弱性と同じようなことがあっても、Fargateに移行しておけば簡単に対応できることが期待できます。

移行作業

ecspressoを使用していたので、ecspressoで使う設定用JSON書き換えと、ALBからの向き先入れ替えが主な作業になります。Fargateが動く新しいECSのServiceを作って並列動作させた上で、古いServiceを停止して無停止で移行できました。

service definition
- launchType を FARGATE に書き換え
task definition
- networkMode を bridge から awsvpc に書き換え
- Fargateはawsvpcしかサポートしていないため
ALB
- Fargate用のtarget groupを作ってALBに登録