AWS Identity & Access Management (IAM) Posts

A Quick Overview of IAM Permission Policies: AWS-Managed, Customer-Managed, and Inline Policies

An overview of AWS IAM policies

In AWS IAM, permission policies play a crucial role in securely controlling access to your AWS environment. You can attach three types of permission policies to your identities: AWS-managed, customer-managed, and inline policies. In most cases, AWS recommends using managed policies over inline policies, especially customer-managed policies created from AWS-managed policies. However, there may also be cases for inline policies. In this post, we will quickly explore IAM’s permission policies to help you decide which is best for you.

By the way, we will only talk about AWS IAM’s identity-based permission policies in this post. The resource-based trust policies used in IAM roles, in which you specify the principals you trust to assume a role, will be out of the scope of this post. So, when we use the ‘policy’ term below, it will only refer to an IAM permission policy: AWS-managed, customer-managed, or inline. Then, let’s begin.

So, when you attach a policy to an identity (a user, group of users, and a role), that policy determines whether to allow or deny access to your AWS resources. Hence, with security threats in mind, choosing the right policy type for your needs is essential, as well as granting the least privilege. But you wouldn’t want to increase the management overhead while doing this, right?

Each IAM policy type has its use cases. So, let’s analyze each one to see what features it offers.

Continue reading the A Quick Overview of IAM Permission Policies: AWS-Managed, Customer-Managed, and Inline Policies blog post.

AWS IAM Users vs. Roles: Which to access your AWS resources?

AWS IAM users vs. roles - Shikisoft Blog

AWS Identity and Access Management, or IAM, is a critical AWS component controlling access to your AWS resources. The IAM user and the IAM role are two crucial IAM concepts with similar features. So, sometimes, it can be difficult to tell the difference between them. In this post, we will discuss the similarities between AWS IAM users and IAM roles and how they differ.

Continue reading the AWS IAM Users vs. Roles: Which to access your AWS resources? blog post.

Sharing Your AWS CodeCommit Repository With Other Developers

Sharing Your AWS CodeCommit Repository

You started using AWS CodeCommit as your remote private Git repository and liked its cost-effective, easy to manage, and serverless nature. Now you would like to invite other developers to your project and collaborate with them. How can you achieve this?

In this post, I will talk about the steps you need to make your repository accessible to other developers. Let’s start!

Continue reading the Sharing Your AWS CodeCommit Repository With Other Developers blog post.

AWS Lambda IAM Authentication for Amazon RDS With Python: Secure, But Limited

Amazon RDS Iam Authentication

Where do you keep your DB credentials in your AWS Lambda functions that you use to access your Amazon RDS databases? Hardcoded? No! Environment variables? Well, you might be using AWS Secrets Manager, right? It would be great! But did you know that you can also use the IAM role of your AWS Lambda function and its temporary credentials to do this?

Yes, there are different ways to manage your database credentials in your AWS Lambda functions. In this post, I will talk about one of the most secure methods, using IAM authentication of Amazon RDS, with an example of an AWS Lambda function developed in Python. I will use an Amazon RDS - MySQL DB instance, but IAM authentication is also supported on PostgreSQL DB instances as well.

Continue reading the AWS Lambda IAM Authentication for Amazon RDS With Python: Secure, But Limited blog post.

Triggering AWS Step Functions by AWS API Gateway Calls

If you recall, in a previous blog post I discussed AWS Step Functions as a great service for orchestrating your AWS Lambda functions by giving an example. Today, I will show you how you can integrate your API Gateway resource methods with your AWS Step Functions state machines so that you can trigger your state machines with API calls.

Actually the benefits are obvious. Instead of serving our Lambda functions as separate endpoints and orchestrating which one to call and when in our front end; we can use a single endpoint and pass all logic to the back end. Then our back end, in this case our state machine, will execute the functions in sequential or parallel. This method especially suits well to cases when all these function calls are necessary to complete a single business action.

Continue reading the Triggering AWS Step Functions by AWS API Gateway Calls blog post.