AWS の機能を GCP のサービスアカウントで認証して利用する

[publish: 2021-05-16]

概要

Google Cloud (GCP) のサービスアカウントのトークンを用いて認証し、AWS の機能を利用してみた。

背景

AWS を AWS の外から利用するには、IAM User とそれに付随するアクセスキーを発行して認証することが簡単かと思われる。しかしながら、アクセスキーは長期的な認証情報のため、セキュリティ面でのリスクが高く、なるべく用いることは避けたい。

今回、GCP のサービスアカウントを経由して認証することを試みた。この方式であれば、GCP 内のメタデータサーバからの一時的なトークンによる認証、もしくは個人の Google アカウントによる認証を用いることができる。これによって、アクセスキーを用いる必要がなくなり、セキュリティリスク (e.g. クレデンシャルの漏洩) や運用コスト (e.g. 鍵のローテーション) を低減することできる。

目標

今回は個人に紐づく Google アカウントから Google のサービスアカウント (以下、GSA とする) の一時トークンを生成し、AWS のトークンを取得し、 aws コマンドを実行する、ということを試みる。

Google サービスアカウント(GSA)の準備

GSA aws-user を作成する

gcloud iam service-accounts create aws-user

gcloud iam service-accounts describe aws-user@{{ google_project_id }}.iam.gserviceaccount.com --format=json

{
  "email": "aws-user@{{ google_project_id }}.iam.gserviceaccount.com",
  "etag": "{{ etag }}",
  "name": "projects/{{ google_project_id }}/serviceAccounts/aws-user@{{ google_project_id }}.iam.gserviceaccount.com",
  "oauth2ClientId": "{{ aws-user_client_id }}",
  "projectId": "{{ project_id }}",
  "uniqueId": "{{ gsa_unique_id }}"
}

GSA に対して iam.serviceAccountsTokenCreator のロールを Google アカウントに付与する

gcloud iam service-accounts add-iam-policy-binding \
  aws-user@{{ google_project_id }}.iam.gserviceaccount.com \
  --member=user:{{ google_account_id }} \
  --role=roles/iam.serviceAccountTokenCreator

AWS Web Identity Federation の設定を行う

OIDC プロバイダ accounts.google.com の jwks 配信サーバのTLS証明書の fingerprint を取得する

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html

下記の内容は上記の AWS ドキュメントに記載されている内容である。

curl https://accounts.google.com/.well-known/openid-configuration | jq -r .jwks_uri

↑のようにして account.google.com の jwks 配信サーバの URL ↓を取得する。

https://www.googleapis.com/oauth2/v3/certs

エンドポイントは https://www.googleapis.com であることがわかったので、このhttpsサーバで用いられている証明書の fingerprint を確認する。

openssl s_client -showcerts -servername www.googleapis.com -connect www.googleapis.com:443 < /dev/null

↑を実行すると↓のような文字列が確認できるが、www.googleapis.com は中間認証局 GTS CA 1O1 とルート認証局 GlobalSign によって署名されていることがわかる。

depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = upload.video.google.com
verify return:1

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html

複数の証明書が表示される場合は、表示される最後 (コマンド出力の最後) の証明書を見つけます。

今回は中間認証局 GTS CA 1O1 の証明書が最後に出力されていることから、中間認証局 GTS CA 1O1 の証明書の fingerprint を AWS 側に登録する。

depth=0

depth=1

中間認証局の証明書を /tmp/depth_1.pem として保存する。

openssl x509 -fingerprint < /tmp/depth_1.pem

↑の openssl コマンドで fingerprint ↓を得る。

SHA1 Fingerprint=DF:E2:07:0C:79:E7:FF:36:A9:25:FF:A3:27:FF:E3:DE:EC:F8:F9:C2

echo DF:E2:07:0C:79:E7:FF:36:A9:25:FF:A3:27:FF:E3:DE:EC:F8:F9:C2 | tr -d ":" | tr "[[:upper:]]" "[[:lower:]]"

