ZOZOにおけるID基盤のk8sへのリプレイスとセキュリティの取り組み / Authentication service replacement and security efforts of zozotown(CNDT2020)

ZOZOにおける 
ID基盤のk8sへのリプレイスと 
セキュリティの取り組み 
 
株式会社ZOZOテクノロジーズ 
SRE部 
リーダー　瀬尾直利 
エンジニア　亀井宏幸 
Copyright © ZOZO Technologies, Inc.

View Slide

© ZOZO Technologies, Inc.
瀬尾直利 (そのっつ) 
株式会社ZOZOテクノロジーズ
2019年1月入社 SREスペシャリスト
SRE部 ML-SRE リーダー兼
SRE部プラットフォームSRE リーダー兼
CSIRT
Twitter/GitHub: @sonots
CRuby、Fluentd コミッタ
2

View Slide

https://zozo.jp/ 
● 日本最大級のファッション通販サイト 
● 1,300以上のショップ、7,400以上のブランドの取り扱い（ともに2019年12
月末時点） 
● 常時73万点以上の商品アイテム数と毎日平均3,200点以上の新着商
品を掲載 
● 即日配送サービス 
● ギフトラッピングサービス 
● ツケ払いなど 
3

View Slide

アジェンダ 
● ZOZOTOWNリプレイスの全体感 (そのっつ) 
● ID基盤の概要 (以降、亀井) 
● 更新系ワークロードのリプレイス方法 
● AWS/EKSで実施したセキュリティへの取り組み 
● 課題と今後 
4

View Slide

ZOZOTOWNリプレイス
5

View Slide

6
2004年 ZOZOTOWN オープン

View Slide

7
ZOZOTOWNはアーキテクチャを変えずに規模を拡大してきた

View Slide

IIS (Web)
RO
iOS Android
ブラウザ
PC/SP
リプレイス開始前: 〜2017年
ストアドストアドストアド
8
IIS (API)
ロジックがDBに載ってい
る（ストアド）
成功
● データの近くで処理を行うため高速（特に2005年
当時はネットワークが細い)
● ロジックをDBに載せることでDRYにできる
課題
● ストアドをスケールさせづらい
● ストアドのテストが書きづらい
● レガシー VBScript
● Windows Server の構築自動化が難しい
● 現実問題、ASPレイヤーで２重管理になっている
ロジックは存在する

View Slide

9
2017年4月

View Slide

10
2017年当時のリプレイス計画

View Slide

Java API
Read Only
SQL
ストアドをら
はがしてAPI
に移設
第１フェーズ: 2017年〜2020年参照系ロジックのストアド剥がし
11
IIS (Web)
RO
iOS Android
ブラウザ
PC/SP
Read Only
IIS (API)
DBレプリ
課題
● ASPレイヤーのロジックがそのまま
● 更新系のリプレイスが未計画
● オンプレIISが入り口のままであるためオ
ンプレを卒業できない設計
Read Only
成功
● ストアドロジックが減った
● クラウドに移設したことでスケーラビリティ
を手にいれた (ECサイトは参照リクエスト
が圧倒的に多い)
ZOZO DC クラウド

View Slide

既存の課題解決と
ZOZOTOWNリプレイスを加速させるため
新アーキテクチャと新体制
の計画をスタート
12
2020年1月
そのっつ参画

View Slide

リプレイスプロジェクト加速にあたって必要なこと
● リプレイスの目的の統一
● 最終的なアーキテクチャのイメージの刷新
● リプレイス作業への開発リソース確保
13

View Slide

改めて目的を再確認。
なぜリプレイスするのか
14

View Slide

改めて目的を再確認。なぜリプレイスするのか
ZOZOTOWNの成長のため
スピード
をあげる
コスト
をさげる
人材
をふやす
これらを達成できる組織にする
15

View Slide

2020年度、リプレイスプロジェクトで進めること
まず、変更しやすくしたい。
1. ストアドはがし（継続）
2. マイクロサービスの立ち上げ
16

View Slide

新フレームワーク
ロジック
（Web表示のみ）
商品
サービス
RO
お気に入り
サービス
RW
メンバー
サービス
RW
ネイティブアプリはAPI
直呼び出し
ブラウザ
PC/SP
iOS Android
WebのUIに
新技術が使える
ようになる
それぞれのAPIが
独立したサービスに
= マイクロサービス化
API Gateway
ID認証
サービス
RW
17
第２フェーズ: 目指す姿

View Slide

