Vault サンプル問題

正解：B

A　RoleIDとSecretIDを使う機械向けの認証で、人間の既存ディレクトリ資産を活用できない

B（正解）　正解。既存のLDAP/ADディレクトリに問い合わせて認証し、ディレクトリ側のグループをVaultポリシーにマッピングできる

C　Vault内に独自のユーザー名とパスワードを作る方式なので、ADとの二重管理が発生してしまう

D　クライアント証明書の発行と配布という別の運用が増え、既存アカウントの再利用にはならない

正解：C

A　人間向けにVault内へユーザーを作る方式で、機械への安全な資格情報配布の仕組みを持たない

B　実在する認証メソッドだが、個人のGitHubトークンを使う人間向けの方式であり、RoleIDとSecretIDの組み合わせではない

C（正解）　正解。RoleID(公開してよい役割の識別子)とSecretID(機密値)を分離して配布でき、アプリやCIジョブの認証を想定した設計になっている

D架空　このような名前の認証メソッドはVaultに存在しない

正解：A

A（正解）　正解。インスタンスメタデータの署名やIAMの署名済みリクエストをVaultが検証するため、事前に秘密値を配置する必要がない

B　機械向けではあるが、SecretIDという秘密値をどうやってインスタンスに届けるかという問題が残る

C　クライアント証明書と秘密鍵をインスタンスに配置する必要があり、「秘密値を配置しない」という要件に反する

D　既に発行済みのトークンを使うだけの仕組みで、そのトークン自体を安全に配布する問題は解決しない

正解：B

A　アンシールキーは初期化時に一度だけ配布される運用者向けの鍵素材で、ログインとは無関係

B（正解）　正解。認証はトークンの発行に集約され、以後のすべての操作はそのトークンと付随するポリシーで認可される

C　ポリシーはサーバ側に保存され、クライアントへファイルとして返されることはない

D　ルートキーはVault内部で管理される鍵で、クライアントに渡されることはない

正解：B

A　2つを分離する設計の意味が失われ、設定ファイルが漏れただけで認証できてしまう

B（正解）　正解。受け取り側が一度だけunwrapでき、途中で開封されていれば検知できるため、配送経路の信頼性を下げられる

C　プロセス一覧や管理APIから読める可能性があり、開封の検知もできない

D　ポリシーは認可ルールの定義であり、秘密値を格納する場所ではない

正解：A

A（正解）　正解。pathブロックにcapabilitiesの配列を書くのがVaultポリシーの基本構文

B架空　permissions という属性はVaultのポリシー構文に存在しない。正しい属性名はcapabilities

C　ブロック名はpathであり、policyではない

D　KV v2の実際のAPIパスは secret/data/ 配下になるため、このパスでは読み取りが許可されない

正解：C

A　Vaultは許可優先ではない。denyが混在した時点で拒否される

B　ポリシーに適用順という概念はなく、付与順で結果は変わらない

C（正解）　正解。denyは他のどの許可よりも強く働くため、誤って広い権限を与えたときの安全弁として使える

D　競合は明確なルールで解決されるだけで、トークンが失効することはない

正解：B

A　空ではなく、自分自身のトークンを扱うための最低限の権限が定義されている

B（正解）　正解。これがあるおかげで、どのトークンも自分の情報確認や更新、自主的な失効ができる

C　それはrootポリシーの説明で、defaultとは別物

D　特別扱いどころか、既定ですべてのトークンに付く汎用のポリシー

正解：D

A　除外パスはなく、sys/ 配下も含めてすべてが許可される

B　rootポリシーは変更できない。権限を絞りたい場合は別のポリシーを作って使う

C　削除もできない。運用上はrootトークンを失効させ、必要なときだけ再生成する運用が推奨される

D（正解）　正解。特権が強すぎるため、日常運用ではrootトークンを常用せず必要時のみ生成する

正解：B

A　root保護された特権パスに必要なもので、通常のキー一覧とは関係がない

B（正解）　正解。キーの一覧取得はreadとは別のcapabilityとして扱われるため、listを明示的に許可する必要がある

C　新規作成のための権限で、一覧の可否には影響しない

D　既存データの更新のための権限で、読み取り系の一覧操作には使われない