実際に利用する値はコロンを除いた小文字になるため、↑で加工した値 ↓ を利用する。

dfe2070c79e7ff36a925ffa327ffe3deecf8f9c2

OIDC プロバイダ accounts.google.com の作成

前項で得た fingerprint を用いて OIDC プロバイダ accounts.google.com を作成する。

aws iam create-open-id-connect-provider \
  --url https://accounts.google.com \
  --thumbprint-list dfe2070c79e7ff36a925ffa327ffe3deecf8f9c2

サービスアカウントのUniqueIDをIdentity Proversのaudienceに追加する

aws iam add-client-id-to-open-id-connect-provider \
  --open-id-connect-provider-arn "arn:aws:iam::{{ aws_account_id }}:oidc-provider/accounts.google.com" \
  --client-id {{ gsa_unique_id }}

AssumeRoleするためのIAM ロールを作成する

gsa-aws-user.json

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::{{ aws_account_id }}:oidc-provider/accounts.google.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "accounts.google.com:aud": "{{ gsa_unique_id }}",
                    "accounts.google.com:sub": "{{ gsa_unique_id }}",
                    "accounts.google.com:oaud": "arn:aws:iam::{{ aws_account_id }}:oidc-provider/accounts.google.com",
                    "accounts.google.com:email": "aws-user@{{ google_project_id }}.iam.gserviceaccount.com"
                }
            }
        }
    ]
}

aws iam create-role --role-name gsa-aws-user --assume-role-policy-document file://gsa-aws-user.json

GSAのトークンを用いてawsコマンドを実行できるようにする

https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-sourcing-external.html

~/.aws/config の credential_process という仕組みを用い、 GSA のトークンからAWSの認証情報を作成するための設定を行う。

gsa-oidc.sh を配置する

下記の gsa-oidc.sh を PATH が通っている場所に配置する。

#!/bin/bash
set -eu -o pipefail
# ${1}:
#   gcloud configuration name.
#   (if you want to use current configuration, set empty "" string.)
# ${2}:
#   Google Cloud service account's email.
# ${3}:
#   AWS account id.
# ${4}:
#   AWS role name.

GCLOUD_CONFIGURATION=${1}
GSA_EMAIL=${2}
AWS_ACCOUNT=${3}
AWS_ROLE_NAME=${4}

GCLOUD="gcloud --configuration=${GCLOUD_CONFIGURATION}"
GCLOUD_ACCOUNT=$(${GCLOUD} config get-value account)
AUDIENCE="arn:aws:iam::${AWS_ACCOUNT}:oidc-provider/accounts.google.com"
GSA_ID_TOKEN=$(${GCLOUD} --impersonate-service-account=${GSA_EMAIL} auth print-identity-token --audiences=${AUDIENCE} --include-email)

AWS_ROLE_ARN="arn:aws:iam::${AWS_ACCOUNT}:role/${AWS_ROLE_NAME}"
AWS_ROLE_SESSION_NAME="gsa-oidc-${GCLOUD_ACCOUNT}"

aws --profile gsa-oidc sts assume-role-with-web-identity \
  --role-arn "${AWS_ROLE_ARN}" \
  --role-session-name "${AWS_ROLE_SESSION_NAME}" \
  --web-identity-token "${GSA_ID_TOKEN}" \
  | jq "{Version: 1} + .Credentials"

実行権限を付与しておく。

chmod a+x gsa-oidc.sh

aws-user という名前で gcloud の configuration を作成する

gcloud config configurations create aws-user
gcloud config set project {{ google_project_id }}
gcloud auth login {{ google_account_email }}

~/.aws/config で gsa-oidc.sh を用いて認証情報を得る設定をする

[profile gsa-oidc]
output = json

[profile gsa-aws-user]
credential_process = gsa-oidc.sh aws-user aws-user@{{ google_project_id }}.iam.gserviceaccount.com {{ aws_account_id }} gsa-aws-user