商品
サービス
RO
お気に入り
サービス
RW
メンバー
サービス
RW
API Gateway
ID認証
サービス
RW
18
IIS (Web)
RO
ブラウザ
PC/SP
IIS (API)
ZOZO DC
第２フェーズ (2020年〜進行中) 切り替え方法 (ストラングラーパターン)
iOS Android
切り替え
切り替え
DBレプリ
クラウド

View Slide

この1年でマイクロサービスの完成形テンプレートを作る
19

View Slide

アーキテクチャを反映した、開発しやすい組織体制に移行
ロジック
ユーザー
サービス
RO
お気に入り
サービス
RW
商品
サービス
RW
API Gateway
ID認証
サービス
RW
20

View Slide

組織
21
「マイクロサービスは組織論である」

View Slide

ECプラットフォーム部 / プラットフォームSREの設立 (4月)
EC開発本部
ZOZOTOWN
フロントエンド
バックエンド
アプリ
ZOZO
技術開発本部
ECプラットフォーム部
基幹 MSP USED CHINA
SRE部
検索マイグレーション API基盤推薦基盤
サービス
MLOps
MA BtoB USED
PF-SRE
グロース
EC開発本部と一緒にマイクロサービス化を進めていく
22

View Slide

● 我々は、ZOZOTOWNがこれからも成長を続けるために、開発効率・運用性・
堅牢性・柔軟性・回復性の確保を見据えて、技術面でも環境面でもクラウドネイ
ティブに刷新するための取り組みを進めます。
● 巨大でピーク性のある大規模ECシステムを、最適なアーキテクチャをチームで
思い描きながら設計・構築・リリース・運用まで一環して行い ZOZOTOWN の
成長を加速させることがミッションです。
23
23
プラットフォームSREのミッション 

View Slide

● マイクロサービスプラットフォーム Kubernetes クラスタの設計
● API Gateway 経由のアーキテクチャに変更
● ID基盤のリリース (更新系リプレイス第一弾)
● 第一弾として検索機能を Front API から切り出してマイクロサービス化
24
プラットフォームSRE今期 (2020年4月〜9月) 
24

View Slide

25
25
2020年3月

View Slide

26
26
＊マルチクラウドやめました
今期目標

View Slide

ZOZOにおける 
ID基盤のk8sへのリプレイスと 
セキュリティの取り組み (後半) 
 
SRE部 
リーダー　瀬尾直利 
エンジニア　亀井宏幸 
Copyright © ZOZO Technologies, Inc.

View Slide

SRE部 
亀井宏幸 
2017年9月にZOZOテクノロジーズに中途入社。ZOZOTOWN
のオンプレサーバ運用を経て 
2019年9月にPF-SREチームへ、 
パブリッククラウド・k8sを初体験しながら 
ZOZOリプレイスに携わっている。 
28

View Slide

SRE部 
亀井宏幸 
2017年9月にZOZOテクノロジーズに中途入社。ZOZOTOWN
のオンプレサーバ運用を経て 
2019年9月にPF-SREチームへ、 
パブリッククラウド・k8sを初体験しながら 
ZOZOリプレイスに携わっている。 
29

View Slide

アジェンダ 
● ZOZOTOWNリプレイスの全体感 (そのっつ) 
● ID基盤の概要 (以降、亀井) 
● 更新系ワークロードのリプレイス方法 
● AWS/EKSで実施したセキュリティへの取り組み 
● 課題と今後 
30

View Slide

お話ししないこと 
● アプリケーションの説明 
● k8sクラスタの構築内容 
● IaC、CI/CDの手法 
31

View Slide

ID基盤の概要 
32

View Slide

の前に、API Gateway について 
33

View Slide

API Gateway 
● API の Gateway となるマイクロサービス 
● マイクロサービス化にあたりID基盤に先行してリリース済み 
● API コントローラー、SSL終端などの役割をもつ 
 
34
ロジック
ユーザー
サービス
RO
お気に入り
サービス
RW
商品
サービス
RW
API Gateway
ID認証
サービス
RW
これ

View Slide

API Gatewayは自前で実装 
● AWS にはマネージドサービスの API Gateway がある 
● 複雑な要求に柔軟に対応するために自前実装 
○ エンドポイントを複数もつサービス(マルチクラウド/マルチクラスタ)に対し、 
エラーやタイムアウト時に別エンドポイントへのリトライ 
○ ヘッダー (Client-Token) によるクライアント認証機能 
など 
● AWS/EKSで構築 
35

View Slide

改めて、ID基盤とは 
36

View Slide

