![[Cloud OnAir] Dive to Google Kubernetes Engine 2018年8月2日 放送](https://cdn.slidesharecdn.com/ss_thumbnails/uuuuuuuuuu-180802093151-thumbnail.jpg?width=600&height=600&fit=bounds)
201312 scalr[oss] installation_idcf
Se está descargando tu SlideShare.
×
Eche un vistazo a continuación
Recomendado
Más Contenido Relacionado
Similares a 楽天における安全な秘匿情報管理への道のり (20)
Más de Rakuten Group, Inc. (20)
Más reciente (20)
楽天における安全な秘匿情報管理への道のり
- 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!
