業務でAuth0を使った構成はさわったけど同じことを検証するとパクリ業務情報の持ち出しと思われそうだったのと、VaultでサポートされているOIDCプロバイダリストを眺めているとローカル環境でも使ってるGitLabがあったのでお試し。
設定に使うのは以下のJWT/OIDC認証を使った構成。
Use JWT/OIDC authentication | Vault | HashiCorp Developer
VaultにおけるGitlab(全部小文字？)の設定方法については、かなり簡潔だけど記載はあるのでこの通りやればOK
Use Gitlab for OIDC | Vault | HashiCorp Developer
また、GitLabに使うサーバー証明書は自己署名だとX509エラーをクリアできなかったため、自前のCAで良いので署名付きのものを使用する。
設定投入
VaultでOIDC認証を有効化
Use JWT/OIDC authenticationのConfigurationの項より、まずはOIDC認証の有効化
/ $ vault auth enable oidc Success! Enabled oidc auth method at: oidc/
GitLabでアプリケーション作成
GitLabの「Settings > Applications」で「Add new application」で認証用アプリケーションを作成する。入力する項目は以下の通り。
Nameにはvaultなどわかりやすい名前を入力。
Redirect URIはVaultのURLベースで https://{vault-host:vault-port}/ui/vault/auth/{path}/oidc/callback を入力する。 {path} はOIDC有効時のパスを指定する。
前述の場合であればoidcが当てはまる。
すでに別の認証でoidcを使用している場合はvault auth enable --path=foobarbaz oidcのようにパスを別途指定することになるので、そのパスを指定する。
あとはScopesはopenidにチェックをいれて、「Save application」押下する。
するとApplication IDとSecretの値を確認できるのでメモしておく。
(Secretはこの画面を離れると再確認できず再作成することになるので注意)
VaultでOIDCとロールの設定
Vaultのシェルで認証情報の設定とロール作成を行う。このOIDCを使ってログインしたユーザーのポリシーはpoliciesで指定するので事前に用意しておく。(appendix参照)
以下コマンドで設定作成。
oidc_discovery_urlにGitLabのURLを指定- GitLabで作成したApplication IDとSecretは、それぞれ
oidc_client_idとoidc_client_secretで指定 oidc_discovery_ca_pemにGitLabのサーバー証明書にサインしたルートCAのcrtファイルパス
コマンド実行時にGitLabのサーバーへ.well-known/openid-configurationファイルを取得しに行くため、証明書エラーがあると失敗する。podに注入したCAのファイルのパスをoidc_discovery_ca_pemで指定する。(@を忘れないこと)
vault write auth/oidc/config \
oidc_discovery_url="https://gitlab.example.org" \
oidc_client_id="$client_id" \
oidc_client_secret="$client_secret" \
oidc_discovery_ca_pem=@/opt/ca/root-ca/ca.crt
上手くいかない場合はpodのログを確認。tls: failed to verify certificate: x509などが出力されていれば証明書を見直す。
ロール作成は以下の通り。(以下はRole名gitlabとしている)
allowed_redirect_urisにはGitLab上でApplications作成時に入力したCallback URLと同じVaultのURLを入力。
vault write auth/oidc/role/gitlab \
allowed_redirect_uris="https://vault.example.org/ui/vault/auth/oidc/oidc/callback" \
user_claim="preferred_username" \
policies=kv-read-list \
ttl=1h
これでVaultのログイン画面で、MethodをOIDC、Roleにgitlabを入力して「Sign in with OIDC Provider」を押下すればGitLabの認証画面が起動するので、GitLabで認証すれば指定ポリシーが提要されたアカウントとしてVaultにログインできる。
いろいろ試行錯誤だったけどまとめてみたら意外と分量なかった。。
まぁ公式ドキュメントに載っている内容だからね。。
appendix
secretマウントでVaultのpodでルートCAのファイルを参照する
まずルートCAのsecretを作成する。
$ kubectl create secret -n vault generic local-root-ca --from-file=ca.crt secret/local-root-ca created
そしてこのsecretをpodからマウントするようにデプロイする。
VaultのHelmチャートの場合は以下定義を追加してhelm upgradeする。
server: volumes: - name: local-root-ca secret: secretName: local-root-ca volumeMounts: - mountPath: /opt/ca/root-ca name: local-root-ca readOnly: true
要はpodの定義で以下のようにcaのファイルがマウントできていればよい。
spec: containers: volumeMounts: - mountPath: /opt/ca/root-ca name: local-root-ca readOnly: true [...] volumes: - name: local-root-ca secret: secretName: local-root-ca
/ $ ls /opt/ca/root-ca/ca.crt /opt/ca/root-ca/ca.crt
Vaultのpolicy作成
KVシークレットエンジンのreadとlist件を設定する例
path "kv/*" { capabilities = ["read", "list"] } path "cubbyhole/*" { capabilities = ["deny"] }
ファイルは作らずヒアドキュメントで作成する。
vault policy write kv-read-list -<<__EOL__
path "kv/*" {
capabilities = ["read", "list"]
}
path "cubbyhole/*" {
capabilities = ["deny"]
}
__EOL__
Vaultコンテナにはcurlはないけどwgetはあるので、GitリポジトリとかHTTPアクセスできるならそこから流しても良いかも。(動作未確認)
wget -O- https://raw.githubusercontent.com/...... | vault policy write kv-read-list -
作成済みポリシー確認
一覧
/ $ vault policy list default kv-read-list kv-read-write root
内容確認
/ $ vault policy read kv-read-list
path "kv/*" {
capabilities = ["read", "list"]
}
path "cubbyhole/*" {
capabilities = ["deny"]
}
/ $
参考
ルートCAの作成はこの辺
(むしろこのときに作成したのをそのまま運用してて、サーバー証明書は-days 365で作っててちょうど期限きれてた)
GitLabはここの要領で証明書は自前のCAで署名、コンテナ起動はDocker Compose使用。
そしてまさか6年も前に書いたOpenShiftの認証プロバイダとしてGitLabを使ったときのエントリがちょっと役に立つとは思わなかった。
OpenShiftはGitHubの認証も対応してるんでVaultも同じように(サポートリストに入ってないけどたぶん)簡単にできるだろうと思ってたら意外と全くそんなことなかったんで、別途まとめたい。
※ そもそもVaultがサポートしてるのはOIDCであり、GitHubは仕組みが異なる。らしい。
※ 2026.02.15 書いた
環境
- Kubernetes: K3s v1.34.3
- HashiCorp Vault 1.21.2 (on Kubernetes)
- GitLab Community Edition v18.0.1 (on Docker)