ZOZOTOWN におけるID基盤 
● ZOZOTOWN は ZOZO ID という認証システムがある 
● ID基盤は ZOZO ID のモダン化リプレイスプロジェクト 
● PF-SRE のマイクロサービス第二弾 (話せば長くなる) 
37

View Slide

ID基盤の特徴 
● 更新系ワークロードを扱う 
○ 更新系 : 会員登録/更新/退会()
○ 参照系 : ログイン/トークン発行/トークンリフレッシュ
など 
● 個人情報も扱う 
○ email 
○ password 
○ phone 
38

View Slide

○ 更新系 : 会員登録(insert)/更新(update)/退会(delete )
など 
○ email 
○ password 
○ phone 
39
ZOZOTOWNにおける 
更新系ワークロードの 
リプレイス第一弾 

View Slide

○ 更新系 : 会員登録/更新/退会()
など 
○ email 
○ password 
○ phone 
40
高セキュリティの 
インフラが求められる 

View Slide

求められた要件 
● クラウドネイティブ化 
● マイクロサービス化 
● CI/CD (Continuous Integration / Continuous Delivery) 化 
● IaC (Infrastructure as Code) 化 
● 開発ガイドライン(社内ガイドライン)のセキュリティ要件の遵守 
41

View Slide

従来のアーキテクチャ 
● オンプレミスで構成されていた 
42
FW / WAF
Load Balancer
オンプレミス
Web Server
(IIS)
DB Server
(SQL Server)
● 巨大でモノリシック 
● Web Server は Classic ASP で実装さ
れ多数の細かいサービスが混在 
● DB Server は用途ごとに物理的にイ
ンスタンスが分割されているものの、
多数の細かいサービス用のテーブル
が混在 
※簡易的なアーキテクチャ図です 
TCP : xxx

View Slide

ID基盤の全体アーキテクチャ 
● AWS で構成している 
43
API Gateway
ID基盤
VPC1
VPC2
Peering
ALB
ALB
EKS
Cluster2
EKS
Cluster1
● マイクロサービスアーキテクチャ 
● 極力マネージドサービスを利用 
○ ALB 
○ EKS 
○ Aurora MySQL 
● API Gateway と 
AWSアカウントを分離(後述) 
Account1
Account2
Aurora
MySQL
※簡易的なアーキテクチャ図です 
HTTP

View Slide

ID基盤のソフトウェアスタック 
44
● アプリケーション 
○ Golang 
● インフラ(AWS) 
○ Route 53 
○ Application Load Balancer (ALB) 
○ Elastic Kubernetes Service (EKS) 
○ Aurora MySQL 
Route 53 ALB
EKS Aurora MySQL
CloudFormation
CloudWatch APM
slim

View Slide

EKS (Elastic Kubernetes Service) 
● AWS のフルマネージド型の Kubernetes (以後 k8s) サービス 
● コントロールプレーンの管理は不要 
● EC2マネージドノードグループを採用することで、 
ワーカーノードの構築、運用負荷も最小限 
● k8s のメリットを享受できる 
○ オートスケールや自動修復 
○ コントローラーによる高い拡張性・柔軟性 
 
クラウドのメリットを最大限活用するため、EKSを採用 
45

View Slide

Aurora MySQL 
● フルマネージド型でMySQL互換のRDSサービス 
● 高い可用性 
○ データは99.99%の可用性 
○ レプリカへのフェイルオーバーは約30秒程度 
● LTS (Long Time Support) バージョンが用意されており 
最低限のバージョンアップ頻度としダウンタイムを最小化できる 
 
 
MySQL互換であり高い可用性から、Aurora MySQLを採用 
 
46

View Slide

ID基盤概要のまとめ 
● ID基盤 = 新 ZOZO ID 
● オンプレ→クラウドへ、初の更新系リプレイス 
● マイクロサービス第二弾 
● AWS/EKS/Aurora で構築 
● API Gateway と AWS アカウントを分離(後述) 
47

View Slide

更新系ワークロードの 
リプレイス方法 
48

View Slide

やりたかったこと 
● サービス停止はしない 
○ データ更新が継続したままでのリプレイス 
● オンプレSQL Serverのデータを、ID基盤のAurora MySQLへ移行 
● 再設計されたテーブル構造に対応した形に変換しデータ移行 
 
 
49
FW / WAF
Load Balancer
オンプレミス
Web Server
(IIS)
DB Server
(SQL Server)
API Gateway
ID基盤
VPC1
VPC2
Peering
ALB
ALB
EKS
Cluster2
EKS
Cluster1
Account1
Account2
id, email, pasword
...

View Slide

