Review Google cloud IAM fundamentals and best practices

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.

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.