kennygt51.dev

Vaultの「AWS Auth Method（IAM）」による認証・認可

Posted on
Vault

日本一分かりやすく、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の帽子
    • リクエストはタイムスタンプを含む。リクエストのタイムスタンプの５分以内にAWSに到達しない場合は、AWSはリクエストを拒否する

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

  • AWS Auth Methodには、iamとec2という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に対してアクセスする。