イオンスマートテクノロジーのCTO室SREチームの@hikkie13です。
過去の記事に記載がある通り、弊社ではHCP Vaultの導入を進めています。
導入には教育・学習が欠かせません。
その過程で得た知識を何回かに分けてまとめていこうと思います。（心が折れない限り）
今回は、VaultのTokenについてです。
Tokenについては、弊社内のこの記事もご参考ください。
Tokenについて
Vault Token
- Tokenは認証の中核的な方法。
- Vaultでのほとんどの操作は既存のトークンを必要とする
- 例外として、例えばログインパスには不要
- Token Auth MethodはTokenの作成と保管を担当する。
- Token Auth Methodは無効にできない。
- Tokenは直接使用することもできるし、他の認証方法（例えば外部のIdPLDAPなど）と組み合わせて動的にTokenを生成することもできる。
- Tokenには、Tokenが実行可能な操作を制御するための1つ以上のポリシーが付随する。 ※ポリシーについては別記事で。
- トークンはX-Vault-Tokenヘッダー経由で送信される。
- Authorization Bearerも有効なヘッダー。
Tokenの種類
Tokenには大きく Service TokenとBatch Tokenに大別される。
tokenの種類はprefixで見分けられる。
| タイプ | prefix |
|---|---|
| Service Token | hvs. |
| Batch Token | hvb. |
| Recovery Token | hvr. |
後述されるが、Service Tokenは用途によりさらに分別される。
Serivce Token
- デフォルトのTokenタイプ。
- ストレージに永続化される（ストレージに対して大量のwrite/readが発生）。
- 更新、無効化が可能で、子Tokenを作成することも可能。
Batch Token
- 暗号化されたバイナリ・ラージ・オブジェクト（BLOB）である。
- 軽量でスケーラブルに設計されている。
- ストレージには永続化されない。
- 全機能を持ってはいない。
- 高ボリュームの操作、例えば暗号化に理想的である。
- ディザスタリカバリ（DR）レプリケーションクラスターの昇格にも使用される。
Service TokenとBatch Tokenの比較
| 特性 | Service Token | Batch Token |
|---|---|---|
| Root Tokenになれる | ○ | ✕ |
| 子Tokenを生成できる | ○ | ✕ |
| 更新可能 | ○ | ✕ |
| 周期的になれる | ○ | ✕ |
| 明示的にMaxTTLを設定可能 | ○ | ✕ |
| Accessorを持つ | ○ | ✕ |
| Cubbyholeを持つ | ○ | ✕ |
| 親Tokenが取り消された時に取り消される (orphenでない場合) | ○ | 停止 |
| Dynamic Secretのリース割り当て | 自己 | 親 (orphanでない場合) |
| Performance Replication Cluster間で使用可能 | ✕ | ○ |
| Performance Standby Nodeの数に応じてスケール | ✕ | ○ |
| パフォーマンス・コスト | 重量 Token生成時に大量の書き込みが発生する |
軽量 Token生成時にストレージの書き込みコストがない |
Tokenのヒエラルキー
- Root Tokenを除いて、各TokenはTTL(Time-To-Live)を持つ。
- 更新されない限り、TTLに達した時点でrevoke（廃止）され、無効となる。
- max TTLに達すると、無効になる。
- 手動で無効化することによって、TTLより前にに無効にすることも可能
- 親Tokenが無効になると、その子Tokenもすべて無効になる。
以下のTokenのヒエラルキーを持つ場合、Tokenが無効になる順番はC,D → A,Bとなる。
DはCの子Token、BはAの子Tokenのため。
トークンA (ttl=4h)
├ トークンB(ttl=6h)
└ トークンC(ttl=2h)
└トークンD(ttl=3h)
ユースケースとTokenの選択
| ユースケース | Token |
|---|---|
| 長時間稼働するアプリケーションがあり、Tokenや秘密鍵の再生成ができない | Periodic Service Token |
| 一度の使用後に自動的に無効になるTokenが必要 | Service Token with Use Limit |
| 親Tokenの影響を受ける有効期限を持つTokenをアプリで使用できない | Orphen Service Token |
Periodic Service Token
以下の特徴を持つため、Tokenの再生成を扱えない長期稼働のサービスやアプリケーションに有用。
- Tokenが無効になることが問題になる場合、Rootまたはsudoユーザーは周期的なTokenを生成できる。
- 周期的なTokenにはTTLはあるが、max TTLはない。
- 周期的なTokenは無限の時間存続する可能性がある。
Service Token with Use Limit
使用回数制限付きのService Token。
- Tokenの使用回数を設定する。TTL（Time To Live）およびmax TTLに加える形となる。使用回数の制限もしくはTTLのうち、早い方の制限で失効する。
つまり、失効するのは以下の通り。- 残りのTTLに関わらず、最後の使用時。
- 残りの使用回数に関わらず、そのTTLの終わり。
Orphan Service Token
Orphan=孤立、という意味。
- 親Tokenの子ではないため、親Tokenが失効しても失効しない。
- 自身のmax TTLに達した時に失効する。
RootまたはsudoユーザーがOrphan Tokenの生成可能
Root Tokenについて
Root Tokenとは
Rott TokenはVaultに無制限のアクセスを持つスーパーユーザーである。
- TTLはない。
- Root Policyが紐づけられる。（つまり何でもできる）
- Root TokenはTTLを持つRoot Tokenを生成できる。
- 権限が強すぎるので、Root Tokenを日常使いしてはいけない。
- 削除することを推奨
Root Tokenはいつ作られるのか？
vaultの初期化( vault operator init )で生成される。
- Vaultを最初にデプロイする際の唯一の認証方法となる。
- 認証方法や監査デバイスなどの初期設定に使用される。
- 新しい認証方法が設定・疎通されたら、Root Tokenは削除すべき。
Token Accessors
すべてのTokenには、Tokenへの参照として使用されるToken Accessorがある。
Token Accessorsは、限定されたアクションを実行するために使用する。
例としては、
- 更新(renew)/無効化(revoke)
- プロパティやcapabilitiesを参照する。
Vaultへの認証や追加リクエストの実行には使用できない。
TTLについて
- TTLのデフォルトは32日（768h)
- 変更する場合は、
defalut_lease_ttlを設定する。
参考
HashiCorp Certified: Vault Associate 2024 (w/ Hands-On Labs)
HashiCorp Certified: Vault Operations Professional
最後に（採用のお知らせ）
イオンスマートテクノロジーではエンジニアをはじめとした様々な職種を積極的に採用中です！
これからとてもおもしろいフェーズへ突入していくと思いますので興味のある方は是非カジュアル面談などで話を聞いてください！
Discussion