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.
But, what if we need access to the bucket from an on-premise Data Center where we can not attach an IAM role?
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.
Nowadays, it is very common to run applications on Spot instances. In this scenario, where a spot instance could be terminated at any point of time because of AWS pulling back their resource or ASG Scale-In incident, we need to have something in place to handle the termination smoothly so that we can complete our final tasks before the system shutdown. It could be executing some scripts, unmounting some storage device, shipping final log files to S3, or uploading cache data in a centralized server like Redis. Today, I will attempt to cater to this problem.
First of all, let’s think of trying to run a custom script prior to shutdown in our local system. If everything works fine, the same would be applicable for ec2 spot instances too.
But Why Json ?
We generally think JSON means data provided general output from any API. But, if we talk about any technology, JSON is a very common programming language or we can say format, which is used as the output format of any resource. While using DevOps tools like Docker, Ansible, or any other tool, we generally get the output in JSON format when we use any output command like Docker inspect or Ansible facts gather.
During this lockdown period, people are usually working from home which means they all are contributing to work by staying at home. So, if someone wants to work on something online, such as on a particular private or public server of a company, depending on the scenario, will need a network route to that server.
Meaning, they first need access to that particular server either via a public network or using VPN. These things have their own set of complexities. Therefore, we will discuss a few aspects of network access & their drawbacks:
In the last blog, we covered a few and important security practices of AWS IAM but unfortunately, we didn’t cover many security options. So, we bring to you another AWS IAM blog. This blog covers the other remaining and also the important AWS IAM security options. So, it’s time to wear your ironman suit and get started with security edition part-2 [ The endgame ]. Here we go!