正解：B

A　既定の種別で機能は豊富だが、1つ1つがストレージに永続化されるため大量発行時の負荷が問題になる

B（正解）　正解。暗号化された値としてクライアントに返され、ストレージに書かれない。その代わり更新も子トークン作成もできない軽量な種別

C　長期稼働プロセス向けに更新し続けられる性質を指すもので、ストレージ負荷を減らす仕組みではない

D　親を持たないという性質を指すだけで、永続化されるかどうかとは別の軸の話

正解：C

A　そもそも更新ができないため、TTLが切れた時点で使えなくなる

B　指定回数使うと失効する種別で、長期稼働にはむしろ不向き

C（正解）　正解。通常の最大TTLの制約を受けず、period(周期)ごとに更新し続ける限り有効期限が延び続ける

D　親の失効の影響を受けないというだけで、最大TTLの制約は通常どおり適用される

正解：A

A（正解）　正解。親を持たないため親トークンの失効に巻き込まれず、独立したライフサイクルを持つ

B架空　transientという名前のトークン種別はVaultに存在しない

C　TTLの長さと親子関係は別問題で、親を失効させれば残TTLに関係なく子も失効する

D　ストレージに永続化されない軽量な種別で、親子関係の解消を目的とした選択ではない

正解：D

A　子は親のライフサイクルに従うため、TTLが残っていても一緒に失効する

B　トークンに紐付くリースも同時に失効し、動的シークレットの実体も削除される

C　子の存在は失効を妨げない。むしろ連鎖的に処理される

D（正解）　正解。トークンは木構造を持ち、失効は下方向へ伝播するので、根を切れば配下がまとめて無効になる

正解：B

A　最大TTLは発行時点から測られる上限で、更新によって延びることはない

B（正解）　正解。最大TTLは無期限に生き続けるトークンやリースが生まれないようにする安全装置として働く

C　警告値ではなく強制的な上限で、到達すれば失効する

D　動的シークレットのリースにも同様に最大TTLが適用される

正解：C

A　KVはv1もv2も静的なシークレットの保管用で、動的シークレットは発行しない

B　どちらもバリアで暗号化されて保存される。暗号化の有無は違いではない

C（正解）　正解。値を上書きしても過去バージョンが残り、削除しても undelete で戻せる点がv1との大きな違い

D　バージョンに関係なくポリシーによる認可は必要で、むしろv2ではdata/とmetadata/を意識した記述が要る

正解：B

A　これはKV v1のパス構造。v2ではdata/が挟まる

B（正解）　正解。kvサブコマンドがv2のパス構造を補ってくれるため、CLIの見た目とAPIパスがずれる。ポリシー記述時はこの実パスを使う

C　バージョン一覧や削除状況などメタデータを取得するパスで、値そのものは返らない

D　マウントパスは secret のままであり、kv というセグメントが前に付くことはない

正解：A

A（正解）　正解。誤操作からの回復を考えた設計になっており、完全に消すには別途destroyが必要

B　即時消去されるのは destroy を使った場合の挙動

C　メタデータごと消すには metadata delete を使う。deleteの対象は特定バージョンにとどまる

D　削除マークが付いたバージョンは読み取れなくなる。読み書きの片方だけを止める機能ではない

正解：D

A　確認から書き込みまでの間に他プロセスが更新する余地が残るため、競合は防ぎきれない

B　運用としては単純化できるが、複数プロセスが更新するという前提そのものを崩してしまう

C　参照側がどのパスを見ればよいか分からなくなり、根本的な解決にならない

D（正解）　正解。現在のバージョンが期待値と一致するときだけ書き込みが成功するため、見落とした更新を上書きせずに済む

正解：A

A（正解）　正解。要求時に生成され期限が来れば消える短命な資格情報になるため、共有アカウントの問題を避けられる

B　それは静的なシークレット保管の動作で、動的シークレットエンジンの振る舞いではない

C　Vaultは資格情報を発行するだけで、DB通信の経路には入らない

D　ルート資格情報のローテーションなど別機能の話で、creds/ の読み取りでは新規ユーザーが作られる

正解：C

A　表形式の出力から抜き出す形になり、キー名や整形の変化に弱く値の切り出しも余計な処理が要る

