本スライドでは私たちのチームにおいて、秘匿情報の管理方法をどのように改善したか記載しております。

1. 楽天における安全な秘匿情報管理への道のり
Jan 13th, 2023
Takumi Sato
Rakuten Group, Inc.

2. 2
自己紹介
• Software Engineer
• 2020年4月 楽天グループ株式会社新卒入社
• 趣味
• ドライブ
• サウナ
• 最近やったこと
• DiRT
• Vault Enterprise版導入
• Kubernetes Operator Pattern導入
佐藤 匠(さとう たくみ)

3. 3
Service Operation Kaizen (SOK) Section
※ Our team member's presentation.
https://codezine.jp/article/detail/12021
https://event.cloudnativedays.jp/cndo2021/talks/371
https://event.cloudnativedays.jp/cndo2021/talks/311
https://event.cloudnativedays.jp/cndo2021/talks/401
https://event.cloudnativedays.jp/cndo2021/talks/621
https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15381/dirt-up
https://www.elastic.co/elasticon/solution-series/asia-pacific-jp?tab=2#agenda
Our Mission : Operation Zero
Our Services : 9 Services
Used by various Rakuten Group’s services

4. 4
職種
• Software Engineer
• SRE
• Project manager
• Product manager
We are hiring!
https://www.irasutoya.com/2016/02/blog-post_329.html
Maps Data: Google, ©︎2022

5. 5
Today's Theme
How To Manage the Secret
Information
w/o
Hard Operation

6. 6
Agenda
はじめに
背景
Vault Serverの構築について
Vault Clientの導入について
Disaster Recovery Operationについて

7. 7
Agenda
はじめに
背景
Vault Serverの構築について
Vault Clientの導入について
Disaster Recovery Operationについて

8. 8
シークレットとは
認証認可を与えるものの総称。DB認証情報、クラウドのIAM、トークン、
ID&パスワード、SSH Keyなどを指す

9. 9
Vaultとは
シークレットの管理
データの暗号化、復号 認証・認可
https://www.silhouette-illust.com/illust/37090
https://icon-rainbow.com/

10. 10
Agenda
はじめに
背景
Vault Serverの構築について
Vault Clientの導入について
Disaster Recovery Operationについて

11. 11
チーム内におけるシークレット管理方法の課題
シークレットの漏洩リスク
•平文での管理
•ソースコードに直接書き込まれている
•GitHub, Confluenceなどさまざまな場所に保存されて
いる

12. 12
• シークレットを暗号化した状態でより安全かつ一元的に管理
• Audit logによってシークレットにいつ誰がアクセスしたか追跡可能
Vaultによるシークレット管理方法の改善

13. 13
Vault本格利用時の課題
• Vaultを本番環境で本格的に利用するために、マルチリージョンの冗
長化を行いたい
• しかし、クラスタ間のレプリケーションはEnterprise版のみの提供
Vault Enterprise契約を決定

14. 14
Vault Enterprise契約のプランについて
HCP版 Self managed版
Overview SaaS ライセンスを取得し、
自前でクラスタを構築
冗長化レベル マルチリージョンでのDR(Disaster Recovery)
構成が組めない
マルチリージョンでのDR構成が組める
コスト 高 低
運用 サーバの運用が不要 サーバの運用、メンテナンスが必要
機能 カスタムプラグインを未サポート
Advanced Data Protectionを未サポート
Vaultの全ての機能を利用可能

15. 15
Vault Enterprise契約のプランについて
HCP版 Self managed版
Overview SaaS ライセンスを取得し、
自前でクラスタを構築
冗長化レベル マルチリージョンでのDR(Disaster Recovery)
構成が組めない
マルチリージョンでのDR構成が組める
コスト 高 低
運用 サーバの運用が不要 サーバの運用、メンテナンスが必要
機能 カスタムプラグインを未サポート
Advanced Data Protectionを未サポート
Vaultの全ての機能を利用可能
マルチリージョンの冗長構成が可能なself
managed版を選択

16. 16
Agenda
はじめに
背景
Vault Serverの構築について
Vault Clientの導入について
Disaster Recovery Operationについて

17. 17
Vault Serverの概要

18. 18
$ helm install vault hashicorp/vault -n vault ¥
--values vault_config.yaml
Helmで容易にinstall可能
Vault Serverの構築手順

19. 19
Vault Server構築時に必要なシークレットはAzure Key Vaultで保管
• root token(一時的に使用)
• TLS証明書
• recovery key (unseal key)
Vault Serverの構築手順

20. 20
Audit log
$ vault audit enable -tls-skip-verify file file_path=stdout
Audit logを有効化することで誰がどのシークレットにアクセスしたか追
跡可能に

21. 21
レプリケーションについて
https://developer.hashicorp.com/vault/docs/enterprise/replication#primary-secondary-communication
低コストでマルチクラスタ構成のとれるDR Replicationを採用
• DR Replication: Active/Standby構成
• Performance Replication: Active/Active構成

22. 22
Data Storageについて
別途ストレージを用意する必要のないIntegrated Storageを採用
• Nodeにデータを永続化
• Raft(分散合意アルゴリズム)によってデータをレプリケーション
https://developer.hashicorp.com/vault/tutorials/raft/raft-storage

23. 23
自動化ポイント①: Retry join
Retry joinによってpod再起動時に自動でクラスタに参加するよう設定
retry_join {
leader_api_addr = "http://127.0.0.2:8200"
}
retry_join {
leader_api_addr = "http://127.0.0.3:8200"
} Copy

