Most significant public clouds employ Identity and Access Management (IAM) to safeguard resources on their system. This is most emphatically true of the “Big Three” public cloud providers, Google Cloud Platform (GCP), Microsoft Azure, and Amazon Web Services (AWS).
Even though each of the leading public clouds includes an IAM architecture, such frameworks are not similar. To get the most out of your IAM in the cloud, you must understand the complexities of your IAM framework by IAM services comparison. Let’s look at those subtleties by contrasting and comparing the IAM tools on each of the three significant clouds.
Google Cloud vs. AWS vs. Azure
The GCP, Azure, and AWS IAM systems share the same core purpose and primary function points. At the heart of any IAM system is a user registry that each individual who accesses the cloud platform will use for authentication. All the providers we’ve discussed can use some identity confederation to connect to any existing identity systems in your business. Most companies will use Microsoft Active Directory with ADFS or a hosted solution, such as Okta.
GCP credentials can originate from practically anywhere in the Google ecosystem, including G Suite users, consumer Google accounts, and semi-service hijacking. When you use G Suite, you get access to federation services. Suppose you aren’t a G Suite subscriber. The Cloud Identity Zone The capability to federate with external people.
GCP makes use of the notion of projects. Each portfolio has its billing and IAM settings, and all rights apply to all assets in that development. (Remember that your username can be a member of many projects, each with a different role.)
Because rights get assigned at the project level, an organization often creates a GCP project for each application or effort to connect resources.
Each user account in Google’s environment may access several projects on Google Cloud, making credential management easy.
The directory on AWS connects with their worldwide identity services. Its “root account” (the top-level account for the company you work for) is another account you can use. Identity federation merely extends the core directory.
One distinctive feature of AWS IAM is that accounts established within the organization (rather than through federation) only get used within that organization. This is in contrast to Google and Microsoft. On the plus side, each group is self-sufficient. On the negative side, users may wind up having many credentials to gain access to different businesses.
The second distinguishing feature is that any user may create and use access keys to create a semi-account, an interactive account by allowing console access, or both. (Access keys must get produced to use the CLI.) All three vendors’ IAM systems also support the idea of groups, which allows permissions to apply at a more ideological level than specific online accounts.
In Terms of Roles and Policies
When applying rights to access resources, each cloud has its method, with a somewhat distinct language. Because it is the oldest and most mature public cloud, AWS provides the most flexibility regarding how you give and revoke access.
AWS rules can range from granting special access (such as reading from a single topic in SNS) to giving complete access to many resources (such as the default “Administrator access” policy).
Azure credentials are comparable to Google’s approach in that they may originate from a variety of Microsoft products, including Office 365. The Azure AD service, which includes both accounts and applications configuration, lies at the heart of Azure. Service principals are the accounts used by apps and other non-interactive services to access resources in Azure.
Similar to GCP, Azure allows user accounts to move between folders without logging out. Without having to handle many sets of credentials, each directory may have its membership.
In Terms of Flexibility,
Azure’s IAM also provides a unique method for delivering rights that sits between GCP and AWS. There are other fundamental roles accessible in Azure IAM, but the most typically allocated are Contributor and Owner. Member allows you to do anything you want with the resources in your scope. In contrast, the Owner provides the power to alter permissions on those assets.