B　-key というフラグは用意されていない。フィールド指定は -field を使う

C（正解）　正解。指定したフィールドの値だけが余計な装飾なしで出力されるため、そのまま変数に代入できる

D　-field 自体は正しいが、KV v2ではパスに data/ が必要になるためこのままでは目的のシークレットを読めない

正解：A

A（正解）　正解。ほとんどのコマンドで使えるグローバルオプションで、リースIDやメタデータも含めた構造化された出力が得られる

B　そのようなオプション名ではない。書式指定は -format

C　単独のフラグとしては用意されておらず、-format に値を渡す形が正しい

D　既定の人間向け表形式で、機械処理には向かない

正解：D

A　トークンをAuthorization: Bearerで渡すこと自体はVaultも受け付けるが、APIパスに /v1/ プレフィックスが無く、KV v2の data/ も含まれていないため取得できない

B　ヘッダは正しいが、KV v2のデータ本体は data/ を含むパスにあるため、このパスでは取得できない

C　トークンをURLに含めるとログ等に残る。Vaultはヘッダでトークンを受け取る設計になっている

D（正解）　正解。すべてのAPIは /v1/ 配下にあり、トークンは X-Vault-Token ヘッダで渡す。KV v2ではパスに data/ が入る

正解：B

A　認証トークンを渡すための変数で、接続先の指定には使われない

B（正解）　正解。CLIとAPIクライアントが接続するVaultサーバのURLを指定する変数で、未設定だと既定のローカルアドレスが使われる

C　名前空間を指定する変数で、接続先ホストとは無関係

D　出力形式の既定値を決める変数で、接続には影響しない

正解：B

A　シール中はデータの復号に必要な鍵が使えないため、読み取りもできない

B（正解）　正解。シールとはストレージを復号する鍵がメモリ上に無い状態を指し、ほぼすべての機能が停止する

C　トークンの権限とは無関係で、アンシールしない限り誰も操作できない

D　認証もストレージの読み書きを伴うため実行できない

正解：A

A（正解）　正解。1人の手元にある鍵だけではVaultを開けられないため、単独犯行や1枚の紛失に耐えられる

B　1つで足りるならシェアに分ける意味がない。しきい値の数だけ必要になる

C　全数ではなくしきい値(例えば5つのうち3つ)で足りる。1枚紛失しただけで復旧不能になるのを避けるため

D　Vaultが自分で保存していれば封印の意味がない。シェアは運用者が分散して保管する

正解：C

A　手間は減るが1つの鍵でVaultを開けられてしまい、分散管理の安全性が失われる

B　鍵と暗号文が同じ場所に置かれ、封印の意味がなくなる最悪の運用

C（正解）　正解。起動時にVaultが外部の鍵管理サービスへ問い合わせて自動的にアンシールする。人手で扱う鍵はリカバリーキーに置き換わる

D　そのような設定は存在しない。シールはVaultのセキュリティモデルの中核

正解：D

A　Vaultが自ら暗号化してから書き込むため、平文で保存されることはない

B　バリアを通過するデータはまとめて暗号化されるため、値だけという区別はない

C　ストレージを直接読む話とトークンによるAPI認可は別で、直接読んでも暗号文しか得られない

D（正解）　正解。この前提があるため、信頼できないストレージにもVaultのデータを置ける設計になっている

正解：B

A　実在するHA対応のバックエンドだが、別のクラスタを構築・運用する必要があり「外部の運用を増やさない」という要件に合わない

B（正解）　正解。Vaultノード自身がRaftでデータを複製するため、外部依存なしにデータ保存とHAを同時に満たせる

C架空　このような名前のストレージバックエンドは存在しない

D　単一ノードの開発・検証向けでHAに対応しておらず、本番の可用性要件を満たせない

正解：C

A　監査を欠いたまま処理を続けることはVaultの設計上許容されない

B　シールはされない。リクエストが通らなくなるだけで、書き込み先を復旧すれば処理は再開する

C（正解）　正解。監査ログを残せない操作は実行しないという方針のため、監査デバイスは冗長に構成しておくのが定石

D　ログのローテーションや削除はVaultではなく外部の仕組みで管理する