Carpe Diem

備忘録

MongoDB 4.2でシャーディング・レプリカセットのクラスタ構築

概要

気づいたらMongoDBも4.2になっていました。
以前に

DockerでMongoDBのレプリカセットを構築 - Carpe Diem

レプリケーションを、

MongoDBでシャーディング - Carpe Diem

でシャーディングを構築しましたが、設定項目が代わっていたりしたので復習がてらdocker上で構築検証しました。

大まかな流れは変わらないため、↑の記事を読んでおくとスムーズに進められます。

環境

  • MongoDB 4.2
  • Docker 19.03.2

クラスタ構成

種類 レプリカ名 台数
config configRepl 3
mongod shard shardRepl_1 3
mongod shard shardRepl_2 3
mongod shard shardRepl_3 3
mongos - 1

の計13台です。

続きを読む

技術書典7でAbemaTVの合同誌にHashiCorp Vaultについて寄稿しました

概要

AbemaTVの合同誌にHashiCorp Vaultについて執筆しました。

techbookfest.org

どんな内容

基本的にはこの技術ブログで紹介した内容を体系的にして、最新バージョンで改めて動作確認した感じにしています。

初めてHashiCorp Vaultを使う人にとって読みやすくなっていると思います。逆にすでにここの記事を読んでいた人には物足りないと思います(^_^;)

僕以外にも12人もの執筆者が各々の内容で執筆しており、かなりボリュームがある本だと思います。

当日は見本誌もありますので、是非手にとって内容をチェックしてみてください。

gRPCでエラー詳細を渡す方法

概要

以前

christina04.hatenablog.com

こちらの記事で、アプリケーション内でのレイヤ間のエラーハンドリングについてまとめました。
ではマイクロサービス間でそのエラーコードを伝播していくのはどうすれば良いのか、というのが今回の主題です。

課題

gRPCはレスポンスコードを持っています
しかしこれだけでは下記のようなケースをハンドリングできません。

  • フォームのvalidationエラーを伝える際に、どのフィールドの不備が原因か
  • カード決済時のエラーで、カードの何が問題でエラーが起きているのか

このような詳細なエラーをクライアントに伝えられない場合、クライアントは抽象的なエラー文言しかユーザに出せず、結果としてユーザは問題を解決することができなくなります。

続きを読む

protocの使い方

概要

christina04.hatenablog.com

で紹介したprotoeasyがリンクごと消えて使えなくなったので、protocの使い方を整理するために書きます。

環境

  • libprotoc 3.9.1

使い方

golangを例に基本的な使い方を説明します。

SRC_DIRディレクトリに.protoファイルがある場合、基本的には以下のようにコンパイルを実行します。

$ protoc -I./SRC_DIR --go_out=./OUT_DIR ./SRC_DIR/*.proto

各オプションをそれぞれ説明していきます。

続きを読む

機密情報の管理で大切なこと

概要

機密情報の管理はいつも悩みのタネです。
その管理に僕はHashiCorp Vaultを推してますが、その理由を含めて説明します。

管理方法の課題

機密情報の管理で考えなければいけないことはたくさんあります。

  • データの暗号化
  • どこに保存するか
  • 認証
  • アクセス権限
  • ローテーション
  • 鍵の共有自体を防ぐ仕組み
  • デプロイ時などの鍵配送
  • Audit(監査)ログ
  • 漏洩の検知
  • 漏洩時のインシデントインパクトの最小化

最初の2つはすぐ浮かぶと思いますが、残りは多くのケースで十分な対応がされてないです。

続きを読む

VaultのCubbyhole Response Wrapping

概要

HashiCorp VaultにはCubbyhole Response Wrappingという仕組みが用意されています。
これによってトークンや秘密情報の受け渡し時の漏洩リスクを最小限にします。

課題・背景

人やマシンにトークンを渡す場合、

  • 発行した人から漏洩する可能性
  • 渡す際に盗聴されて漏洩する可能性
  • 同じトークンの使い回し(別の人にも同じトークンをシェアしてしまう)
    • =漏洩経路の拡大

などの問題点を考慮する必要があります。
また仮に漏洩した場合に

  • 漏洩したトークンが不正に利用された

ということを検知する仕組みが必要になります。

Cubbyhole Response Wrappingはそれらを解決する手段です。

環境

  • Vault 1.2.2
続きを読む

HashiCorp VaultのDynamic Secrets

概要

HashiCorp VaultにはDynamic Secretsという期限の付いた認証情報を動的に生成してパブリッククラウドやDBへのアクセスをセキュアに保つ仕組みが用意されています。

課題・背景

秘密情報とその周辺の認証を一元化し、適切な暗号化・Auditなどをしっかりしたとしても以下の課題が残っています。

  • 鍵情報を用意してもローテーション運用が大変
    • 退職者が出るたびにローテーションしなきゃいけない
  • 鍵の共有化
    • 影響範囲が分からず削除できない
    • 漏洩しても誰が使ったのか分からない
  • 起動時だけ秘密情報が必要なのに永続的にどこかに残すのがセキュアでない
    • ログやクラッシュレポートに秘密情報が吐き出されてしまったり

ref: https://www.hashicorp.com/blog/why-we-need-dynamic-secrets

Dynamic Secretsはそれを解決するための手段です。

環境

  • Vault 1.2.1
続きを読む