今までのリプレイス方法 
● 参照系ワークロードの例 
○ SQL Server to SQL Server 
○ サービス停止はしない 
○ SQL Server レプリケーションでデータを移行 
 
50

View Slide

今までのリプレイス方法 
● 参照系ワークロードの例 
○ SQL Server to SQL Server 
○ サービス停止はしない 
○ SQL Server レプリケーションでデータを移行 
 
● ID基盤では今までの方法は使えなかった 
○ to MySQLのため、SQL Server レプリケーションは使えない 
○ 再実装でテーブル構造が異なる 
51

View Slide

ダメなリプレイス方法 
1. データ移行 (bulkload&restore) 
2. クライアント切り替え 
 
サービス停止はしないため、 
1と2の間にデータ更新が合った場合、差分が発生してしまう 
52
オンプレミス
DB Server
(SQL Server)
データ加工
id, email, pasword ...
クライアント
1
2
AAA
BBB
CCC
DDD
EEE
AAA
BBB
CCC
DDD
EEE
差分が発生

View Slide

採用したリプレイス方法 
1. 更新ワークロードを行うクライアント (ASP) でダブルライト 
2. データ移行 (bulkload&backfill) 
3. クライアント切り替え 
 
ダブルライトし新規データの整合性を担保した後、データ移行 
この方法を採用(詳細を後述) 
53
オンプレミス
DB Server
(SQL Server)
更新クライアント (ASP)
1
AAA
BBB
CCC
DDD
EEE
EEE
AAA
BBB
CCC
DDD
EEE
3
EEE
EEE
2 データ加工
id, email, pasword ...

View Slide

ダブルライト 
● ID基盤でユーザー登録/更新/削除を行うダブルライトAPIを実装 
● 更新ワークロードを行うクライアント (ASP)で 
ZOZO ID 更新時にダブルライトAPIを叩いてもらうリリース 
● ダブルライト開始後のデータは新・旧DBで同一となる状態 
● ダブルライトAPIはUPSERT (レコードが存在しなければINSERT、存在すればUPDATE) で実装 
○ ダブルライトのデータ更新が常に正となる 
○ 次のデータ移行 (backfill) 時に必要となる実装 
 
 
54

View Slide

データ移行(bulkload) 
● SQL Serverのデータを抽出し、MySQLの一時テーブルへ移行 
○ ダブルライト中でデータがたまり始めた本番テーブルでなく、 
ID基盤内に用意した一時テーブルへ 
● Embulkを使った 
○ データ転送ツール 
○ SQL Server to MySQL のプラグインあり 
○ 社内実績あり 
○ データを加工し、テーブル構造の差分も解決 
■ データ抽出時のSQLで “ごにょごにょ” 加工する 
55

View Slide

データ移行(backfill) 
● MySQLの一時テーブルから、本番テーブルへ過去データの穴埋め 
○ 既存データは上書きしない (duplicate entry は諦める) 
○ ダブルライトとバッティングする可能性が考えられたため、 
ダブルライトは UPSERT を実装 
(もしバッティングしても、ダブルライトでUPDATE され最新データを取り込むことができる) 
● Golangで実装した 
○ アプリケーションに合わせて Golang 
○ 高速化のため、1000件程度の bulk insert し 
失敗したら1件ずつ insert する 
56

View Slide

結果 
● 大変だったこと 
○ 旧DBに重複したデータが存在していた 
→ データを確認し、必要なデータのみ移行 
○ 移行データの整合性チェック 
→ validateを用意 (Golang) 
○ 退会時のデータ削除が、旧DBは論理削除、新DBは物理削除 
backfillにてユーザが復活してしまうことが懸念された 
→ 移行後に復活した削除ユーザを抽出、削除した 
 
● 約2千万件の移行で約 25 min (bulkload 10min、backfill 15min) 
 
57

View Slide

AWS/EKSで実施した 
セキュリティへの取り組み 
58

View Slide

求められたセキュリティ要件 
59
分類要件
アカウント管理ログインアカウントを共有してはならない 
アカウントは最小限の原則に基づいて権限設定をする 
個人情報管理高度なアクセス管理のできない場所に個人情報を保存してはならない 
アプリケーション管理セキュリティアップデートを速やかに取り入れる
アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する
秘密情報管理秘密情報を平文で保存してはならない
ログ管理本番環境の設定変更/操作ログを取得・永続化
パブリッククラウドの監査ログを取得・永続化 
開発ガイドラインから下記のセキュリティ要件が求められた 

View Slide

60
分類要件
下記4項目の取り組みについてお話します 
 

View Slide

61
分類要件
※WAFは、課題と今後にて後ほどお話します 
 

