When companies move from on-prem workloads to the cloud, common concerns arise around costs, security, and cloud user management. Each cloud provider handles user permissions in a slightly different way, with varying terminology and roles available to assign to each of your end users. Let’s explore a few of the differences in users and roles within Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform, and Alibaba Cloud.
AWS IAM Users and Roles
AWS captures all user and role management within IAM, which stands for “Identity and Access Management”. Through IAM, you can manage your users and roles, along with all the permissions and visibility those users and service accounts have within your AWS account. There are a couple different IAM entities:
Users – used when an actual human will be logging in
Roles – used when service accounts or scripts will be interacting with resources
Both users and roles can have IAM policies attached, which give specific permissions to operate or view any of the other AWS services.
Azure utilizes the RBAC system within Resource Manager for user permissions, which stands for “Role Based Access Control”. Granting access to Azure resources starts with creating a Security Principal, which can be one of 3 types:
User – a person who exists in Azure Active Directory
Group – a collection of users in Azure Active Directory
Service Principal – an application or service that needs to access a resource
Each Security Principal can be assigned a Role Definition, which is a collection of permissions that they can utilize to view or access resources in Azure. There are a few built-in Role Definitions, such as Owner, Contributor, Reader, and User Access Administrator, but you can also create custom role definitions as well depending on your cloud user management needs. Roles may be assigned on a subscription by subscription basis.
Google Cloud Platform IAM
Google Cloud Platform also uses the term IAM for their user permissions. The general workflow is to grant each “identity” a role that applies to each resource within a project. An identity can be any of the following:
Google account – any user with an email that is associated with a Google account
Service account – an application that logs in through the Google Cloud API
Google group – a collection of Google accounts and service accounts
G Suite domain – all Google accounts under a domain in G Suite
Cloud Identity domain – all Google accounts in a non-G-Suite organization
Roles in Google Cloud IAM are a collection of permissions. There are some primitive roles (Owner, Editor, and Viewer), some predefined roles, and the ability to create custom roles with specific permissions through an IAM policy.
Alibaba Cloud RAM
Alibaba Cloud has a service called RAM (Resource Access Management) for managing user identities. These identities work in slightly different ways than the other cloud service providers, though they have similar names:
RAM-User – a single real identity, usually a person but can also be a service account
RAM-Role – a virtual identity that can be assigned to multiple real identities
RAM users and roles can have one or more authorization policies attached to them, which in turn can each have multiple permissions in each policy. These permissions then work similarly to other CSPs, where a User or Role can have access to view or act upon a given resource.
Cloud User Management – Principles to Follow, No Matter the Provider
As you can see, each cloud service provider has a way to enable users to access the resources they need in a limited scope, though each method is slightly different. Your organization will need to come up with the policies and roles you want your users to have, which is a balancing act between allowing users to do their jobs and not letting them break the bank (or your infrastructure). The good news is that you will certainly have the tools available to provide granular access control for your cloud user management, regardless of the cloud (or clouds) you’re using.
Read more: feedproxy.google.com