aws assuming existing role policy and testing to see if it works

We are going to assume an existing role that has permission to s3 bucket. So in this setup we will be setting up a policy called "mydummy-strong-role-s3" and then granted permission called "AmazonS3FullAccess".

This is what our trust policy looks like for mydummy-strong-role-s3. This says that user jeremydev can assume this role. 

{
  "Version": "2012-10-17",
  "Statement": [
      {
          "Effect": "Allow",
          "Principal": {
              "Service": "lambda.amazonaws.com"
          },
          "Action": "sts:AssumeRole"
      },
      {
          "Effect": "Allow",
          "Principal": {
              "AWS": "arn:aws:iam::<user-id-number>:user/jeremydev"
          },
          "Action": "sts:AssumeRole"
      }
  ]
}

Next, we will provide permission to this role. In the IAM -> ensure we have the role selected and then under permission -> Add permission. Add the permission "AmazonS3FullAccess".

We can create a policy and specify who can assume that role using the following 

To see which user your aws cli is running on, use the following command 

aws sts get-caller-identity

To test this out in your aws cli, let's assume this role by running 

aws sts assume-role --role-arn "arn:aws:iam::<role-id-aws>:role/mydummy-strong-role-s3" --role-session-name "SuperDevSession" which outputs the followings 

{
  "Credentials": {
      "AccessKeyId": "",
      "SecretAccessKey": "",
      "SessionToken": "",
      "Expiration": ""
  },
  "AssumedRoleUser": {
      "AssumedRoleId": "",
      "Arn": ""
  }
}

Next let's see if you can list the s3 resources using 

aws s3 ls



















Comments

Popular posts from this blog

gemini cli getting file not defined error

NodeJS: Error: spawn EINVAL in window for node version 20.20 and 18.20

vllm : Failed to infer device type