View Slide

62
分類要件
①　個人情報を扱わない Pod が、 
Aurora の個人情報を参照できないよう制限する取り組み

View Slide

Auroraアクセス制限案1 
Pod に IAMロールをつけ、権限を分離する方法 
 
● 概要 
○ IRSA (IAM Roles for Service Accounts) を使う 
○ IAMロールを k8s の Service Account に関連付ける 
○ Pod ごとに Service Account を分離し、アクセスを制限する 
 
63

View Slide

 
● 問題 
○ Aurora MySQL の認証は ID/PW のネイティブ認証を使いたい
IAM データベース認証は 200接続/秒の制約があるため
● 結論 
○ Aurora が ID/PWの認証なので、IAMレベルの分離をしても意味がない 
64

View Slide

 
● 問題 
○ Aurora MySQL の認証は ID/PW のネイティブ認証を使いたい
IAM データベース認証は 200接続/秒の制約があるため
● 結論 
○ Aurora が ID/PWの認証なので、IAMレベルの分離をしても意味がない
65
NG

View Slide

Pod のネットワークを分離する方法 
 
● 概要 
○ k8s の NetworkPolicy を使う 
○ 送信、受信の制御ルールを Pod ごとに定義する 
○ ネットワークを分離することでアクセス制限ができる 
○ ルールの宛先は CIDR で記述する 
○ 送信の制御ルールを定義する場合、どちらかが考えられる 
■ 全トラフィックを拒否し、許可する通信先を Allow List 化 
■ 全トラフィックを許可し、拒否する通信先を Block list 化 
 
66

View Slide

 
● 問題 
○ Allow List は外部APIなど通信をすべて把握、設定する必要があり非現実的
○ Block List はDB追加都度リスト追加をする必要があり、運用が辛い
● 結論
○ CIDR で記述する NetworkPolicy ルールの管理は非効率でできればやりたくない
67

View Slide

 
● 問題 
○ Allow List は外部APIなど通信をすべて把握、設定する必要があり非現実的
○ Block List はDB追加都度リスト追加をする必要があり、運用が辛い
● 結論
○ CIDR で記述する NetworkPolicy ルールの管理は非効率でできればやりたくない
68
NG

View Slide

Pod にセキュリティグループをつけ、ネットワークを分離する方法 
 
● 概要 
○ Pod にセキュリティグループをつける 
○ Aurora は許可したいセキュリティグループからの通信を許可 
○ セキュリティグループを分離することでアクセス制限ができる 
69

View Slide

 
● 問題 
○ まだ機能として存在しない 
ロードマップには存在するが開発中 
○ マネージドノードグループは、セキュリティグループの設定がクラスタ単位となり 
ノードグループごとにセキュリティグループを分けることも不可能 
 
● 結論 
○ 一番シンプルで現実的な方法だが、今はできない 
70

View Slide

 
● 問題 
○ まだ機能として存在しない 
ロードマップには存在するが開発中 
○ マネージドノードグループは、セキュリティグループの設定がクラスタ単位となり 
ノードグループごとにセキュリティグループを分けることも不可能 
 
● 結論 
○ 一番シンプルで現実的な方法だが、今はできない 
71
NG

View Slide

● 同一 EKS クラスタ内の Pod で、 
Aurora アクセスを分離し制限することは難しいと判断 
● AWS アカウント自体分離し、 
個人情報を扱う Pod とそうでない Pod を完全に分離する方針を取った 
 
Auroraアクセス制限結果 
72
API Gateway
ID基盤
VPC1
VPC2
Peering
ALB
ALB
EKS
Cluster2
EKS
Cluster1
Account1
Account2

View Slide

73
分類要件
②　コンテナイメージの脆弱性を速やかに検知する取り組み 

View Slide

コンテナイメージ脆弱性の検知 
● 脆弱性は日々増える 
○ 新たに発見される 
○ ライブラリの追加で、イメージに混入する 
 
74

View Slide

● イメージ脆弱性スキャンツールを導入 
○ 脆弱性ソースが多く、検知精度の高い Trivy を採用 
75

View Slide

● イメージ脆弱性スキャンツールを導入 
○ 脆弱性ソースが多く、検知精度の高い Trivy を採用 
● 確実に検知できるよう、GitHub Actions で自動実行 
○ 1日一回実行 
○ Pull Request の push 都度実行 
76

View Slide

Trivyスキャン導入の効果 
● 結果 
○ 2件の脆弱性を検知、修正 
■ CVE-2020-13777 (libgnutls30) 
■ CVE-2020-10878 (perl) 
 