実行する

aws --profile gsa-aws-user sts get-caller-identity | jq -r .Arn

↑を実行すると↓のような出力を得られる。

arn:aws:sts::{{ aws_account_id }}:assumed-role/gsa-aws-user/gsa-oidc-{{ google_account_email }}

これで AssumeRole を GSA の認証情報を用いて行えることがわかった。

あとはロール aws-user に適切なポリシーを付与すれば、各種 AWS の機能を使えるようになる。

補足

中間認証局 GTS CA 1O1 の証明書の情報を確認する。

openssl x509 -text <<_EOS_
-----BEGIN CERTIFICATE-----
MIIESjCCAzKgAwIBAgINAeO0mqGNiqmBJWlQuDANBgkqhkiG9w0BAQsFADBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEGA1UEChMKR2xvYmFs
U2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjAeFw0xNzA2MTUwMDAwNDJaFw0yMTEy
MTUwMDAwNDJaMEIxCzAJBgNVBAYTAlVTMR4wHAYDVQQKExVHb29nbGUgVHJ1c3Qg
U2VydmljZXMxEzARBgNVBAMTCkdUUyBDQSAxTzEwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDQGM9F1IvN05zkQO9+tN1pIRvJzzyOTHW5DzEZhD2ePCnv
UA0Qk28FgICfKqC9EksC4T2fWBYk/jCfC3R3VZMdS/dN4ZKCEPZRrAzDsiKUDzRr
mBBJ5wudgzndIMYcLe/RGGFl5yODIKgjEv/SJH/UL+dEaltN11BmsK+eQmMF++Ac
xGNhr59qM/9il71I2dN8FGfcddwuaej4bXhp0LcQBbjxMcI7JP0aM3T4I+DsaxmK
FsbjzaTNC9uzpFlgOIg7rR25xoynUxv8vNmkq7zdPGHXkxWY7oG9j+JkRyBABk7X
rJfoucBZEqFJJSPk7XA0LKW0Y3z5oz2D0c1tJKwHAgMBAAGjggEzMIIBLzAOBgNV
HQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFJjR+G4Q68+b7GCfGJAboOt9Cf0rMB8G
A1UdIwQYMBaAFJviB1dnHB7AagbeWbSaLd/cGYYuMDUGCCsGAQUFBwEBBCkwJzAl
BggrBgEFBQcwAYYZaHR0cDovL29jc3AucGtpLmdvb2cvZ3NyMjAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnBraS5nb29nL2dzcjIvZ3NyMi5jcmwwPwYDVR0g
BDgwNjA0BgZngQwBAgIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly9wa2kuZ29vZy9y
ZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAGoA+Nnn78y6pRjd9XlQWNa7H
TgiZ/r3RNGkmUmYHPQq6Scti9PEajvwRT2iWTHQr02fesqOqBY2ETUwgZQ+lltoN
FvhsO9tvBCOIazpswWC9aJ9xju4tWDQH8NVU6YZZ/XteDSGU9YzJqPjY8q3MDxrz
mqepBCf5o8mw/wJ4a2G6xzUr6Fb6T8McDO22PLRL6u3M4Tzs3A2M1j6bykJYi8wW
IRdAvKLWZu/axBVbzYmqmwkm5zLSDW5nIAJbELCQCZwMH56t2Dvqofxs6BBcCFIZ
USpxu6x6td0V7SvJCCosirSmIatj/9dSSVDQibet8q/7UK4v4ZUN80atnZz1yg==
-----END CERTIFICATE-----
_EOS_

↑を行うと↓のような出力を得られる。

  :
Validity
    Not Before: Jun 15 00:00:42 2017 GMT
    Not After : Dec 15 00:00:42 2021 GMT
  :

中間認証局の証明書が 2021/12/15 に失効するため、中間認証局の証明書の fingerprint を更新する仕組みが必要になる。

blog.monophile.net

Author

Posts