CNDT2021、メルカリがマイクロサービスのセキュリティを強固にするための施策を解説
![](https://thinkit.co.jp/sites/default/files/styles/main_image_730x/public/main_images/19303_main.jpg?itok=ziIOHrix)
CNDT2021から、メルカリのエンジニアリング部門のマネージャーである中島大一氏によるマイクロサービスのセキュリティを強化するための施策に関するセッションを紹介する。
メルカリには「メルカリ」と「メルペイ」という2つの大きなサービスが存在し、それぞれがマイクロサービスとしてGCPの上のKubernetesに実装されている。合計200以上のマイクロサービスが、4000個以上のPodによって配備されているという。
メルカリは2020年のCNDTでもセッションを行っており、その際はメルペイ側のSREである高木氏が講演を行い、デベロッパー自身が運用まで行うという特徴的な体制について解説を行っている。今回の中島氏の講演でも、運用に専任しているエンジニアはおらず、プラットフォームの自動化などを行うエンジニアが存在するという内容を解説した。
メルカリ全体のセキュリティを強化するための施策について、3つのポイントに絞って解説を行ったのが今回のセッションである。基本はそれぞれのレイヤーにおいてのセキュリティを確保するだけではなく、多層防衛として複数のレイヤーに跨った深い防御を行うことが重要だと解説し、今回はその中から3つを紹介している。
開発環境におけるセキュリティ
メルカリのプラットフォームは、マルチテナントを前提としてKubernetesのネームスペースによって分離されている。その際に特権の付与については、最低限必要なものだけを与える「Least Privilege」を基本としているという。
これは実行環境であるKubernetesとアプリケーションをビルドするCI/CD開発環境においても適用されているおり、デベロッパーからビルドシステムへのアクセス、そしてビルドシステムからGCP上のKubernetesへのアクセスという2点において、最低限の特権を管理する方法が取られていると説明した。
Kubernetesにおいては、RBAC(Role Based Access Control)とネームスペースを使って特権の制御を実装していることを解説。リポジトリーについてはチームごとのにディレクトリー構造に分かれており、そのディレクトリーに対するアクセスを制限する方法を取っていると説明した。
リポジトリー内の特権の解説に続いて、Infrastructure as Code(以下、IaC)におけるセキュリティについて説明を行った。
この図ではIaCとして管理されているリソースの設定情報などについて、GitHubに対するPull Requestを使って修正や追加を行うことで、サービスチームが直接クラスターなどの設定情報にアクセスしない仕組みになっていることを説明した。
ここでは各サービスチームでは、CODEOWNERというロールを持つユーザーだけがネームスペース配下に構築されるリソースにアクセスできることを解説している。
ビルドシステムが持つサービスアカウントが大きな特権を持ってしまうことでリスクが高まることも認識しており、そのために長い時間を掛けてシステムを見直したことを説明。ここではビルドシステムの管理者アカウントが直接サービスの管理者特権を取得する方法ではなく、サービスにおける管理者アカウントに成り代わる形でサービス内のリソースにアクセスできるように設計していることを解説した。
このImpersonate機能によって、ビルドシステムがアクセスできる特権を必要最低限の範囲に制限できることを説明した。
本番環境におけるセキュリティ
次に本番環境におけるセキュリティについての解説に移った。
ここでは本番環境をエンジニアが直接操作するのではなく、IaCに関わるコードをリポジトリーの中で編集することでビルドシステムが環境を操作する方法を採用していると説明した。この方法は、Googleの社内のポリシーであるゼロタッチプロダクションを参考にしていることを紹介。また臨時にロールを与える機能を使うことで、通常の運用の90%の操作は実行できると解説したが、残りの10%、つまり緊急時にPodをリスタートさせたり、入れ替えたりという操作が必要になると説明した。
ここではそのような緊急の操作についてリスクを軽減するためのツールとして、Lyftが開発して公開しているClutchというツールを使ってリソースの可視化などを行っていると解説した。
Clutchについては以下の公式サイトを参照されたい。
Clutch:https://clutch.sh/
ソフトウェアのサプライチェーンにおけるセキュリティ
最後に、ソフトウェアのサプライチェーンにおけるセキュリティについて解説を行った。
ここではソースコードからビルド、クラスターへの配備までのプロセスにおいて、多くの危険な箇所が存在することを説明し、どこか一ヶ所が破られただけでシステム全体が危険に晒されてしまうことを強調した。
ここでもゼロタッチプロダクションと同様に、オライリーの書籍であるBuilding Secure and Reliable Systemsからの引用を行い、ユーザーではなく成果物に対する検証が必要であることを解説した。
ここではソースコードをビルドした成果物が、実際にクラスターに配備されるものと同一かどうかを検証するためのツールとしてKritisが紹介されている。KritisはGrafeasの一部として公開されているオープンソースソフトウェアだ。詳しくは、以下のInfoQの記事と公式リポジトリーが参考になるだろう。
参考:Software Supply Chain Management with Grafeas and Kritis
Kritis:https://github.com/grafeas/kritis/blob/master/docs/binary-authorization.md
ここではセキュリティの強化を後付けで行うことは非常に難しく、多くの時間と労力が必要になるというメルカリ自身の経験からのコメントがあった。許可しないリストをベースにセキュリティを実装するのではなく、許可することを選んでそれだけを使うような発想でシステムを構築するべきだと説明した。
またインフラストラクチャーが常に一定ということは有り得ないので、デベロッパーが使うレイヤーは抽象化して配下のインフラストラクチャーを直接操作するような手法は避けるべきだと解説して、セッションを終えた。実際にKubernetes上でマルチテナント、単一リポジトリーでIaCを実践しているメルカリの手法がそのまま多くの企業で応用できるかは分からない。しかし、マルチテナントなKubernetesに実装、許可リストから始めること、多層のレイヤーで防御を実装することなどヒントになる内容が多いセッションとなった。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- CNDT 2022、DMMのアーキテクトが解説するSREと開発の責任境界とリソース管理の実際
- CNDT2020シリーズ:メルペイのマイクロサービスの現状をSREが解説
- 「CloudNative Days Tokyo 2021」開催レポート
- KubeCon Europe前日のプレカンファレンスKubeSec Enterprise Summit
- CloudNative Days Tokyo 2019:メルペイのマイクロサービス化の目的とは?
- Kafka on KubernetesのStrimziConから新機能を解説するセッションを紹介
- CNDT2021、Kubernetesのマルチテナントを実装したIIJのSREが語る運用の勘所
- CNDT2021、パブリッククラウドを使ってゼロから勘定系を開発したみんなの銀行のセッションを紹介
- CNDO2021、Kubernetesがない世界とある世界の違いをインフラエンジニアが解説
- CNDT2020シリーズ:サーバーレスの現状と実装の苦労をメルカリのSREが語る