[セッションレポート] EC2からKubernetesへの移行をセキュリティ/モニタリングから考える #jawsdays #jawsug #jd2019_e

02/23 に開催されました JAWS DAYS 2019 、Eトラックで行われた下記セッションをレポートします。freee株式会社の杉浦さん・河村さんのお二人による、Kubernetes (k8s) 環境におけるセキュリティの考え方と守り方、監視システムについての興味深い発表が行われました。

• EC2からKubernetesへの移行をセキュリティ/モニタリングから考える | JAWS DAYS 2019

スピーカー

• 杉浦 英史さん - freee株式会社 CSIRT
• 河村 篤志さん - freee株式会社 SRE

freeeは創業6年のcloud nativeな会社です。 会計や人事情報という機密情報を扱う難題に立ち向かいつつ、スタートアップらしく、素早く、そして、しなやかに前に進み続けなければなりません。

セッション前半は、EC2 instanceで運用してきたサービスを、Kubernetesに移行する作業を通して、可能な限りの最高速でシステムを実装しつつセキュリティを担保するために、どう考えてきたかを紹介したいと思います。

セッション後半は、freeeのKubernetesクラスタを日々見つめる、Elastic Stackを用いたモニタリング基盤を紹介します。

(前半) EC2->k8s移行をセキュリティから考える

「スタートアップらしくリスクは取り、高いセキュリティも実現する」

• どうしてセキュリティが大切なのか
• EC2のときにセキュリティをどう考えていたか
• k8sになってどう考えるようになったか
• freee
• ミッション：「スモールビジネスを、世界の主役に」
• 最新テクノロジーでデータを収集
• 生の経営情報が収集される
• これまでは Viewer （= データに対し閲覧するだけ）として動いていた
• アプリストア -> プラットフォームへなろうとしている
• 電子決済代行第一号
• Fintechの先頭を走っているという自負
• 画像データ -> 匿名化が難しい
• 機械学習 -> データの集積

EC2をどう運用していたか

• AWS = 責任共有モデル = OSから上は自分で守る
• freee はサービス開始当初からCloud上で動かしていた
• 物理的（地理的？）な制限からは解放
• (サービスに対する)想定攻略経路 / Cyber Kill Chain
• 多層防御
• Proactive Defence
• Discover logをとる、履歴を残しておく
• Detect 異常値を検知する
• Active Defence
• Deny 止める - FW,IPS,packet drop
• Disrupt 妨害する - Anti Mulware
• Degrade 時間稼ぎ - Ratelimit
• Decieve 攪乱する - HoneyPot
• Destroy 破壊する - 警察に通報

EC2インスタンスを守るのは自分たち

• WAF、DeepSecurity、GuardDuty
• OneLogin
• クレデンシャルを文字列で配ることは止めた
• 内部探索 (WIP)
• VPC flow logでrejectをとる？
• やみくもに内部探索する痕跡を捉えよう
• 奪取 / インターネットへの情報漏洩
• データを持ち出されるのを防ぐ
• Outbound any open をやめる、必要以外は閉じる (WIP)
• ログ
• インシデントレスポンス
• イベントドリブン（Slackからの通知）
• S3にあつめてSlackに通知をとばす
• トリアージ / 調査・解析
• 対策が必要か考える
• 誤検知？
• freeeはセキュリティ担当・開発担当とわけていない
• みんなで考える・対応する
• 修正
• アプリケーション
• (WAF)シグネチャ
• ACL
• 評価・予測
• 現在はイベントドリブンでしかない
• インテリジェントドリブンにしたい
• AWS WAF の進化
• WAF フルログが取れる = 攻撃の流れがわかる
• マネージドルールはblackbox
• WafCharmはシグネチャがwhitebox = どこでなにが引っかかったのか分かる！
• DeepSecurity
• Alert -> syslogに吐いてfruentdでひろってS3でslackへ -> 1分程度で通知が来る
• SQSだと20分くらいかかる
• GuardDuty
• 転ばぬ先の杖
• 検知まで数時間かかる、即時性はない
• (即時影響のない)設定忘れなどを早めに指摘してもらえるのはありがたい

マイクロサービスへ移行

• エンジニアが100名超えた
• デプロイが大変
• k8sになっていろいろ考えないと
• kube-awsだとつらみ多かった
• OSがCoreOS = DeepSecurityが使えない！
• EKSがきた
• コントロール部分をマネージドに
• Amazon Linux つかえる = DeepSecurityが動く！
• OneLogin + Session Manager で管理
• 内部探索・情報漏洩への対策 (WIP)
• system call logging + alert
• Sysdig
• Kubernetes & Docker Monitoring, Container Security, & more | Sysdig
• Falco
• Falco - Container Native Runtime Security
• cilium
• API-aware Networking and Security | Cilium
• ekscli
• weaveworks/eksctl: a CLI for Amazon EKS
• kubectl の嵐を解決
• shingle cluster
• Cluster : Namespace = 1:1
• 運用がシンプルになった
• Network Policy
• サービスに必要なものだけを許可
• IAM / RBAC
• 1:1 マッピング
• Cluster Auto Scaling
• 1サービスのことだけ考えれば良い
• Cluster B/G deploy (WIP)
• 3/15 までにeksctl k8sに移行予定（絶賛deploy中）

