{"id":10037,"date":"2022-03-15T17:22:04","date_gmt":"2022-03-15T11:52:04","guid":{"rendered":"https:\/\/opstree.com\/blog\/\/?p=10037"},"modified":"2022-03-15T17:22:04","modified_gmt":"2022-03-15T11:52:04","slug":"know-how-to-access-s3-bucket-without-iam-roles-and-use-cases","status":"publish","type":"post","link":"https:\/\/opstree.com\/blog\/2022\/03\/15\/know-how-to-access-s3-bucket-without-iam-roles-and-use-cases\/","title":{"rendered":"Know How to Access S3 Bucket without IAM Roles and Use Cases"},"content":{"rendered":"\n

We all have used IAM credentials to access our S3 buckets. But it’s not a very safe or recommended practice to keep our Access keys and Secrets stored in a server or hard code them in our codebase.
Even if we have to use keys, we must have some mechanism in place to rotate the keys very frequently (eg: using Hashicorp Vault). Another widely adopted method is to use IAM roles attached on the EC2 instance or the AWS service accessing the bucket.<\/p>\n\n\n\n

But, what if we need access to the bucket from an on-premise Data Center where we can not attach an IAM role?<\/p>\n\n\n\n

Yes, we can obviously use IAM credentials and secret tokens with the rotating mechanism. But setting up the key rotation mechanism itself could be another overhead if we do not have one already in place. What if we do not require keys or roles without making the bucket public?

In this blog, I will make an attempt to cater to this problem with another alternate and easy solution.<\/p>\n\n\n\n\n\n\n\n

Let’s first learn how we can access an S3 bucket without<\/strong> IAM credentials or IAM roles. Then we can move to the part of accessing it from the Data Center.<\/p>\n\n\n\n

We need to make two small changes in order to achieve the same. In this example, I have created a bucket named – \u201cs3-access-test-techdemos\u201d with all the default settings.
Now, we can see as I have no AWS credentials configured, hence I am not<\/strong> able to list or access the s3 bucket.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Step 1: <\/strong><\/p>\n\n\n\n

I will edit the S3 bucket policy and change it. The bucket policy below is to allow accessing the bucket from my ISP’s router public IP address. You can change it to your\u2019s own. (Run curl ifconfig.me or visit https:\/\/whatismyipaddress.com\/)
The bucket policy would look something like below:-<\/p>\n\n\n\n

<\/p>\n\n\n\n

Code link is given here<\/a>

With this bucket policy we are allowing access to publicly (“Principal”: “*”<\/em>) and hence do not require IAM credentials or roles. But at the same time restricting access from only IpAddress: 45.64.225.122<\/em>

<\/p>\n\n\n\n

Step 2<\/strong>: <\/p>\n\n\n\n

Go to CLI and update the command by appending \u201c--no-sign-request<\/code>\u201d <\/p>\n\n\n\n

aws s3 ls <your-bucket-name> --no-sign-request<\/code>
<\/p>\n\n\n\n

<\/p>\n\n\n\n

As you can see the bucket has been listed. Similarly, we can upload or download files to S3.<\/p>\n\n\n\n

<\/p>\n\n\n\n

When we run an AWS CLI command, in the backend a request URL is generated using the AWS credentials we provide, which determines whether we have access to the bucket or not. Usually, it is called the signed URL. 
In our case, we haven\u2019t configured any credentials.
Basically, –no-sign-request (boolean) means  AWS CLI will not sign the requests when a request URL is generated. i.e credentials will not be loaded if this argument is provided. We are doing this because our bucket is always accessible from my public IP \u2192 45.64.225.122<\/em>.<\/p>\n\n\n\n

This IP could be our Data Center end router, Ip. but that will not be a very recommended method to access buckets.<\/p>\n\n\n\n

Now that we are able to access the bucket we can think of its use cases.<\/p>\n\n\n\n

<\/p>\n\n\n\n

  1. Accessing the bucket from on-premise data center<\/strong> :-<\/li><\/ol>\n\n\n\n

    Since in this article, we are not interested in accessing our S3 bucket\/s using IAM credentials\/roles from an on-premise data center, hence we will use solutions like AWS Direct Connect<\/em><\/strong> to connect the AWS Cloud services<\/em><\/strong> from on-premise.<\/p>\n\n\n\n

    After AWS Direct Connect connections have been established, we can establish access to Amazon S3 in the following ways:<\/p>\n\n\n\n