What You Need to Know about AWS vs. Azure IAM Policies

In today’s world, the adoption of cloud infrastructure for running applications workloads is increasing by leaps and bounds. And why not, cloud infrastructure provides scalability, flexibility, cost-effectiveness, and ease of deployment. This shift means businesses can deploy applications faster than you can say "cloud," scale resources on demand, and innovate without the restrictions of traditional on-premises setups. No wonder everyone's on the cloud bandwagon — it's the life of the tech party!

Whoa! But hold on – before you start throwing cloud parties left and right, let's talk about the role of bouncers at this bash: cloud security. With the rapid adoption of cloud infrastructure, making sure your data stays safe and sound is more crucial than ever. After all, what's a party without some security to keep the gatecrashers out? Cloud security means protecting your sensitive data, ensuring your business complies with regulations, and fending off cyber threats which are getting craftier each day.

Alright, now let's talk about one important bouncer at this party: Identity and Access Management, or IAM. This bouncer has the list of who gets into the party and what areas they're allowed to visit. IAM is all about ensuring the right people (and only the right people) have access to the resources they need. No more, no less.

And here's the kicker: the principle of Least Privilege IAM. It's like giving your guests access only to the rooms they need to be in. Why let someone into the DJ booth if they're just there to enjoy the snacks? Least Privilege IAM ensures that users have just enough access to do their jobs and nothing more. This helps to minimize the blast radius if an account is compromised (or even to simply prevent honest mistakes) and keeps the party running smoothly without unwanted interruptions. So, while everyone’s enjoying the cloud bash, Least Privilege IAM is quietly ensuring everyone’s safety.

Now, imagine if you didn't implement Least Privilege IAM. It's like not restricting guests' movements. Bizarre things can happen, you have guests wandering into the DJ booth, the VIP lounge, and even the backstage area! You might even find someone trying to remix the DJ's playlist with their karaoke favorites! Not only does this create chaos, but it also creates risk: exposure to sensitive data or exposure of critical systems and applications. Without the least privilege, one compromised account could lead to a full-blown security disaster, bringing your cloud party to an abrupt and unpleasant halt. So, if you want to keep your cloud environment secure and your operations smooth, implementing Least Privilege IAM is not just a good idea — it's essential.

Every cloud provider implements IAM (Identity and Access Management) one way or another. Now let's dive deeper into understanding how IAM works in AWS and Azure (Azure IAM is referred to as Azure RBAC).

How does AWS IAM work?

Let’s talk about how AWS IAM rolls out the red carpet for your cloud party. Think of AWS IAM as the bouncer who ensures only the right guests get into the right rooms. AWS IAM lets you manage access to AWS services and resources securely by creating and managing AWS users and groups and using permissions to allow and deny their access to AWS resources.

Here are the building blocks of AWS IAM:

Polices: The Bouncer’s Rulebook

Policies in AWS IAM are like the bouncer’s rulebook or set of guidelines. For example, a rule can be created for the catering team in the party to be allowed to access only the kitchen and the serving area and nowhere else.

Policies can be attached to users, groups, or roles. We will learn more about users, groups, and roles in the upcoming sections.

Policies are written in JSON and include statements that specify the Effect (Allow or Deny), the Action (like s3:ListBucket), and the Resource (like a specific S3 bucket). Here’s a simple example of a policy that allows listing all S3 buckets:

{
  "Version": "2012-10-17",
  "Statement": [
	{
  	"Effect": "Allow",
  	"Action": "s3:ListAllMyBuckets",
  	"Resource": "*"
	}
  ]
}

There are two main types of policies:

1. Managed Policies

These can be AWS-managed or customer-managed. AWS provides a set of pre-built policies to get you started quickly. You can also create your own policies tailored to your specific needs.

2. Inline Policies

These are policies that you attach directly to a single user, group, or role. They provide a one-off, specific set of permissions. Inline policies maintain a one to one relationship with an entity only for the lifecycle of that entity.

Roles: Temp Access Card

Sometimes, you need to let an outsider, like a photographer or a caterer, into specific areas. IAM roles are like temporary access cards that grant access to resources for a limited time. Unlike users, roles do not have long-term credentials. Instead, roles are assumed temporarily and provide temporary security credentials.

Roles can be attached to users, groups, or other resources.

Here’s a simple example of a role that allows EC2 instances to read from an S3 bucket:

