Glide Note

glidenote's blog

ChatOpsでOSのセキュリティアップデートを自動化出来るようにした

先日@naoya_itoさんが自身のブログ(インフラの継続的デリバリー)KAIZEN platform Inc.のインフラについて書いていたやつの続編的な内容。

TL;DR

  • Chat(Slack) + Hubot + CircleCI + GitHub を用いてセキュリティアップデートを自動化した
  • GitHubのPull Requestを契機にセキュリティアップデートを実行できるようにした
  • CircleCIが大変便利。インフラ系の作業を自動化するのに非常に合っている気がする

背景

KAIZEN platform Inc.では、

  1. ネットワーク脆弱性スキャン
  2. アプリケーション脆弱性スキャン
  3. セキュリティアップデートの定期実行

の3つをセキュリティ系タスクとして継続的にやっていこうという話になり、今回は私が担当した、「セキュリティアップデートの定期実行」の話。

RHEL系OSにはyumの自動更新機能がありますが、これが稼働していて意図せずミドルウェアがバージョンアップして、 過去にみんな痛い目に遭遇した経験があるので、これは利用せずにアップデートの内容を事前に確認したいという事情もあります。

仕組みの詳細

全体の流れ

  1. 定期的にHubot自身が、Chat(Slack)上からHubotにSecurity Checkを指示する(今回はキャプチャを取るために私が召喚してます)
  2. Hubot経由でCircleCIのAPIを叩いて、Security Update用リポジトリ上にチェック用ブランチを作成して、GitHubにPush
  3. GitHubへのPushを検知して、CircleCIが検証環境であるQA環境のサーバに対して、sshしてyum --secuity check-updateを実行
  4. セキュリティ更新があれば、下記のようなデプロイ用ブランチへのPull Requestを作ってインフラメンバーにmentionを送る。無ければそのまま終了。
  5. インフラメンバーがPull Request内容を確認して、問題が無ければMerge。
  6. デプロイ用ブランチへのMergeを契機に対象サーバについてyum --security -y updateがかかり、セキュリティアップデートがかかる
  7. アップデート後にCircleCI経由でSlack上のHubotを召還
  8. Hubot経由でe2eテストが自動で走り、セキュリティアップデートによって、アプリケーションに不具合が発生していないかテストされる
  9. e2eテストに問題が無ければ、Production環境のサーバ向けに2-8の手順を繰り返す
  10. 最終的には下記のように、どのサービス、どのステージでセキュリティアップデートが完了したかが通知される
  11. 寿司を食う

この一連の流れが各ロール(web,log,proxy,batch等々)のサーバ数十台に対して一斉に自動で走ってくれて、 進捗報告もChat(Slack)に都度通知されるようになっている。

人の手を介するのは5のセキュリティアップデート内容のレビューとMergeボタンを押す部分だけ。

naoyaさんのブログから画像を拝借すると、セキュリティアップデートの適用もMergeボタンに集約された感じ。

これにより

  • 定期的なセキュリティアップデートのチェックを自動化
  • セキュリティアップデートをPull Requestでレビュー可能に
  • CircleCI経由で実行することで、CircleCI上に作業ログの保存

が出来るようになった。

CircleCIについて

CircleCIには

  • ssh鍵やTOKENがセキュアに渡すことが出来る
  • 実行ログが残せる
  • Chat系アプリと簡単に連携できる
  • UIが直感的で分かりやすい
  • CircleCI自体にssh出来るので、デバッグが簡単に出来る

という特徴があるので、インフラ系の作業を自動化するのには非常に合っていると思う。(某OSSなCIツールで同じ事をやろうとすると、そこまで行くのにいろいろと設定が必要でyak shavingな感じが…)

私が担当した以外のセキュリティ系タスクも自動化がされているし、 Chefの適用、セキュリティスキャンなどChatOpsの範囲が広がってきて、最近はサーバにほとんど入らなくなってきているので もっと頑張れば寿司だけ食っていれば良い世界が来るかもしれない。

Comments