イオンスマートテクノロジーのCTO室SREチームの@hikkie13です。
過去の記事に記載がある通り、弊社ではHCP Vaultの導入を進めています。
導入には教育・学習が欠かせません。
その過程で得た知識を何回かに分けてまとめていこうと思います。（心が折れない限り）
今回は、VaultのAuth Methodsについてです。
Auth Methodsについて
- 認証の実行とIDの管理を行う。
- IDやPolicyの割り当てを担当する。
- ユースケースに応じて複数の認証方法を有効にできる。
- 大きく分けて人間による方法とマシンによる方法で区別する。
- 一度認証されると、vaultはTokenを発行し、それ以降のvaultへのリクエスト（読み取り/書き込み）に使用する。
- つまり、認証メソッドの基本的な目的は、Tokenの取得となる。
- 各Tokenは関連するPolicyとTTLを持つ。
Auth Methodsの種類
認証方法には、以下のように様々なものがある。
- JWT/OIDC
- Kerberos
- Username and Password
- TLS証明書
- Token
- AppRole
- RADIUS
- aws/Google Cloud/Azure
- Okta
認証方法は、大きく分けて、人間向けとマシン向けがある。
-
認証方法（人間向け）
- 既存のアイデンティティプロバイダーと統合
- 使用には手動での操作が必要
- プロンプトまたはポップアップでログイン
- 多要素認証が統合されていることが多いプラットフォームで設定されている。
- UserPass、RADIUS、Oktaなど
-
認証方法（マシン向け）
- 覚えにくい（=人間には不向きな）手法を使用
- 通常、既存のプラットフォームと統合される。
- Kerberos、TLS証明書、Token、AppRole、Azureなど
Auth Methodsのワークフロー
以下がAuth Methodsのワークフロー図となる。
https://developer.hashicorp.com/vault/tutorials/auth-methods/tokensより
- clientがVaultと何かしらの方法で認証する（Tokenなど）
- 設定された認証方法でClientの認証を行う。(IdPなど)
- 認証が成功する。
- Tokenを生成し、ClientにTokenを返却する。
Auth Methodsの操作
- Vaultの認証方法は、使用する前に有効化する必要がある。
- 一度に一つまたは複数の認証方法を使用することができる。
- 一般的に、異なる認証方法は異なるユースケース（アプリケーション/人間）に対応させる。
- Token Auth Methodはデフォルトで有効化されており、これを無効にしたり、他の認証方法を有効にすることはできません
- 新しいVaultクラスタでは、認証にtokenが使用される。そして、それはroot tokenである。
- 認証方法は、UI、API、またはCLIを使用して有効または無効にすることができる。
- API/CLIでは可能だが、UIはできないケースがある。
コマンド例は以下
approleをデフォルトPATHで有効化する
$ vault auth enable approle
approleをexampleのPATHで有効化する
$ vault auth enable -path=example approle
以降、一部のAuth Methodsについて深掘りしていきます。
AppRole
AppRoleは、機械やアプリケーションがVaultに認証するために、事前に定義されたRoleを使用する。
- Roleはクライアント認証とVaultのアクセス要求の間に一対一の対応関係を表す。
- 定義された各Roleは静的なrole-idを持ち、0または複数のsecret-idが生成され、認証に使用される。
- role-idがユーザ名、secret-idがパスワードのようなイメージで捉えると良い。
- 例えば、異なるApplicationが同じroleを利用している場合はsecret-idは別々になる。
AppRoleの設定と認証フロー
AppRoleの基本的な設定と認証フローは以下。
https://developer.hashicorp.com/vault/tutorials/auth-methods/approleより
- AppRoleのAuth Methodを有効化する。
- PolicyやRoleの設定をする。
- role-idを取得する。
- Roleのsecret-idを取得する。
- Applicationにrole-idを渡す。
- Applicationにsecret-idを渡す。
- Applicationはrole-idとsecret-idを使用して、Vaultと認証する。
AppRoleのチュートリアル
以下をこなすと、理解が深まります👍
フローの各手順のコマンドの確認ができる。
Token
Tokenについては以前の記事をご参照ください。
Tokenでの認証例
$ vault login
Token (will be hidden):
Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run "vault login" again. Future Vault requests will automatically use this token.
Username and Password(Userpass)
- Userpass認証方法では、Vaultクライアントがローカルのユーザー名とパスワードを使用して認証する。
- Userpassは外部のIdPから認証情報を取得したり、統合したりすることはなく、ローカルで保管される。
- ユーザ名は全て小文字で扱われる。そのため、
Aeonとaeonは同じもの(aeon)として認識される。
JWT
JWTは、現状private clusterなAKSにおいてVault Secrets Operatorを使う上で必須となる。
JWTの利用という結論に辿り着くまでの苦労話は、過去の記事を参照してください。
公式ドキュメントは以下に説明があります。
- KubernetesはOIDCプロバイダーとして機能し、VaultはJWT/OIDC認証を使ってサービス・アカウント・トークンを検証する。
- サービスアカウント発行者ディスカバリーを使用する場合、JWT認証マウントにOIDCディスカバリーURLと、場合によっては信頼するTLS認証局を提供するだけでよい。このため、Kubernetesクラスタが要件を満たしていれば、最も簡単に設定できる方法となる。
- これを利用することで、 kube-apiserverへの通信を必要とせずに認証することが可能となる。(ここが一番大事👍）
参考
HashiCorp Certified: Vault Associate 2024 (w/ Hands-On Labs)
HashiCorp Certified: Vault Operations Professional
最後に（採用のお知らせ）
イオンスマートテクノロジーではエンジニアをはじめとした様々な職種を積極的に採用中です！
これからとてもおもしろいフェーズへ突入していくと思いますので興味のある方は是非カジュアル面談などで話を聞いてください！
Discussion