Cloud IAM Google Cloud

Once you have identified who a user is (authenticated them) using Cloud Identity, the next step is to define what they can do on Google Cloud (authorize them) so they can access the resources they are permitted to use. Access control for Google Cloud resources is managed by Cloud IAM policies for humans and by service accounts for non-humans (applications and services). Let’s take a closer look at Cloud IAM and service accounts.

What is Cloud IAM? 

Cloud IAM helps define who can do what and where on Google Cloud. It provides fine-grained access control and visibility for centrally managing cloud resources.

IAM policies manage access control for Google Cloud resources. They are collections of IAM bindings, each one “binding” together a principal, a role, and the resource to which the policy is attached. What is commonly thought of as an authorization group is an IAM binding on Google Cloud: the union of an identity group and a role, bound to a specific resource or hierarchy node. Binding principals can be:

• an org domain, granting the role to all org members

• a Workspace/Cloud Identity user

• a Workspace/Cloud Identity group

• a service account (described later)

IAM roles group a set of related fine-grained permissions. There are three types of roles: basic, predefined, and custom.

• Basic roles are easy to understand and apply but include broad permissions and scope. For example, owner includes editor permissions. 

• Pre-defined roles map well to the model of "which services users are allowed to use". They provide a narrower per-service permissions scope; they require a bit more effort but are safer than primitive basic roles. 

• Custom roles enable you to define custom defined permissions scopes at the org, project, or service level. While this is the most secure option, it requires substantial maintenance effort to manage dependencies and updates.

IAM Conditions: IAM policies can also be bound to conditions based on resource and request attributes. This allows for the following use cases:

• Time-limited access; for example: only allow access during working hours

• Access to a subset of resources; for example: grant access only to VMs prefixed with ‘webapp-frontend-’

• Network address space; for example: only allow access from the corporate network

IAM Conditions also enable granular control on which roles can be assigned or revoked. In practice this means centrally controlling which services (via IAM roles) users can use in their projects, but still giving autonomy to the teams to manage permissions directly on their projects (as long as those permissions are for the approved services).

IAM Conditions also support secure tags. Tags are access-controlled key/value resources defined at the organization level, which can be associated with hierarchy nodes (organization, folders, projects). Once tags are associated with a node, they can be set in IAM Conditions to scope role assignment to relevant nodes.

Cloud IAM best practices

When using Cloud IAM, you should map IAM policies to functional identities using groups.

• Use individual identity groups as recipients of functional sets of IAM roles, with clear permission scopes and boundaries (org, folder, project, resource).

• Use groups to mirror on-premises workflows (networking, DevOps, etc.) or map to new cloud-specific workflows.

• Sync groups from your source of truth so that its join/leave process is shared.

• Define and enforce a naming convention for group names.

• Minimize the points where IAM policies are applied by using folders.

• Optionally nest groups when specific cross-team functions are shared across different teams.

• Optionally enforce domain membership via the iam.allowedPolicyMemberDomains organizational policy.

What are service accounts? 

Service accounts are a special type of account used by applications and services. Non-human access to Google Cloud APIs and services is usually done via service accounts. They are created and managed within projects like most other resources. Because they are typically used by services, they don’t have an associated password and cannot log in via browser or cookies.

Authentication is done via private/public key pairs (either Google or customer-managed) or identity federation. 

Service account types

Some types of service accounts are built into Google Cloud services.

• User-managed: Created by you and managed like all other resources. No IAM role is assigned by default. Can be used via key, VM association, or impersonation.

• Service default: Created at API activation. Used by default when no customer service account is selected. For example, Compute Engine has a default service account for VMs. They have a fixed naming convention, and an editor IAM role is assigned at creation.

• Google-managed (robots or service agents): Created at API activation. Used by Google Cloud services to perform actions on customer resources so they are created with specific IAM roles assigned. The Compute Engine robot account is an example of a Google-managed service account. 

Service account credentials

There are different ways of managing and accessing service account credentials.

Google-managed keys: Both the public and private portions of the key pair are stored in Google Cloud, auto-rotated, and secured. They can be used by associating a service account with a VM or other compute service, or by impersonation from a different identity.

User-managed keys: You (as the customer) own both public and private portions and are responsible for rotating and securing them. Key pairs can be created from Google Cloud, or created externally and the public portion is uploaded to Google Cloud. 

It is a best practice to use short-lived credentials when you need to grant limited access to resources for trusted identities.

Service account best practices

• From a workflow perspective, the default service account is generous with permissions (i.e. Project Editor). It’s a good idea to create app-specific accounts, and only grant needed permissions.

• Service accounts can be used for selective applications to apply firewalls. For example: Open port 443 (HTTPS) for VMs for service account ‘webapp-fe’

• Create service accounts on dedicated projects for centralized management.

• A security risk related to user-managed keys is keys being compromised, either maliciously or by mistakenly publishing keys by embedding them in code. To help mitigate this risk, rotate keys frequently.

• VPC Service Controls help limit who can access Google Cloud services (which is what service accounts are ultimately for). For example: Access only permitted from on-prem IP ranges (when interconnecting). Implementing these access limitations can help minimize your attack surface. 

• Combine service accounts with a proactive approach by using Forseti to alert on old keys that need to be rotated.

That was a quick overview of authorization in Google Cloud using Cloud IAM and service accounts. For a deep dive check out the whitepaper on Google Cloud security foundations.  For more #GCPSketchnote, follow the GitHub repo. For similar cloud content follow me on Twitter @pvergadia and keep an eye out on thecloudgirl.dev