Every major cloud provider has some form of Identity and Access Management (IAM) that is used to secure resources within their platform. This is certainly true of the “Big Three” public cloud providers, Google Cloud Platform (GCP), Microsoft Azure, and Amazon Web Services (AWS).
Yet while each of the major public clouds has an IAM framework, those frameworks are far from identical. In order to get the most out of IAM on the cloud that you use, you need to know the nuances of your IAM framework.
Let’s take a look at those nuances by comparing and contrasting the IAM tools on each of the three major clouds.
Directory Services—Authentication
The IAM platforms for GCP, Azure, and AWS all have the same basic goal and major function points. At the core of each IAM platform is a directory to the users that each person accessing the cloud platform will use for authentication. All the providers we are discussing have the ability to leverage some form of identity federation to access any identity systems you may already have in your organization. For most organizations, this means Microsoft Active Directory using ADFS, or a hosted solution like Okta.
GCP identities can come from almost anywhere in the Google ecosystem—from G Suite users to consumer Google accounts to non-interactive service accounts. If you are a G Suite user, you have access to federation services. If you aren’t a G Suite user, then the functionality to federate with an external authentication provider is referred to as the Cloud Identity Domain. Each user account in Google’s ecosystem can access multiple projects on Google Cloud, which makes it easier to manage credentials.
Azure identities are similar to Google’s offering, as they can come from multiple places inside the Microsoft family of products, including Office 365. At Azure’s core is the Azure AD service, which contains both accounts and application configuration information. The accounts used by applications and other non-interactive services to access resources inside Azure are called service principals. Similar to GCP, Azure allows user accounts to switch between multiple directories without the need to log back in. Each directory can have its own subscriptions without having to manage multiple sets of credentials.
In AWS, the directory is integrated with their global identity services, and its “root account” (which is the top-level account for the organization you work under) can be the same account you use to shop. Identity federation is simply a service that extends the core directory.
One unique thing about AWS IAM is that accounts created in the organization (not through federation) can only be used within that organization. This contrasts with Google and Microsoft. On the good side, every organization is self-contained. On the bad side, users can end up with multiple sets of credentials they need to manage to access different organizations.
The second unique element is that every user can have a non-interactive account by creating and using access keys, an interactive account by enabling console access, or both. (Side note: To use the CLI, you need to have access keys generated.)
The IAM solutions with all three of these providers also allow the concept of groups to apply permissions at a more abstract level than with individual user accounts.
Roles and Policies—Authorization
In terms of actually applying permissions to access resources, each cloud has its own way to do this, with a slightly different spin on the terminology that is used. As you would expect, because it is the oldest and most mature of the public clouds, AWS has the most flexibility in how you can grant or revoke access.
Within AWS, you create policies that can grant highly specific access (down to just reading from a single topic in SNS) up to allowing full access to all resource types (like in the predefined “AdministratorAccess” policy). When you have either created a custom policy or selected which default policies you want to use, the policies can be assigned directly to individual users, groups, or to roles. A role in AWS is an object that acts as an abstraction layer between policies and accounts. Some organizations find it easier to group all their policies into roles, and then assign roles to groups and users as required. An example would be organization policies by service—and then attaching the service to the groups that work with it instead of having to track each policy on all the potential groups and users that need it.
GCP uses the concept of projects. Each project has its own billing and its own IAM configuration, and all permissions apply to all resources within that specific project. (Remember that your user account can be a member of multiple projects and have a different role in each project.) Typically, an organization will make a GCP project per application or initiative so that resources are all related, because permissions are assigned at the project level. A project contains predefined roles which are reader (read-only), editor (reader+modify resources), and owner (editor+modify IAM and billing). You have the ability to create and define custom roles that can be assigned to users and groups as well.
Azure’s IAM also has a unique model for assigning permissions that falls somewhere between GCP and AWS in terms of flexibility. There are quite a few standard roles available within Azure IAM, although in my experience, contributor and owner are the two most commonly assigned. Contributor allows anything to be done to the resources within your scope, and Owner adds the ability to change permissions to those resources. (When I say scope, I mean the level at which you are granted permission.)
In Azure, the levels are: the entire subscription, which allows access to all resource groups; to an individual resource group, or to individual resources. A resource group is unique to Azure, and is very useful once you get used to it. All resources deployed in Azure need to be in a resource group.
Why I like resource groups: besides isolating common resources, each resource group tracks deployments that happen with it and can simply be removed—and all resources in it are deleted instead of having to remove them individually, as in other clouds. There is an additional IAM level above subscription that allows for the creation, tracking, and administration of subscriptions when you have an Enterprise Agreement (EA) with Microsoft. (Microsoft recommends individual subscriptions be given to groups within the company to provide isolation for tracking chargebacks and permissions.)
Conclusion
Although the IAM solutions provided in the Azure, AWS, and GCP clouds all have slightly different approaches, they all address the needs of any organization running workloads to secure access and control of resources, for as large or small a group as required.