● 参考情報も一緒に出力され、すぐに修正に取りかかれる点がGood! 
77

View Slide

78
分類要件
③　k8s manifest の秘密情報を、隠匿しつつコード管理する取り組み 

View Slide

● k8s の秘密情報管理といえば、Secrets リソース
○ base64 でデコード可能なため、そのままコード管理するべきでない 
 
● 解決するツールはいくつかあった 
○ godaddy/kubernetes-external-secrets
○ bitnami-labs/sealed-secrets
など
 
k8sの秘密情報管理 
79

View Slide

● k8s の秘密情報管理といえば、Secrets リソース
○ base64 でデコード可能なため、そのままコード管理するべきでない 
 
● 解決するツールはいくつかあった 
○ godaddy/kubernetes-external-secrets
○ bitnami-labs/sealed-secrets
など
● godaddy/kubernetes-external-secrets を採用
○ コード上の秘密情報関連の情報が少なく、セキュアだと判断した
■ sealed-secrets は公開鍵で暗号化した秘密情報を保存する
■ external-secrets は AWS Secrets Manager に保存した秘密情報の Key を指定するのみ
 
k8sの秘密情報管理 
80

View Slide

external-secrets概要 
● ExternalSecrets カスタムリソースを登録することで、 
Controller が Secrets Manager に Polling を行い、 
秘密情報を自動で Secrets リソースに格納できる 
81
Secrets Manager
External
Secrets
Controller
Name: db/info
Key Value
username xxx
password yyy
External
Secrets
(CustomResource)
ExternalSecrets
apiVersion: kubernetes-client.io/v1
kind: ExternalSecret
metadata:
name: sample
spec:
backendType: secretsManager
data:
- key: db/info
property: username
name: db-username
- key: db/info
property: password
name: db-password
namespace
Secrets
Mame: sample Key Value
db-username xxx
db-password yyy
1. Get ExternalSecrets
2. Fetch Secrets (Polling)
3. Upsert Secrets

View Slide

external-secrets概要 
● ExternalSecrets カスタムリソースを登録することで、 
Controller が Secrets Manager に Polling を行い、 
秘密情報を自動で Secrets リソースに格納できる 
82
Secrets Manager
External
Secrets
Controller
Name: db/info
Key Value
username xxx
password yyy
External
Secrets
(CustomResource)
ExternalSecrets
metadata:
name: sample
spec:
data:
- key: db/info
property: username
name: db-username
- key: db/info
property: password
name: db-password
namespace
Secrets
Mame: sample Key Value
db-username xxx
db-password yyy
1. Get ExternalSecrets
2. Fetch Secrets (Polling)
3. Upsert Secrets
コードで管理

View Slide

運用後直面した課題と解決 
● 課題 
○ 更新した Secrets を Pod にリロードさせる必要がある 
○ Secrets と Deployment (Podのコンテナイメージ)を同時に更新できない 
■ 自動更新である external-secrets と Deployment の更新を合わせることは難しい 
 
 
83

View Slide

運用後直面した課題と解決 
● 課題 
○ 更新した Secrets を Pod にリロードさせる必要がある 
○ Secrets と Deployment (Podのコンテナイメージ)を同時に更新できない 
■ 自動更新である external-secrets と Deployment の更新を合わせることは難しい 
 
● 解決 
○ Controller の Polling を OFF にし、自動更新を停止する 
○ ExternalSecrets リソースは更新でなく毎回 name を変え、新規作成する 
■ Secrets リソースも毎回新規作成される 
○ Deployment は毎回新しい Secrets リソースを指定する 
84

View Slide

同時更新フロー 
1. Secrets Manger を更新 
85
Secrets Manager
Key Value
password yyy zzz
External
Secrets
(CustomResource)
ExternalSecrets
metadata:
name: sample-20200818
spec:
data:
- key: db/info
property: password
name: db-password
Secrets
Name:
sample-2020818
Key Value
db-password yyy
Name: db/info
Deployment
template:
spec:
containers:
- name: id
image: ecr/id:v1
env:
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
key: db-password

View Slide

Deployment
template:
spec:
containers:
- name: id
image: ecr/id:v2
env:
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
key: db-password
2. ExternalSecrets リソースを新規作成し、Deployement の Secrets リソースを変更する 
(コンテナイメージの更新がある場合は、Deployment の image を更新する) 
86
Secrets Manager
Key Value
password zzz
External
Secrets
(CustomResource)
ExternalSecrets
metadata:
spec:
data:
- key: db/info
property: password
name: db-password
Secrets
Name:
sample-2020819
Name: db/info
Key Value
db-password zzz

