日本一分かりやすく、VaultのAuth Methodの一つである、「AWS Auth Method(IAM)」について解説を試みる。公式ドキュメントはこちら

事前知識

AWS STSとは

sts:GetCalleridentity

  • sts:GetCallerIdentityとは、呼び出し元(今まさにサインインして実行しているCLI)の「AWSアカウントID」「ユーザID」「ARN」を返すAPIのこと
  • 実行してみた(他アカウントのロールをAssumeRoleしてCLIを実行した場合)
bash-3.2$ aws sts get-caller-identity
{
    "UserId": "XXXXXXXXX:<user_name>-cli-session",
    "Account": "<account_id>",
    "Arn": "arn:aws:sts::<account_id>:assumed-role/<assume_role>/<user_name>-cli-session"
}

AWS APIリクエストの署名

  • AWSにHTTPリクエストを送る時には、AWSが送信元を特定できるよう、リクエストに署名する必要がある
    • アクセスキー(アクセスキーIDと、シークレットアクセスキー)を用いる
    • AWSCLIやSDKを使っている時は、ツールが設定時に指定したアクセスキーを用いて、自動的にリクエストに署名してくれている
  • v2とv4があるが、v4が推奨されている

リクエストに署名する理由

  • リクエスタのIDの確認
    • 有効なアクセスキーを持っている人がリクエストを送ったことを確認できる
  • 送信中のデータの保護
    • 送信中のリクエストの改ざんを防ぐ
  • replay attackの帽子
    • リクエストはタイムスタンプを含む。リクエストのタイムスタンプの5分以内にAWSに到達しない場合は、AWSはリクエストを拒否する

VaultにおけるAWS Auth Methodについて

  • AWS Auth Methodには、iamec2という2つの認証タイプがある。
  • iammethodの方が新しいmethodで、こちらが推奨される方式である。

iammethod

  • iammethodでは、IAMクレデンシャルによって署名された特定のAWSリクエストが、認証に使用される。
  • IAMクレデンシャルは、IAMインスタンスプロファイル、LambdaなどのAWSインスタンスに自動的に提供され、それをVaultがクライアントに認証に使用する。

ec2method

  • ec2methodでは、AWSは信頼されたサードパーティとして扱われ、個々のEC2インスタンスを一意に表す、暗号的に署名された動的なメタ情報が、認証に使用される。
    • このメタ情報は、自動的にAWSによって全てのEC2インスタンスに提供される。

iammethodを使った認証

オーバービュー

vault-iam-auth-method-overview

解説

  • 事前準備(青矢印の部分)であるが、まず認証リクエスト実行前に、認証しようとするクライアントが、AWS STS APIGetCallerIdentitymethodへのリクエストを作成する(ただし、このタイミングでは、AWS STSエンドポイントに対して送信はしない)
  • 次に、このリクエストに対して、クライアントに設定された、(Vaultに対する認証に用いるIAMエンティティの)クレデンシャルを用いて、署名をおこなう。

  • 事前準備で作成した署名付きのリクエストを、Vaultに対するログインリクエストとともに、Vault Serverに対して送信する。
    • Vault CLIあるいはHTTP APIを利用する。

  • Vault Serverは、AWS STSエンドポイントに対して、リクエストを発行する。(GetCallerIdentityを呼び出す。)
    • 署名部分の内容(クレデンシャルの値)を知らなくても、STSリクエストは実行可能。
  • Vault Serverに対しては、AWS STSエンドポイントに対してリクエストを投げる為、以下のAWSにおけるポリシーを付与する必要がある。
    • sts:GetCallerIdentity
    • iam:GetRole(IAMロールで認証する場合)
    • iam:GetUser(IAMユーザで認証する場合)

  • GetCallerIdentityのレスポンスが返る。
    • Vaultに対する認証に用いるIAMエンティティ(ここの例では、dev-role)のARNが返ってくる。

  • ③で返ってきたARNを元に、Vault Serverが認証を行う。
  • 事前に作成されたVaultのroleにバインドされたIAMPrincipalのARNと突き合わせて、認証を許可するかどうかを決定する。

  • 認証が成功した場合、roleにバインドされたVaultのpolicyで認可を行い、client_tokenを含んだレスポンスを、クライアントに返す。
  • クライアントは、そのclient_tokenを使って、Vault Serverに対してアクセスする。