概要
前回のRedisを使った分散ロックでは、正確なロックを取るためにはZookeeperやetcdを使うと良い、とまとめていました。
なので今回はetcdを用いて分散ロックを実現します。
環境
- etcd v3.4.15
- pkg.go.dev/go.etcd.io/etcd v3.5.0
- go 1.16.0
事前知識
分散ロックに必要なもの
分散ロックマネージャには以下の機能が必要です。
- 自動リース機能
- CAS
- フェンシングトークンを発行する機能
１つ１つ説明していきます。
続きを読むNEG(Network Endpoint Group)を使った負荷分散
概要
従来のGKEのロードバランサーはNodeに到達後iptablesで再度負荷分散するという２段階ロードバランシングでした。
これによりレイテンシの増加、分散のばらつきといった問題が生じていました。
ref: Google Cloud Blog - News, Features and Announcements
しかしNEG(Network Endpoint Group)という機能を使うことで直接Pod宛てに負荷分散を行うことができ、上記の問題を低減することが可能となっています。
ref: Google Cloud Blog - News, Features and Announcements
続きを読むセキュアなトークン管理方法
概要
クライアント↔サーバ間の認証・認可情報としてのトークン管理はWebサービスとしては必ずつきまとうものですが、一方できちんと実装しないとセキュアに管理はできません。
今回はそのトークン管理方法の一例を紹介します。
要件
今回の主な要件は以下です。
- AuthサーバとResourceサーバは別で管理する（負荷特性が異なるので）
- 認証するとAuthサーバはrefresh tokenとaccess tokenを返す
- access tokenはJWT形式
- access tokenはクライアントのオンメモリで管理する
- access tokenの期限は短く（１時間以内）
- refresh tokenを使ってaccess tokenを発行できる
- refresh tokenはrevoke可能である
- 認証情報に変更があれば（パスワード変更など）refresh tokenをrevokeできる
- Resourceサーバは起動時などにAuthサーバから公開鍵を取得し、access tokenの署名検証に使用する
ネイティブクライアントの場合
ネイティブクライアントの場合、keychainなどセキュアな管理ストレージがあるためrefresh tokenを保存することができます。
続きを読む
OAuth 2.0 Device Authorization Grant
概要
サービスのマルチデバイス対応をした際に、各デバイスで同じアカウントにログインするのはユーザにとっては非常に手間です。
例えばテレビデバイスに対応した場合にID＆パスワードをリモコンで入力させるのはユーザにとって苦痛でしかありません。
なのでサービス側はユーザが苦労なくスムーズにログインできる方法を提供しなくてはいけませんが、一方でセキュリティについても気にする必要があります。
そんなケースの対応方法としてOAuth 2.0 Device Authorization Grantがあるので紹介します。
ユーザの体験
例としてテレビデバイスでログインします。
huluが体験として分かりやすいので実際にやってみます。
ログインしようとする
