こんにちは。
はてなインターン2019 システム基盤開発コースでやったことをお話していきます。
今年のシステム基盤開発コースでは、コードネームphoenixと題して、「毎日生まれ変わるセキュアな踏み台サーバ」の作成に取り組みました。
なぜつくったのか
まずはじめに、なぜこのような踏み台サーバの構築を行うことになったのかについて説明します。
多くの現場でもそうであると想像されるように、現状のはてなでは様々な社内サービスや、稼働中のサーバー・データベースにアクセスするために踏み台サーバを経由する必要があります。はてなには種々のサービスが存在していますが、それらで踏み台サーバを共有しており、更にそれが長年連続稼働し続けていることもあって脆弱性への対応などの工数が嵩みがちでした。
サービス毎にAWSアカウントを分けて運用しようという動きもあり、この機にAWSアカウント毎に気軽に建てられ、またこれまでの踏み台サーバのように管理が大変になりすぎない、あたらしい踏み台サーバを準備することになりました。
踏み台サーバ
踏み台サーバの利用方法もチームやサービスによって様々でしょうが、最低限、どのような踏み台サーバにでも求められる要件はできるだけセキュアであることと、踏み台サーバを経由してそのサービスで利用しているサーバやデータベースなどにアクセスできるということでしょう。
後者はどの様にネットワークを構築するか、という話になるので今回はスコープ外として、踏み台サーバがセキュアであるためには、
- 古い状態で放置しないこと
- 余計なアプリケーションが放置されていないこと
- 余計なポートをあけたり余計なネットワークに接続してしまわないこと
が必要です。
今回はこの要求を満たすべく、毎日生まれ変わる踏み台サーバを、ECS上のコンテナとして実現しました。
なぜ毎日生まれ変わるのか
今回リプレースの必要が出てきたように、踏み台サーバを連続で稼働し続けると年月の移ろいに伴ってサーバの内容は老朽化していきます。そこで今回構築する踏み台サーバでは、1日と踏み台サーバの生存期間を区切ってしましました。毎日あたらしいコンテナが踏み台サーバとしてデプロイされ、日々最新のアプリケーションが提供されます。
これにより、古いアプリケーションがずっと稼働し続けて負債になるという状況を防ぐことができます。また、一つの踏み台サーバが長く動いていると、それを止めてあたらしいものを用意するためには大きな心理的抵抗が生じます。毎日踏み台サーバが生まれ変わることで、この心理的抵抗をなくす狙いもあります。
なぜコンテナを使ったのか
一般に踏み台サーバとなると、EC2インスタンスのようなものを建てっぱなしにするものですが、今回は毎日新しくなるものを作るため、デプロイの容易性を考えてコンテナの利用を決めました。コンテナでも十分に踏み台サーバとしての役割を果たすことができ、ECSによる管理ができるので、踏み台サーバを更新するためのシステムの構築が容易になります。
また、コンテナの内容はDockerfileに記述されるため、踏み台サーバの利用用途に合わせてカスタマイズすることができ、サービス毎にこの踏み台サーバを導入するための障壁が減ります。
踏み台サーバを更新する仕組み
AWS CodePipelineを用いたCI/CDが毎日走って、コンテナが更新されます。このパイプラインでは、CodeCommitリポジトリからDockerfileを取得してこれをビルド、できあがったDockerイメージをECRにプッシュして、Blue/Greenデプロイを行って踏み台サーバのコンテナを置き換えています。踏み台サーバとなるコンテナをECSで管理していることによって、更新が容易になっています。
SSMセッションを用いたログイン
今回構築した踏み台サーバでは、AWS Sytem Managerが提供するSession Managerを用いたログインを行うようにしています。SSM(AWS System Manager)セッションを用いたログインはEC2インスタンスなどをAWSコンソールやAWS CLIから操作できるSSHのようなものですが、これはインスタンス内のssm-agentというプロセスが適切に働くため、セキュリティグループにインバウンドの許可設定を与える必要がない点がとても魅力的です。また、SSMによるセッションはCloudTrailに記録されるため、いつログインがあったのかや、どこからログインされていたのかなどの証拠の記録も行うことが出来ます。そのうえSSMを用いることで、踏み台サーバにログインできる人をIAMベースで管理することができるので、踏み台サーバのような用途ではぜひSSMセッションを用いたログインを使いたいと思いました。
SSMセッションを用いたログインを利用するためにはアドバンストインスタンス層を有効にする必要はありますが、ssm-agentさえ動作していればオンプレミスのサーバやコンテナでも利用できるため、今回の踏み台サーバにはこれを導入しました。
SSMセッションを用いたログインはSSHセッションを開始することとは異なるため、従来のコマンドをそのまま利用することは出来ませんが、SSMセッションの上にSSHコネクションを張ったログインができるので従来と変わらない感覚で踏み台サーバを利用できそうです。
CloudFormationによる自動デプロイ（未完）
この踏み台サーバとその更新の仕組みを気軽にデプロイできるようにするため、CloudFormation化にも取り組みました。しかし様々な罠が待ち受けており、すべてを一度にデプロイできるようなCloudFormationの構築を行うことは出来ませんでした。
特に、CloudFormationではBlue/Greenデプロイまわりで対応していない部分が多く、CI/CDパイプラインの自動構築を諦めることになり、その上、パイプラインを手動やAWS CLIで構築するとしてもECSのサービスを作成する際に、デプロイメントコントローラーとしてCodeDeployを用いることができないのでここも手動で構築しなければならなくなってしまいました。
Terraformによる自動デプロイ
一方TerraformではBlue/Greenデプロイまわりも合わせて自動化できそうという感じだったので、CloudFormationのテンプレートを少しずつTerraformに移植しました。こちらでは、踏み台サーバの構築も、CI/CDパイプラインの構築も自動化することができ、コマンド一つでより気軽に踏み台サーバを使っていただける準備を整えることが出来ました。
感想など
今年のシステム基盤開発コースでは、毎日生まれ変わるセキュアな踏み台サーバの構築と、自動デプロイのためのテンプレート作成を行いました。作ったものの性質上、今すぐ使われるものを見ることはできないのですが、少しずつでも今回の成果がはてなの基盤を良いものにしていってくれればと思っています。
