雑記帳

■ [AWS] SAMLで認証しているユーザーの権限でAWS CLIを実行する

AWS Management ConsoleにFederated Userでログインを設定した場合には、IAM Userと違って、永続的なAccess Key Idを発行することができない。こういった場合には、STS (Security Token Service）を使って、一時的セキュリティ認証情報を取得する必要がある。

SAMLを使った場合は、AssumeRoleWithSAMLというAPIを使うのだが、そのままAWS CLIを使って手で実行するのは困難である。ということで、ツールを作ろうかと思ったのだが、さすがにすでに存在していたので、それを紹介する。

saml2aws

saml2aws は、いくつかのSAML IdPに対応したTemporary credentialsを取得するツールである。対応しているIdPは以下の通り。

• ADFS (2.x or 3.x)
• JumpCloud
• KeyCloak + (TOTP)
• Okta + (Duo, SMS, TOTP)
• PingFederate + PingID

それでは早速使ってみたい。

インストール

macOSの場合は、homebrewに対応している。

 $ brew tap versent/homebrew-taps
 $ brew install saml2aws

設定

PingOneで実行したかったのだが、未対応なのでOktaでやってみる。

 $ saml2aws configure

 Please choose the provider you would like to use:

 [ 0 ]:  ADFS

 [ 1 ]:  ADFS2

 [ 2 ]:  JumpCloud

 [ 3 ]:  KeyCloak

 [ 4 ]:  Okta

 [ 5 ]:  Ping

 Selection: 4

 URL []: https://<your_org>.okta.com/home/amazon_aws/deadbeaf/123
 Username []: <your_account>

 Configuration saved for IDP account: default

ここで入力するURLは、Oktaの場合だと、UserHomeに表示されるAWSにサインインするためのURLで良い。 Usernameは、Oktaにサインインするときに使うものを入れる。

設定はこれだけ。

認証

では、認証トークンを得るために、AWSにサインインしてみよう。

 $ saml2aws login
 Using IDP Account default to access Okta https://<your_org>.okta.com/home/amazon_aws/deadbeaf/123
 To use saved password just hit enter.
 Username [<your_account>]:
 Password: ***************

 Authenticating as <your_account> ...

   1) PUSH MFA authentication
   2) UNSUPPORTED: OKTA TOKEN:SOFTWARE:TOTP

 Select which MFA option to use: 1

 Waiting for approval, please check your Okta Verify app ............ Approved

 Selected role: arn:aws:iam::000000000000:role/<role>
 Requesting AWS credentials using SAML assertion
 Logged in as: arn:aws:sts::000000000000:assumed-role/<role>/<role_session_name>

 Your new access key pair has been stored in the AWS configuration
 Note that it will expire at 2018-03-12 19:25:04 +0900 JST
 To use this credential, call the AWS CLI with the --profile option (e.g. aws --profile saml ec2 describe-instances).

OktaでMFAを有効にしているため、MFA optionを選ぶように促される。ここでは、PUSH MFA authenticationである1を入力し、MFAを実行している。認証に成功すると、expireされる時刻が表示され、aws --profile samlと指定するとAPIが実行できると表示された。

AWS CLI実行

では、AWS CLIを実行してみよう。

 $ aws --profile saml sts get-caller-identity
 {
     "UserId": "ABCDEFG12345ZXYW9876S:<role_session_name",
     "Account": "000000000000",
     "Arn": "arn:aws:sts::000000000000:assumed-role/<role>/<role_session_name>"
 }

assumed-roleの権限で、APIを実行していることが確認できた。

ここで、AWS CLIが利用している認証情報を確認してみる。

 $ cat ~/.aws/credentials
 (snip)
 [saml]
 aws_access_key_id     = ABCDEFG12345ZXYW9876S
 aws_secret_access_key = T5on5Z...1wJrtp
 aws_session_token     = FQoDYX...dd1QU=
 aws_security_token    = FQoDYX...dd1QU=

samlというprofileが自動的に更新されているのが確認できる。aws_access_key_id以外は長いので省略しているが、これがSTSのAPIである、AssumeRoleWithSAMLを実行して得られた認証情報である。

対応しているIdPが限られているが、これはかなり便利だと思う。