Go to Qiita Advent Calendar 2024 Top
LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@shikazuki

.aws/configと.aws/credentials確認しつつ、AssumeRoleを理解する

Posted at

概要

今の会社ではAzureADでのSSOをIDプロバイダーとして利用してAWSを利用しています。その際、AdminやDeveloper権限を選択してコンソールにログインしています。
ここら辺があんまりきちんと理解できていないと感じたので、ドキュメントを読んで理解しようがモチベーションです。

今回見ていくページ

認証方法

IAM Identity Center (SSO)

.aws/config
[default]
sso_session = my-sso
sso_account_id = 111122223333
sso_role_name = readOnly
region = us-west-2
output = text

[profile user1]
sso_session = my-sso
sso_account_id = 444455556666
sso_role_name = readOnly
region = us-east-1
output = json

[sso-session my-sso]
sso_region = us-east-1
# IAM Identity Centerの設定のSSO用のURL
sso_start_url = https://my-sso-portal.awsapps.com/start
sso_registration_scopes = sso:account:access

この認証方法は、IAM Identity Centerを利用した際のSSO用の設定のようです。

IAM Identity CenterはIDソースを選択してユーザーを管理することができます。
AWS Organizations で組織あたり1つのみ持つことができ、ソースは以下のいずれかを選べます。

  • Identity Center ディレクトリ : Identity Center ディレクトリで自動的に設定
  • Active Directory : AWS Directory Service を利用しいていて、利用したい場合
  • 外部 ID プロバイダー : Azure ADとかが別にあり、利用したい場合

なので、複数のアカウントをまとめて管理したい時、外部のAzure ADのSSOを利用したい時など、IAM Identity Centerを有効にしてこの認証方法を使うのが良さそうです。

Short-term credentials

.aws/credentials
[default]
aws_access_key_id=ASIAIOSFODNN7EXAMPLE
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
aws_session_token = IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZVERYLONGSTRINGEXAMPLE

[user1]
aws_access_key_id=ASIAI44QH8DHBEXAMPLE
aws_secret_access_key=je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY
aws_session_token = fcZib3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZVERYLONGSTRINGEXAMPLE
.aws/config
[default]
region=us-west-2
output=json

[profile user1]
region=us-east-1
output=text

上記を確認すると、こちらもIAM Identity Centerが前提となっており、これは単にIAM Identity Centerからcredentialsの情報をエクスポートして利用するやり方のようです。
IAMロールの設定ごとに認証の有効期間が設定でき、最大期間は12時間です。
ただ、IAM Identity Centerがきちんと準備されているのであれば、これを利用する必要はなさそうです。

IAM role

.aws/credentials
[default]
aws_access_key_id=ASIAIOSFODNN7EXAMPLE
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
aws_session_token = IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZ2luX2IQoJb3JpZVERYLONGSTRINGEXAMPLE
.aws/config
[default]
region=us-west-2
output=json

[profile user1]
region=us-east-1
output=text
# 認証自体は default で指定した方法で認証する
source_profile=default
# この設定で指定する項目。認証後に assumeRole によってロールの権限が付与される
role_arn=arn:aws:iam::777788889999:role/user1role
role_session_name=session_user1

AWS CLIではsource_profileによる認証後、assumeRoleによってロールの権限が付与されます。
そのため、該当ロールの信頼されたエンティティには以下のような設定が必要です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

この例はAWSアカウントが「123456789012」のrootに対して付与しています。認証後にこのロールの権限をもらうことで、Roleが利用可能範囲の操作をAWS CLIから実行することが可能です。
この記載を見てもらう通り、別のAWSアカウントを指定することも可能なので、複数アカウントを持っており、認証自体は単一で扱い、ロールの切り替えによって利用するリソースを切り替えています。

認証の方法の例はAWSのドキュメントではShort-term credentialsとありますが、後述するLong-term credentialsでも可能です。

IAM IDプロパイダの設定をしておけば、assumeRoleWithSamlでも可能です。

Amazon EC2 instance metadata credentials

.aws/config
[default]
role_arn=arn:aws:iam::123456789012:role/defaultrole
credential_source=Ec2InstanceMetadata
region=us-west-2
output=json

[profile user1]
role_arn=arn:aws:iam::777788889999:role/user1role
credential_source=Ec2InstanceMetadata
region=us-east-1
output=text

Amazon EC2インスタンスからAWS CLIを実行するための設定です。上述のIAM Roleと同じでRoleの権限を起動時に付与しています。

Long-term credentials

認証としての利用はセキュリティリスクがあるので、検証以外では使用しない方が良い。
もし、利用している場合は定期的にアクセスキーの定期的に作り直した方が良い

.aws/credentials
[default]
aws_access_key_id=AKIAIOSFODNN7EXAMPLE
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

[user1]
aws_access_key_id=AKIAI44QH8DHBEXAMPLE
aws_secret_access_key=je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY
.aws/config
[default]
region=us-west-2
output=json

[profile user1]
region=us-east-1
output=text

IAMユーザーからアクセスキーを発行して利用する方法です。

AssumeRoleについて

前段のIAM RoleでAssumeRoleに触れました。
AssumeRole で利用するRoleには以下のような信頼されたエンティティの設定が必要でした。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

AssumeRoleとはAWSリソースへのアクセスに利用できる一時的なセキュリティ認証情報のセットを返すAPIとのことです。
実際にAWS CLIで実行してみましょう。上記の設定したRoleをdev-roleとします。

$ aws sts assume-role --role-arn <dev-roleのARN> --role-session-name <任意のセッション名(ex: dev)>

{
    "Credentials": {
        "AccessKeyId": "1111111111",
        "SecretAccessKey": "2222222222",
        "SessionToken": "3333333333",
        "Expiration": "2024-04-30T12:24:32+00:00"
    },
    "AssumedRoleUser": {
        "AssumedRoleId": "4444444444:dev",
        "Arn": "arn:aws:sts::5555555555:assumed-role/dev-role/dev"
    }
}

AccessKeyIdとSecretAccessKeyとSessionTokenが出力されており、Expirationから一時的に利用できるアクセス情報であることがわかります。

例えば、これらを環境変数として指定することで、dev-roleで実行が可能です。

export AWS_ACCESS_KEY_ID=1111111111
export AWS_SECRET_ACCESS_KEY=2222222222
export AWS_SESSION_TOKEN=3333333333

また、認証情報のセットを.aws/credentialsに設定することは、前段のShort-term credentialsと同じイメージです。
前段のIAM Roleによる認証方法は、これらAssumeRoleの作業の手間をなくしたものになるイメージです。

最後に

AssumeRoleを手動で実行してみて、どう動いているか理解できました。困ったらAssumeRoleを使いこなしたり、今の認証をIAM Identity Center (SSO)の方式に切り替えられたらいいなーと思いました。:smiley:

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?