記事:
仕様:
例:
aws_profile=example aws iam list-virtual-mfa-devices --profile $aws_profile --query 'VirtualMFADevices[?!EnableDate].SerialNumber'
aws_profile=example mfa=$(aws iam list-virtual-mfa-devices --profile $aws_profile --query 'VirtualMFADevices[?!EnableDate].SerialNumber' --output text) for mfa_serial in $mfa; do \ echo "# $mfa_serial"; \ read -p "Hit enter to delete: "; \ aws iam delete-virtual-mfa-device --profile $aws_profile --serial-number $mfa_serial; \ done
対策:
記事:
IAM roleの暗黙的自己信頼が無くなった
やりたい事:
account1:
account2:
account3:
[account1] output = json region = ap-northeast-1 [account2] output = json region = ap-northeast-1 role_arn = arn:aws:iam::<account1 id>:role/role-readonly source_profile = account1 [account3] output = json region = ap-northeast-1 role_arn = arn:aws:iam::<account2 id>:role/role-readonly source_profile = account2
セキュリティ上、アクセス可能なIAM userやIAM roleが放置されると良くない。
IAM user:
IAM role:
記事:
# account1にIAM userがあるとする aws configure --profile account1 cat ~/.aws/config [account1] output = json region = ap-northeast-1 [account2] output = json region = ap-northeast-1 role_arn = arn:aws:iam::<account1 id>:role/role-admin source_profile = account1
rm -r ~/.aws/cli/cache
... "Sid": "BlockMostAccessUnlessSignedInWithMFA", "Effect": "Deny", "NotAction": [ "sts:AssumeRole",...
ansibleやterraformといった外部ツール自体がMFAに対応していない場合、MFAを必須にすると動作しなくなる。
aws sts assume-role \ --role-arn "arn:aws:iam::<account2 account id>:role/role-admin" \ --role-session-name "account2-admin-session1" \ --duration-seconds 3600 \ --profile account1 > account2-admin-session1.json export AWS_ACCESS_KEY_ID=$(cat account2-admin-session1.json | jq -r '.Credentials.AccessKeyId') export AWS_SECRET_ACCESS_KEY=$(cat account2-admin-session1.json | jq -r '.Credentials.SecretAccessKey') export AWS_SESSION_TOKEN=$(cat account2-admin-session1.json | jq -r '.Credentials.SessionToken') aws s3 ls
記事:
一つのAWSアカウントにIAM userを作り、他のAWSアカウントではIAM roleにswitchできる。
多段も可能。login -> role-A -> role-B
AWS_SRC_ACCOUNT=<src account> AWS_ORG_ACCOUNT=<organization account> aws organizations describe-account \ --query 'Account.Name' \ --account-id $(aws sts get-caller-identity --profile $AWS_SRC_ACCOUNT --query 'Account' --output text) \ --output text \ --profile $AWS_ORG_ACCOUNT
IAMユーザのサインイン画面のURLはデフォルトアカウントIDだが、aliasが複数設定できる。 aliasを設定しても、accountIDのリンクは使える。
LambdaはIAMを触る強い権限が必要になる。そうするとAdminになってしまうが、それが嫌な場合。
APIによって、リソースが指定できる場合と、指定できない場合がある。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "ec2:*" ], "Condition": { "StringEquals": { "ec2:ResourceTag/Name": "web" } }, "Resource": [ "arn:aws:ec2:ap-northeast-1:<account id>:instance/*" ] } ] }
AWS_PROFILE=default AWS_REGION=ap-northeast-1 EC2_ID=i-xxxx aws ec2 create-tags --dry-run --resources $EC2_ID --tags "Key=test-key,Value=test-val" --profile $AWS_PROFILE --region $AWS_REGION # 拒否された場合のメッセージ An error occurred (UnauthorizedOperation) when calling the CreateTags operation: You are not authorized to perform this operation. # 許可された場合のメッセージ An error occurred (DryRunOperation) when calling the CreateTags operation: Request would have succeeded, but DryRun flag is set.
jsonのままではAllow/Denyの挙動が把握しにくいのでシミュレータを使う。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "aws-portal:ViewBilling" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "aws-portal:ViewUsage" ], "Resource": "*" } ] }