AWS, Azure and Google all offer identity and access management services to help admins set limits on user activity,...
as well as define broader controls for user groups based on job type or role.
Here, we'll dive into the details of Google's cloud identity and access management (IAM) service, as well as some best practices to help you get started.
The basics of user identity and authentication
Every cloud IAM service has a similar hierarchical structure in which the foundation is the authentication of individual users or services. This, in turn, can be used to create groups. An admin can assign permissions to users and groups to perform specific actions on one or more cloud services. Collections of permissions are typically called roles, and admins link roles to users and groups via policies.
There are three ways to authenticate one's self, establish identity and gain permission to use Google cloud services: through a user account, service account or API key. User accounts are associated with any email address. Service accounts are tied to an application and are either built into the Google Cloud Platform (GCP) service -- such as accounts for Cloud Functions, App Engine or Compute Engine -- or established by a GCP project owner or administrator.
Groups are collections of accounts that simplify the assignment of permissions to users with similar needs or responsibilities. GCP can recognize users from a particular G Suite domain or external domains that a G Suite administrator configures in the G Suite Cloud Identity service. Google cloud IAM also defines two special groups: allAuthenticatedUsers and allUsers. The former is any authenticated user, while the latter comprises anyone on the internet trying to access GCP services. Regardless of the source, IAM can assign permission to any group.
A closer look at resources, permissions and roles
The core purpose of Google cloud IAM is to control access to GCP resources, which are the individual instantiation of various services. For example, an n1-standard-2 Google Compute Engine instance in the us-west1 region, or a Cloud Bigtable instance in us-central-1, would each be a resource.
Cloud administrators use IAM to grant permissions to various resources or collections of resources in a GCP project. These permissions are granular and established by the API of each service. For example, there are more than two dozen permissions for Bigtable, such as the right to get information about a Bigtable instance or read rows from a table.
Since different types of jobs or tasks typically require several different permissions, IAM offers roles -- which, as stated earlier, are a collection of permissions. To simplify security management, Google cloud IAM has several "primitive" roles, such as Owner, Editor and Viewer, and several predefined roles for each service. If predefined roles don't meet their needs, admins can define custom roles.
Close, but not equal
While the three major cloud IAM services from AWS, Azure and GCP are more alike than not, there are differences for users to note. For example, while GCP and Azure accounts can be used in any organization or project, AWS enables you to create specific accounts that can only be used within that organization.
In general, AWS has the most granular level of permissions controls -- such as the ability to limit a user to adding items to a particular S3 bucket. However, Azure and GCP arguably make it easier to control policies for resources with similar security needs, using, respectively, Azure resource groups and GCP project policies and roles. Nevertheless, all three vendors provide ample flexibility to meet most security needs.
The link between roles and users is made through an IAM policy. Policies are a statement of users with a particular set of access rights. The final step in the security chain is to connect policies to resources.
Admins can also organize policies as a hierarchy. This lets them establish a set of basic policies for an entire organization that applies to all resources within it.
Setup and best practices
To set up and manage Google cloud IAM controls, use the GCP console. Select "IAM" from the console main menu, and then select a project to manage. Next, add users to the project and assign roles.
Always follow the principle of least privilege, and ensure users don't have more privileges than they need. Consider using predefined roles as a default when you assign roles since they are more granular than primitive roles.
Also note that policy hierarchy is one-way -- top-down -- and that a more restrictive policy established for a child resource has no effect on its parent or siblings. Nevertheless, in the spirit of least privilege, it's best to establish organization-level IAM policies as defaults that are maximally restrictive and then loosen them when needed for a particular organization or project.