View Slide

2. ExternalSecrets リソースを新規作成し、Deployement の Secrets リソースを変更する 
(コンテナイメージの更新がある場合は、Deployment の image を更新する) 
3. manifest を apply し新しい Secrets で Deployment が起動する 
87
Secrets Manager
Key Value
password zzz
External
Secrets
(CustomResource)
ExternalSecrets
metadata:
spec:
data:
- key: db/info
property: password
name: db-password
Secrets
Name:
sample-2020819
Name: db/info
Key Value
db-password zzz
Deployment
template:
spec:
containers:
- name: id
image: ecr/id:v2
env:
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
key: db-password

View Slide

88
分類要件
④　kubectl exec で Pod にログインした際の 
Pod 上でのコマンド実行ログを取得する取り組み 

View Slide

Pod上でのコマンド実行ログ 
● 設定した一般的な EKS のログ 
 
 
 
 
 
 
 
89
対象ログ (CloudWatch Logs) 取得方法
コントロールプレーン ● k8s API サーバーコンポーネントログ
● 監査ログ
● 認証システムログ
● コントローラーマネージャーログ
● スケジューラーログ
マネージメントコンソールで設定
ワーカーノード ● コンテナログ
● Nodeのサーバログ
● Nodeのk8s系サービスのjornalログ
Daemonsetをインストール 
● CloudWatch Agent 
● Fluentd CloudWatch 

View Slide

● 設定した一般的な EKS のログ 
 
 
 
 
 
 
 
 
● kubectl exec で Pod ログイン後のコマンド実行ログは別途実装する必要があった 
○ 調査のために Pod にログインすることはある 
90
対象ログ (CloudWatch Logs) 取得方法
コントロールプレーン ● k8s API サーバーコンポーネントログ
● 監査ログ
● 認証システムログ
● コントローラーマネージャーログ
● スケジューラーログ
マネージメントコンソールで設定
ワーカーノード ● コンテナログ
● Nodeのサーバログ
● Nodeのk8s系サービスのjornalログ
Daemonsetをインストール 
● CloudWatch Agent 
● Fluentd CloudWatch 

View Slide

● Falco を使う 
○ コンテナアプリケーションやホスト、ネットワークの 
異常検知を行うコンテナランタイムセキュリティツール 
○ できること 
■ システムコールを解析する 
■ rule に従ってアクティビティを検知し、outputする 
 
91

View Slide

● 導入方法 
○ Daemonset をインストールする 
○ コマンド実行ログを取る Rule を ConfigMap で作成する 
■ デフォルトでいくつかの Rule が用意されているが、 
すべてのコマンド実行ログの取得は無いので作成が必要 
92
出力されるログ :
command=ls pid=xxx user=root k8s.ns=xxx k8s.pod=xxx container=xxx image=xxx parent_process=bash
ワーカーノード
OS
コンテナ
アプリPod
ls
cd
...
Falco Pod
システムコール
execve
コンテナで、
execveがコールされたら
(新しいプロセスが生成されたら )
stdout に output する
Rule
2
1

View Slide

● 導入方法 
○ Daemonset をインストールする 
○ コマンド実行ログを取る Rule を ConfigMap で作成する 
■ デフォルトでいくつかの Rule が用意されているが、 
すべてのコマンド実行ログの取得は無いので作成が必要 
○ stdout のログは Fluentd CloudWatch で CloudWatch Logs へ転送 
○ S3へ定期的に格納することで永続化 
93
ワーカーノード
OS
アプリPod
ls
cd
...
Falco Pod
システムコール
execve
コンテナで、
execveがコールされたら
(新しいプロセスが生成されたら )
stdout に output する
Rule
2
1
出力されるログ :
command=ls pid=xxx user=root k8s.ns=xxx k8s.pod=xxx container=xxx image=xxx parent_process=bash
Fluentd Pod
コンテナ
CloudWatch Logs S3

View Slide

課題と今後 
 
94

View Slide

リプレイス半ばである 
● ID基盤を使うクライアントは2つ 
○ フロントエンドWebサーバ ASP(社内) 
○ iOS/Androidアプリ 
● リプレイスのフェーズと現状  
○ Phase1 : ダブルライト 
○ Phase2 : フロントエンドWebサーバ ASP 参照ワークロード切り替え (Private Endpoint) 
○ Phase3 : iOS/Androidアプリ参照ワークロード切り替え (Public Endpoint) 
○ Phase4 : 更新ワークロードの切り替え 
95

View Slide