まとめ

• ClouｄNative
• freeはAWSと共に
• 多層防御
• ログを取り、アラートを出して
• Incident Response
• kube-aws
• multi namespace
• EKS/eksctl
• single namespace
• managedでできるものはmanagedで
• 本質的価値のあるものへ開発に集中
• 車輪の再発明はしない

(後半) freeにおけるKubernetes監視基盤の紹介

• (編集注：おそらく関連する記事)
• Elastic StackによるKubernetesモニタリングシステムの紹介 - freee Developers Blog

監視とはなにか、なぜ監視するのか

• 入門「監視」より
• "あるシステムのコンポーネントの振る舞いや出力を観察しチェックし続ける行為"
• 予防保守
• ちょ会将来起こりうる問題を監視システムで救い上げる
• 異常検知
• サービス・ビジネスの継続に係わる障害の場合、最速で復旧させる必要がある
• そして少なくとも、発生している問題にすぐに気付けることが重要
• 改善指標
• 何か新しい施策を入れたとしても、metricsが取れていなければ効果を計れない

監視システムに求められるもの

• 必要なコンポーネント
• データ収集
• ストレージ
• 可視化
• 分析
• アラート
• 正しい監視をする
• コスト
• 継続的改善が可能

k8sでの監視要件

• 監視対象
• クラスタ、クラスタノード、pod
• 多様性
• freeeではpodは大量かつ多様、個々で設定するのは不可能
• 自動スケール

Elastic Stack を使って監視する

• オープンソースのElastic Stack（Elasticsearch、Kibana、Beats、Logsatsh）でリアルタイムな検索と分析 | Elastic
• Elasticsearch = Data store
• Kibana = Visualize
• Logstash = ETL tool
• Elastic Beats = Data Collector
• "Lightweight Data Shippers"
• Filebeat = log収集
• Metricbeat = メトリック収集
• その他 : Packetbeat, Winlogbeat, Auditbeat, Heartbeat, Functionbeat

• Elastic Cloud
• Elasticsearch Service | AWS、GCPで使えるマネージドサービス | Elastic
• Elastic Alertが使えるのがうれしい
• アラート | データの変化を検知、通知を受け取る | Elastic
• (料金については)高いが、Amazon ESと比べて2倍はしない
• k8s から集められたデータは Kinesis で S3 と Elasticsearch の両方に
• S3 に長期保存・分析
• Elasticsearch は短期保存（1ヶ月）、検索、可視化
• filebeats
• 標準出力ではかれるログを（勝手に）外に送る = アプリは何も考えなくていい
• helm chart あります
• filebeats + kibana
• どこで何が発生したか
• どのPodがどのログをはいたか
• metricbeat
• nodeごとに配置する
• クラスタメトリクスは kube-state-metrics のデプロイが必要
• kubernetes/kube-state-metrics: Add-on agent to generate and expose cluster-level metrics.
• node / pod単位のcpu/memory/network/storageなどが取れる
• • Kibana
• • Dashboard
• アラート
• 優勝パッケージには Kibana と統合されたアラート機能がある
• 自前でホスティングする必要あり
• OSS : ElastAlert
• 構築方法 1 : k8s cluster 内にdeploy
• 方法 2 : AWS Lambda
• 方法 3 : ECS にデプロイ
• 今は方法 3 を検証中

良かったこと

• 導入が楽
• logとmetrics管理を共通化
• Kibanaの柔軟なクエリ(lucene)

微妙

• KibanaのVisualizeはまだexperimentな機能がいくつかある
• VisualizeのDashboardを作るのに慣れが必要
• luceneが自由度高すぎる
• ダッシュボードのexport/importで乗り切る
• ElastAlertの設定難易度高い
• beats系でたまにバグを踏む（修正は早い）
• 監視システム自体の監視
• Elasticsearchの容量枯渇
• Kinesis設定ミス
• ログ基盤

今後

• 別方法の模索
• コンポーネント単位での置き換えは容易
• 他のデータ収集ツール
• apm serverやheart beatなど
• 権限委譲の仕組みをすすめる

所感

会計というクリティカルな情報を扱うシステムだけに、高度な技術力でセキュリティやシステム監視が行われている実態を垣間見ることができました。特に Elastic Stack を使った監視システムについては、個人的に先日、同様の方向性を持つ Sumo Logic の講習を受けてきただけに、その必要性やつらみが伝わってきて興味深かったです。