Introduction This post revisits IAM Roles in AWS, which shows how to create EC2 instances with role-based rather than credential-based access. In that post, the AWS CLI was used to create all of the required AWS resources and dependencies between them were managed manually by copying values from the result of one command into other commands for building dependent resources. Here you will learn how to accomplish the same things with far less effort using AWS CloudFormation.
In my first post, IAM Roles in AWS you created an ec2 instance and directly accessed a restricted S3 bucket. Today, you’ll create a Java application, which will use an ec2 role to access the same restricted s3 bucket. Here’s what you’re going to do: Create a simple Java application Create an S3 bucket Create a customer managed policy Create an IAM role, using the customer managed policy, to manage access to the S3 bucket
Using IAM Roles to Control Access I don’t know about you but when I first started working in the cloud, I thought of it as an on-prem solution in AWS. By on-prem solution in AWS, I mean I thought about solutions in AWS the same way I’d solve problems in our on-prem data center. Over the next few posts, I’m going to talk about making the transition from on-prem designs to cloud-native or cloud-first designs.
Multiple Git Accounts If you contribute to multiple git repositories, for different organizations, and have multiple user accounts for the same git remote server (like gitlab.com), you’ve most likely ran into an issue when you try to clone a repo. Something like this: 1 2 3 4 5 6 7$ git clone email@example.com:project/repository.git Cloning into 'repository'... GitLab: The project you were looking for could not be found. fatal: Could not read from remote repository.