24. 24
自動化ポイント②: Vault Auto Unseal
seal "azurekeyvault" {
tenant_id = <Key Vault's Directory ID>
client_id = <Service Principal's Application ID>
client_secret = <Service Principal's generated secret>
vault_name = <Name of Azure Key Vault instance>
key_name = <Name of generated key on Azure Key Vault>
subscription_id = <ID of the Azure Subscription>
}
secret
Unseal keyの役割をAzure Key Vaultが担うことでauto unsealを実現
extraVolumes:
- type: secret
name: vault-storage-config
extraArgs: '-config=/vault/userconfig/vault-storage-config/config_je.hcl'
vault_config.yaml

25. 25
監視
下記条件で通知が飛ぶように設定
• Vault Serverがエラーメッセージを出力した場合
• Vaultのpodが直近1分間で指定個数を下回った場合

26. 26
不要な手動オペレーションを行わずに
Vault Serverの運用を行っている

27. 27
Agenda
はじめに
背景
Vault Serverの構築について
Vault Clientの導入について
Disaster Recovery Operationについて

28. 28
Vault agent
Kubernetes Cluster
App container
Pod
share secret
<init container>
Vault agent
File system
App Role Auth
role-id
ConfigMap
secret-id
Secret
mount

29. 29
Secret-idの自動更新
secret-idは、最大32日で失効する。
→更新jobをGitHub Actionsで作成し、自動更新を行っている！

30. 30
Agenda
はじめに
背景
Vault Serverの構築について
Vault Clientの導入について
Disaster Recovery Operationについて

31. 31
Disaster Recovery Operationのシナリオ
事前準備
DR-tokenの発行
Ope1
Primaryの昇格
Ope2
GSLBの切り替え
Ope3-1
original primaryか
らレプリケーショ
ンの開始
Ope3-2
new primaryからレ
プリケーションの
開始
事前に用意 障害発生時、すぐに実施！ 復旧後に実施

32. 32
Disaster Recovery Operationのシナリオ
事前準備
DR-tokenの発行
Ope1
Primaryの昇格
Ope2
GSLBの切り替え
Ope3-1
original primaryか
らレプリケーショ
ンの開始
Ope3-2
new primaryからレ
プリケーションの
開始
事前に用意 障害発生時、すぐに実施！ 復旧後に実施

33. 33
事前準備: dr-tokenの発行
$ vault write auth/token/roles/failover-handler ¥ allowed_policies=dr-
secondary-promotion ¥
orphan=true ¥
renewable=false ¥
token_type=batch
$ vault token create -role=failover-handler -ttl=8h
https://developer.hashicorp.com/vault/tutorials/enterprise/disaster-recovery#dr-operation-token-strategy
事前にDR operationに必要なdr-tokenを発行しAzure Key Vaultに保存

34. 34
Disaster Recovery Operationのシナリオ
事前準備
DR-tokenの発行
Ope1
Primaryの昇格
Ope2
GSLBの切り替え
Ope3-1
original primaryか
らレプリケーショ
ンの開始
Ope3-2
new primaryからレ
プリケーションの
開始
事前に用意 障害発生時、すぐに実施！ 復旧後に実施

35. 35
復旧オペレーション1: primaryの昇格
# Get dr_token from Azure Key Vault
$ vault write sys/replication/dr/secondary/promote ¥
dr_operation_token=<dr-token>
Secondaryクラスタをプライマリに昇格
Cluster A
DR primary
Out of service
Cluster B
DR Secondary
Original primary New primary

36. 36
復旧オペレーション2: GSLBの切り替え
GSLBのエンドポイントをnew primaryに変更
GSLB
Cluster A
DR primary
Out of service
Cluster B
DR Secondary
Original primary New primary

37. 37
Disaster Recovery Operationのシナリオ
事前準備
DR-tokenの発行
Ope1
Primaryの昇格
Ope2
GSLBの切り替え
Ope3-1
original primaryか
らレプリケーショ
ンの開始
Ope3-2
new primaryからレ
プリケーションの
開始
事前に用意 障害発生時、すぐに実施！ 復旧後に実施

38. 38
復旧オペレーションパターン3-１: new primaryからレプリケーション
1. Original primaryをDisable
2. New primaryからレプリケーションを再開
Cluster A
DR primary
Cluster B
DR Secondary
Original primary New primary
replication
(@ Cluster A)
$ vault write -f sys/replication/dr/primary/disable
(@ Cluster B)
$ vault write sys/replication/dr/secondary/enable ¥
primary_api_addr=$PRIMARY_API_ADDR ¥
token=$TOKEN

39. 39
復旧オペレーションパターン3-2: original primaryからレプリケーション
(Cluster A)
$ vault write sys/replication/dr/primary/secondary-token id=new-secondary
(Cluster B)
$ vault write sys/replication/dr/secondary/update-primary ¥
primary_api_addr=$PRIMARY_API_ADDR ¥
dr_operation_token=$DR_TOKEN ¥
token=$TOKEN
update-primaryによってprimaryをoriginal primaryに再設定
Cluster A
DR primary
Cluster B
DR Secondary
Original primary New primary
replication

40. 40
dr-tokenの自動更新
dr-tokenは、最大32日で失効する。
→更新jobをGitHub Actionsで作成し、自動更新を行っている！

41. 41
まとめ
• 秘匿情報を安全に管理できるようになった
• ほとんど手間をかけずにVaultを運用できている
• 様々なシナリオを想定したDisastor Recovery
Operationの手順を用意している

42. 42
今後の展望
• 全てのシークレットをVaultで管理したい
• DR operationの自動化を行いたい
• チーム内での運用ルールをちゃんと決めたい

43. We are hiring!