リプレイス半ばである 
● ID基盤を使うクライアントは2つ 
○ フロントエンドWebサーバ ASP(社内) 
○ iOS/Androidアプリ 
● リプレイスのフェーズと現状  
○ Phase1 : ダブルライト 
○ Phase2 : フロントエンドWebサーバ ASP 参照ワークロード切り替え (Private Endpoint) 
○ Phase3 : iOS/Androidアプリ参照ワークロード切り替え (Public Endpoint) 
○ Phase4 : 更新ワークロードの切り替え 
 
現状は Phase2 まで完了 
96

View Slide

Phase3から求められる要件 
● Phase3 : iOS/Androidアプリ参照ワークロード切り替え 
○ Public なエンドポイントを用意するため、サイバー攻撃対策が必要になってくる 
97

View Slide

○ Public なエンドポイントを用意するため、サイバー攻撃対策が必要になってくる 
● オンプレミスで実施している攻撃対策 
○ ログイン異常の検知 
○ 悪意あるユーザの (SourceIP/User-Agent などで) Block 
○ DDoS対策 
など 
 
98

View Slide

○ Public なエンドポイントを用意するため、 
エンドポイントに対する攻撃対策が必要になってくる 
● オンプレミスで実施している攻撃対策 
○ ログイン異常の検知 
○ 悪意あるユーザの (SourceIP/User-Agent などで) Block 
○ DDoS対策 
など 
 
ID基盤版の対策検討中 
検討中の内容を一部紹介します 
99

View Slide

ログイン異常の検知 
100
● ログイン失敗率の増加を検知することで、異常なログインを検知する 
● 必要データの取得方法 
○ アクセスログを Pod で出力し、CloudWatch Logs へ転送 
○ MetricsFilter で Totalログイン数、Failedログイン数を Count 
● 異常の検知、通知方法 
○ CloudWatch Alarm で数式メトリクス失敗率を算出し、しきい値を上回った場合に 
SNS Topic から、Slackなどに通知 
EKS CloudWatch Logs SNS Topic
CloudWatch
Metrics
Filter
CloudWatch Alarm

View Slide

悪意のあるユーザのblock 
101
● ログイン異常の検知などで、悪意のあるユーザが見つかったら block する 
● ALB に AWS WAF をアタッチ、悪意のあるユーザを block するルールを追加 
○ 悪意のあるユーザを block するルール追加 
○ その中でも許可する条件を、前段にルール追加 
 
WebACL
Rule Condition Action
Allow List 特定のUser-Agent 許可
Block List 悪意のあるユーザー
(パブリッククラウドの IP Rangeなど)
ブロック
デフォルト許可
善良なユーザ
悪意のあるユーザ
EKS
ALB WAF

View Slide

DDoS対策 
102
● WAF に RateLimit を超えるリクエストのあった IP を block するルールを追加 
○ Rate-base rule で RateLimit を超えたら block するルールを追加 
 
 
WebACL
Rule Condition Action
Allow List 特定のUser-Agent 許可
Block List 悪意のあるユーザー
(パブリッククラウドの IP Rangeなど)
ブロック
Rate Limit RateLimit を超えるリクエストのあった IP ブロック
デフォルト許可
善良なユーザ
悪意のあるユーザ
EKS
ALB WAF
DDoS攻撃

View Slide

まとめ 
103

View Slide

ZOZOTOWNリプレイス 
104
 
● ZOZOTOWNの成長のためリプレイスを加速させている 
 
● 2020年度、まずは変更しやすくするため 2つの施策を進めている 
● DB接続のAPI化（ストアドはがし） 
● マイクロサービスの立ち上げ 
 
● 2020年度、マイクロサービスの完成形テンプレートを作る 
そのために組織も変えた 

View Slide

ID基盤のリプレイスと取り組み 
105
 
● 従来のオンプレモノリシックなアーキテクチャから 
マイクロサービスアーキテクチャへと作り変えている 
 
● ダブルライト、bulkload、backfill という手法で 
メンテナンスを設けずデータの移行を行った 
 
● セキュリティ向上のため、AWS/EKSで様々な取り組みを行っている 
 
 
これを基準として、ZOZOTOWN のリプレイスを加速させていきます！ 

View Slide

View Slide

ZOZOにおけるID基盤のk8sへのリプレイスとセキュリティの取り組み / Authentication service replacement and security efforts of zozotown(CNDT2020)

ZOZOにおけるID基盤のk8sへのリプレイスとセキュリティの取り組み / Authentication service replacement and security efforts of zozotown(CNDT2020)

kameikki

Other Decks in Technology

Featured

Transcript