{
  "Version": "2012-10-17",
  "Statement": [
	{
  	"Effect": "Allow",
  	"Action": "s3:GetObject",
  	"Resource": "arn:aws:s3:::example-bucket/*"
	}
  ]
}

Users and Groups (guests and guest lists)

Imagine creating guest lists for your party. In AWS IAM, you create users (individual guests) and groups (guest lists). You can assign permissions or roles to users directly or, more conveniently, assign permissions or roles to groups.

For example, your catering team (group) needs access to just the kitchen (specific AWS resources), but not the DJ booth (other AWS resources). The head chef (user) and sous chef (user) can also be allowed permissions to access the guests section as well. So the permissions are assigned to the catering group to just access the kitchen, but we can add more permissions for the chefs in addition to the default catering group permissions.

Multi-Factor Authentication (MFA)

This is the VIP access check. Even if someone has the Access Card (Role) or the Badge (username and password), they need to provide additional proof (like a code from their phone) to gain access. This adds an extra layer of security, ensuring that only the true VIPs get in.

By carefully crafting policies and roles, you can implement the principle of Least Privilege, ensuring that users, applications, and services have only the permissions they need to do their jobs and nothing more. This keeps your cloud environment secure and your operations running smoothly without any unwarranted disruptions

How does Azure RBAC work?

Azure RBAC, helps manage access to Azure resources by allowing you to assign roles to users, groups, and applications at a certain scope. These roles define what actions users are allowed to perform and what resources they can access within Azure.

Here are the building blocks of Azure RBAC:

Role: The Bouncer’s Rulebook

In Azure RBAC, role definitions aka roles are very similar to the AWS Policies, like the bouncer’s rulebook or set of guidelines. These roles define what actions are allowed to perform and what resources can be accessed.

Roles can define Actions, Data Actions, NotActions, and NotDataActions. Here is a sample Contributor role definition

{
  "Name": "Contributor",
  "Id": "b24988ac-6180-42a0-ab88-20f7382dd24c",
  "IsCustom": false,
  "Description": "Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.",
  "Actions": [
	"*"
  ],
  "NotActions": [
	"Microsoft.Authorization/*/Delete",
	"Microsoft.Authorization/*/Write",
	"Microsoft.Authorization/elevateAccess/Action",
	"Microsoft.Blueprint/blueprintAssignments/write",
	"Microsoft.Blueprint/blueprintAssignments/delete",
	"Microsoft.Compute/galleries/share/action",
	"Microsoft.Purview/consents/write",
	"Microsoft.Purview/consents/delete"
  ],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
	"/"
  ],
  "Condition": null,
  "ConditionVersion": null
}

Roles can be assigned to users, groups, service principals, or managed identity. We will discuss these in more detail in the upcoming sections.

Azure RBAC has two type of roles:

1. Built-in role definitions

Azure includes a wide range of built-in roles. These built-in roles have a pre-defined set of permissions. These encompass general roles such as Owner, Contributor, and Reader, as well as roles specific for resource categories like Compute, Storage, and Networking. A complete list of these built-in roles can be found here.

For example:

Owner: Has full access to all resources, just like the person who organizes a party, has control over all aspects of the party.
Contributor: Can create and manage all types of resources but cannot grant access to others, like a party organizer who can set up the event but can’t invite guests.
Reader: Can view existing resources, similar to a guest who can observe the party but not make any changes.

2. Custom role definitions

Custom roles enable you to define permissions that precisely align with your organizational requirements. You can start from scratch or base a custom role on an existing built-in role, modifying permissions as necessary to tailor access control to your exact specifications. This flexibility ensures that you can implement the principle of least privilege effectively, providing users with only the permissions they need.

For example, suppose you need a role that allows users to manage virtual machines but not perform operations that involve the network or storage configurations. You could create a custom role with a JSON definition like this:

{
  "Name": "Virtual Machine Operator",
  "Id": "your-custom-role-id",
  "IsCustom": true,
  "Description": "Allows management of virtual machines, excluding network and storage operations",
  "Actions": [
	"Microsoft.Compute/virtualMachines/start/action",
	"Microsoft.Compute/virtualMachines/restart/action",
	"Microsoft.Compute/virtualMachines/deallocate/action",
	"Microsoft.Compute/virtualMachines/read",
	"Microsoft.Compute/virtualMachines/write",
	"Microsoft.Compute/virtualMachines/delete"
  ],
  "NotActions": [
	"Microsoft.Network/*",
	"Microsoft.Storage/*"
  ],
  "AssignableScopes": [
	"/subscriptions/your-subscription-id"
  ]
}

