Cloud IAM: Identity and Access Management

A crucial part of cloud security involves managing user identities, their permissions, and the resources they have access to. Organizations may have users accessing public cloud resources from a number of different devices and networks. And this can be an extremely challenging task.

Additionally, organizations may be utilizing multiple clouds and managing access across all of those public clouds. Most public cloud vendors today provide Cloud Identity and Access Management (Cloud IAM) frameworks to help facilitate and secure users’ identities and access to resources.

Cloud IAM provides fine-grained access control and visibility for centrally managing cloud resources. Let’s take a closer look at cloud identity and access management in the context of Google Cloud Platform and G Suite, and how organizations can make use of the cloud IAM framework as a means to secure and provide access to resources for their users.

Enhanse your cloud identity and access management with CASB

Try SpinOne

What is Cloud IAM?

Cloud IAM (Cloud Identity and Access Management) is a key part of an organization’s overall cyber security strategy when it comes to securing resources in the public cloud. Cloud IAM helps organizations manage access control by helping to define “who” has “what” access for “which” resource. The who are members, the what are the role and the resources are anything we want to grant permissions on in the public cloud.

One of the key aspects of security when it comes to a user accessing resources is having mechanisms in place that prove that users are who they say they are whether they are accessing public cloud resources from on-premise hardware and networks, or from a mobile device connected to the Internet. Let’s take a look at the following aspects of cloud Identity and Access Management and how each is able to bolster an organization’s public cloud security:

Google Cloud Identity and Access Management

When managing Identity and Access control on public cloud resources, it’s important to follow the principle of “least privilege.” This principle aligns well with most organizations’ security policies. In other words, our goal is to restrict user privileges to the minimum necessary to access resources. This applies whether the resources are located on-premise or in the cloud.

Best Practices for cloud IAM access assignment include:

  • Use Predefined roles over Primitive roles (differences explained below)
  • Treat each part of an application controlled by cloud IAM as a separate trust boundary
  • Grant roles at the smallest scope needed
  • Restrict the number and specifics of who can operate as a service account
  • Restrict who can create service accounts
  • Be restrictive on granting owner roles to members. This allows the modifying and managing of the IAM policy for that resource

Google Cloud Identity
When thinking about G Suite Cloud Identity and Access Control, we first establish the identity of a user, group, or domain, and then apply Google Cloud permissions to provide access control. Identity in the context of Google Cloud Platform (Google’s nomenclature is members) can be one of the following:

Service Account management – allows creating an identity such as code

Google Cloud Permissions and Roles

In today’s RESTful API-driven world, public cloud vendors are heavily using RESTful APIs to allow customers to interact with their public cloud resources. This holds true as well with defining permissions in the public cloud, using IAM. Permissions define which operations are allowed on a given resource in the public cloud. As is the case with Google, these permissions are represented in the form of the following:

  • ..
  • pubsub.subscriptions.consume as an example

Since the interaction with public cloud resources is very heavily RESTful API driven, often the available permissions align themselves with the RESTful API methods that are exposed. So, generally, there is a 1:1 correlation with permissions to API call that is exposed.

Roles are collections of permissions that are directly assigned to a specific user. In fact, with Google Cloud Platform, you cannot directly assign permissions to a user, but rather assign roles to a user. Roles make assigning permissions very efficient in that a user assumes all the permissions that are defined in that role. So, you can create role-based access permissions that define which permissions a typical user in that role would assume.

As an example, Google Cloud Platform has three types of roles that can be assigned via cloud IAM:

Primitive roles

    – The primitive role is much of what you would expect from standard-issue permissions found in many different types of systems. These are standard roles that should be familiar to most organizations – Owner, Editor, Viewer
Role NameRole TitlePermissions
roles/viewerViewerPermissions for read-only actions – the state is preserved
roles/editorEditorIncludes Viewer permissions and permissions to modify the state
roles/ownerOwnerIncludes all Editor permissions and includes managing access control, billing

Predefined roles – The predefined roles that Google Cloud Platform offers are more granular than the legacy primitive roles. They allow for more fine-grained control over access. So, while an might be able to publish and have access to more actions, a predefined publisher role may only be allowed to publish.

Predefined roles

Custom roles – The custom roles are where we can truly get creative when it comes to the exact permissions we want to include in a role. When organizations want extremely granular and customized roles that truly align as closely as possible to the role-based access they want to assign to member objects, customized roles can accomplish this. With customized roles, we would get into being able to uncover the low-level RESTful API-based control mentioned earlier.

Policy-Based Cloud Access

Adding to the building blocks of cloud Identity and Access Management includes defining IAM Policy. What is Policy as it relates to Google public cloud IAM? IAM Policy defines which objects (members) are assigned to which role. Users could be granted their role based on matched criteria presented in a policy.

With cloud IAM policies, they are organized hierarchically with the organization node being the top-level entity. Policy flows from top to bottom with child resources inheriting the policies assigned on the parent entity. This does not flow the other way around with child policy affecting parent entities, etc.

Policies can be managed via API in the Google Cloud Platform using IAM methods which allow:

  • Setting policies – setIamPolicy()
  • Getting policies – getIamPolicy()
  • Testing permissions for a resource – testIamPermissions()

Of course, RESTful API interaction with policies is much preferred for automating policy as well as interacting and making, or getting, bulk changes from the policy API.

Intuitive Single Management Interface

With Google Cloud Platform Identity and Access Management, organizations get a single management plan to be able to manage users, roles, resources, policies, API endpoints, etc. Cloud IAM tasks are easily performed from the same management plane, allowing a single “pane of glass” approach to configuring members, building roles with the appropriate permissions, using policy to define which members get which roles, and other cloud-driven IAM tasks.

IAM & admin settings

IAM Auditing

Auditing is a staple when it comes to securing systems either on-premise or in the cloud. It helps to give visibility and accountability to G Suite administrators and other users for any actions they may perform in business-critical systems.  Similarly, auditing, as it relates to cloud IAM, allows organizations to determine who did what, wherein the system, and when it was done.

With Google Cloud Platform IAM auditing, there are two audit logs for each project and organization – Admin Activity and Data Access. The admin audit logs entries for API calls that includes modifying any configuration of resources and other tasks that administrators might perform.

Viewing logs for admin logging requires the IAM roles of Logging/Logs Viewer or Project/Viewer. Data Access logs record API calls relating to any user-provided data. Viewing the Data Access logs requires the Logging/Private Logs Viewer or Project/Owner IAM roles.

Google’s Stackdriver Logging


Cloud IAM (Cloud Identity and Access Management) is a crucial part of any organization’s security strategy to make sure both identity and access are validated so that access to business-critical resources in the public cloud has the correct permissions applied. Among the many powerful features of cloud-based IAM are Identity and Access control, Permissions and roles, Policy-Based Access, single management interface, and Auditing capabilities. By using these and other security features of cloud-based IAM in conjunction with other cloud security measures such as API-based CASB, organizations, and GDPR compliance are able to drastically bolster the security of public cloud resources. Making sure the identity of users accessing cloud resources is validated and making sure those validated users have fine-grained permissions applied helps to ensure the best practice of “least privilege” access.

Check out SpinOne API CASB security expertise and keep your clod data protected!

This website stores cookies on your computer. These cookies are used to improve your website experience and provide more personalized services to you, both on this website and through other media. To find out more about the cookies we use, see our Privacy Policy. We won't track your information when you visit our site. But in order to comply with your preferences, we'll have to use just one tiny cookie so that you're not asked to make this choice again.Learn more about our use of cookies.