Scopes: The Venues

In Azure RBAC, scopes determine the level at which roles are assigned. These scopes can be at different levels within the Azure hierarchy:

Resource

Azure Resources are individual services or components within Azure, such as virtual machines, databases, storage accounts, and networking elements, that you can create, manage, and configure to build and operate your applications and solutions.

Consider resources as individual elements within a party room, like the DJ Booth. A guest can access the DJ booth only if he has the relevant scope assigned.

Resource Group

Azure Resource Groups are containers that hold related Azure resources, allowing for easy management, organization, and deployment of those resources as a single unit.

Consider Resource Groups are like designated sections within the party room, organizing related resources together for better management. Just as you might have a dance floor area, a snack table, and a VIP lounge all within one big party space, a resource group contains all the Azure resources that share a common lifecycle and can be managed as a single entity.

You can assign the scope of such sections to designated section managers to ensure the smooth running of the section itself.

Subscriptions

Azure Subscriptions are units of management, billing, and scale within Azure. Subscriptions can encompass multiple resource groups.

Management Groups

Azure Management Groups provide a hierarchical structure to manage and govern Azure resources across multiple Azure subscriptions.These management groups allow organizations to apply policies and security controls consistently, ensuring compliance and governance throughout their Azure environment.

Role Assignment

As we discussed earlier, roles can be allocated to users, groups, service principals, or managed identity. Role Assignment facilitates this allocation. Role Assignment attaches a principal (user, groups, managed identities, etc.) to the role along with a given scope.

Just as you might assign someone the role of "Bartender" or "Security Guard" to manage the drinks or keep an eye on the door, in Azure, you assign roles like "Virtual Machine Contributor" or "Network Contributor" to users or groups. This role assignment defines what actions they can take and what parts of the party (Scope) they have access to. It's all about making sure the right people have the right responsibilities to keep the party running smoothly and securely.

Security Principals

In Azure, security principals function similarly to guests and guest lists in AWS IAM. Just as you create users and groups in AWS IAM to manage access, in Azure RBAC, you create security principals. Principals are users, groups, service principals, and managed identities that require access to Azure resources.

Overall, security principals in Azure serve as the foundation for access management, allowing organizations to effectively control and monitor resource access based on user roles and group memberships.

AWS vs Azure

Policies vs Roles

AWS IAM’s policies provide fine-grained control over permissions, giving you the flexibility to create highly specific access rules. Azure RBAC’s roles simplify this by grouping permissions into roles, which can be easier to manage, but might require custom roles for specific needs.

Scope of Access

Both systems allow scoped access, but Azure RBAC’s hierarchy (management group, subscription, resource group, resource) can provide more structured and scalable management across large environments. AWS IAM relies more on attaching policies to roles and users, which can be straightforward but may require more management as your cloud footprint grows.

Flexibility and Complexity

AWS IAM’s fine-grained policies offer high flexibility but can become complex to manage at scale. Azure RBAC’s role-based approach can be less complex, but might need custom roles for very specific access needs.

Both AWS IAM and Azure RBAC offer robust frameworks for managing permissions and access control in their respective cloud environments. The choice between them depends largely on your specific needs, existing infrastructure, and familiarity with the platforms. AWS IAM provides a user-centric, policy-driven approach, while Azure RBAC offers a more hierarchical, role-based model that can simplify large-scale management.

Whichever cloud provider you choose, it is critically important to understand and implement the principles of Least Privilege IAM. Ensuring that applications, services, users, groups, etc. have only the permissions they need reducing the risk of unauthorized access and potential security breaches.

This is where appCD can be of immense help. appCD can help organizations build a secure cloud infrastructure based on the Least Privilege principles on both AWS and Azure. It also helps you visualize your cloud infrastructure, making it easier to identify over-permissioning and provisioning, and ensure resources are allocated efficiently.

With appCD, you can enjoy your cloud party with the confidence that your data and applications are protected by a robust, well-implemented IAM strategy. Seamlessly manage your cloud environments across multiple platforms, ensuring security, compliance, and optimal resource utilization.

Learn more about appCD and Infrastructure from Code.