Cloud Identity and Access Management

In a business, following proper access management best practices can mitigate much of the risk. After all, the cost of a breach is usually significantly more than the cost and time it will take you to design a system properly. It is your responsibility, dear Cloud Architect, to be “awake” on the importance of security in every aspect of your system design. We discussed the shared responsibility model earlier, and that will come up throughout the book. Even though Google Cloud may be the most secure cloud platform that exists, it is still up to cloud architects to responsibly bake in security best practices across their organizations. Consider the importance of your access model, and don’t take this one lightly.

Google Cloud and other cloud providers have made administration so much easier by baking in security via infrastructure as code (IaC). You simply manage the templates and build some monitoring and detection alerts to ensure that mistakes don’t accidentally happen. Maybe you’ll even build a corrective control to mitigate anomalous grants when they happen.

Cloud IAM Overview
Cloud Identity and Access Management (Cloud IAM) is an enterprise-grade access control service that enables administrators to authorize who can take actions on certain resources and what conditions must exist before they can take action. The goal of a cloud administrator is to have full visibility and fine-grained, centrally managed, access control capabilities that span all cloud resources. Quite often, enterprises have massively complex organizational structures with hundreds of working groups, many projects, and very intricate access control requirements. Cloud IAM gives you the ability to manage all the access policies across your organization with its built-in auditing capabilities. You can create and manage your IAM policies through the Cloud Console, the API, or the command line.

Remember the difference between Cloud Identity and Cloud IAM. Cloud Identity is the source of truth for handling authentication by creating or synchronizing user accounts, setting up single sign-on (SSO), and leveraging 2-Step Verification (2SV), and it is managed from the Admin console at admin.google.com. Cloud IAM handles access management, including creating and managing all the roles for your applications and environments, following the role-based access control (RBAC) model.

The purpose of having a strong access management model is to ensure that you are granting the right roles to the right users and minimizing their privileges so that they’re using only what they need. As a cloud administrator, you’ll probably be required to provide audit reports for internal or external compliance reasons and security monitoring. Remember the AAA security model: authentication, authorization (or access), and accounting (or auditing)? You need to manage AAA efficiently—the last thing you want to do is block your users from doing the work that they should be authorized to perform, especially in the cloud, where business and innovation are supposed to be exponentially accelerated. Your users don’t care about the security model. They don’t care about how many privileges they should have. They just want to be able to do their jobs without running into insufficient privileges errors.
What about your security operations team? Have you considered their feelings when you built your IAM architecture? After all, they have needs too! They hold you accountable for aligning to the information security policies of your organization. One of the biggest challenges I’ve seen is a lack of engagement between the folks who create the policies, the folks enforcing them, and the folks who are leading the cloud migrations and engineering work. When your work is in security operations, you’re often down in the trenches building the capabilities to detect malicious activity or you’re responding to potential incidents. Aside from having a say on the policies, it can be quite difficult to be a part of the cloud engineering or migration efforts.
When you’re designing your IAM architecture, take a close look at your enterprise security policies around access management as you’re working through the many considerations of a well-architected access model. For new cloud organizations, it’s more than likely that they’ll need to revisit their security policies around IAM and rework them as they understand how the model evolves in the cloud. For information security teams, it’s important to dictate what users and how users can access resources in the cloud. How and when do they need to rotate their keys? Also, you need to have an inventory of all the resources that can surface the data to their security monitoring tool to ensure that everyone is compliant with their requirements. If your system gets breached, you are liable for all your customers’ data. You have a duty to protect them, because mom won’t be there to protect you!

Members, Roles, and Policies
The model for access management in Cloud IAM has three main parts: members, roles, and IAM policies.
- A member can be a Google account (human users), a service account (programmatic account for applications and virtual machines), a Google group, or a Google Workspace or Cloud Identity domain that can access a resource. The identifier for a member is the e-mail address associated with the type of account or the domain name associated with the Google Workspace or Cloud Identity domain. It’s common to hear the term “users” used as a blanket statement to cover members. Just remember that Google Cloud refers to all of these as members, and each is treated distinctively according to the member’s appropriate title.
- An IAM role is a collection of permissions that determines what operations are allowed on a resource. When you grant a member a role, all of the permissions contained within that role are granted to that member.
- An IAM Policy is a configuration that binds together one or more members and roles for the purpose of enforcing only approved access patterns through a collection of statements. It basically ties the “who” and the “what” together—who needs to access a resource, and what do they need to do? After you create an IAM policy, you attach it to the resource—or you can attach them to those logical resource containers (project, folder, and organization).

When you’re defining the duties that any member will perform, an easy way to determine whether you’ve given your member too many roles is to imagine what would happen if the member were compromised. What is the extent of the damage that could happen? If you haven’t mitigated the risk to an acceptable position, you may have to separate duties across various members. This is actually a great tip for everything you architect in the Google Cloud Platform (GCP).

Google Accounts
Google accounts are human users (members) authenticated from your identity provider that can be entitled to perform certain roles or actions in GCP. As discussed in earlier chapters, your users are typically provisioned in Cloud Identity, where users are defined along with the criteria for authenticating into GCP. User accounts should be individually provisioned and not managed by multiple humans, because you need to ensure accountability for every action that is performed in GCP. Remember the third A of the AAA security model—accounting (auditing).
Google accounts are typically developers, administrators, and other users who interact with Google Cloud. Any e-mail that is associated with a Google account, including Gmail addresses, can be an identity. You sign up for a Google account at https://myaccount.google.com.
This last point brings up an important topic: conflict accounts. These occur when a user creates a personal Google account with the same domain name as your organization. When your organization signs up for a managed Google account and attempts to add those users, a conflict will occur: users cannot use the same e-mail address for their personal and work accounts. This happens more often than you might think. Think about someone who signs up for a YouTube account with their work e-mail address. So what happens when you try to create an account for this user to your organization when there is already an existing account? The user with the existing account will be asked to rename their account. Once that account is renamed, it will continue to be managed outside of your organization.

Groups
Users and service accounts can be added to groups, which are logical containers or groupings of one or more accounts that define clear roles and ensure ease of manageability of your cloud access model. Groups are also provisioned in Cloud Identity. Imagine, for example, that your small organization is hiring DevOps engineers to work on the developer environment for its core application. It’s much more difficult to track each and every developer’s name and grant each individual access to that environment than it is to track developers by their role in the company and allocate them appropriately. That role probably will be applied to other applications in the group in which that team will be working. By using groups, you don’t have to grant new permissions for each of your 300 developers; you can just add their role to the group policy.

Service Accounts
While users, or members, are the individual human accounts in Google Cloud, you’ll often need to be able to perform certain actions without human involvement, but you’ll still need to be able to trace where the action was performed. In this case, service accounts can be used in GCP. These programmatic accounts can be granted roles and privileges to perform certain actions on behalf of an application. Think about a bank running a batch job to process checks and sending the ledger of each transaction to a regulating agency every night. You can’t expect your users to perform this action every single night. You can automate this instead by creating a service account with the appropriate permissions to access the database of posted transactions that can perform the batch job and send the transaction ledger to the agency.
When you run code on GCP, that code is run as the service account that you specify. There’s no limit to how many service accounts you can leverage, and you should not be afraid to use as many service accounts as you need, as long as you have the appropriate oversight in place to manage them all. The principles of separation of duties and least privilege apply to service accounts as well as all members.
NOTE Service accounts can be thought of as both a member and a resource. As a member, when you grant roles to a service account, you can allow it to access a resource. As a resource, when you grant roles to other members, you can allow those members to access or manage the service account.
Service accounts are not generated from your identity provider, whether it is Cloud Identity, Okta, or another provider. Service accounts are created within projects, so the management of these accounts falls directly to GCP. Authentication uses an X.509 private key to obtain OAuth2 tokens. You can also generate an external RSA private key if you need to authenticate to Google Cloud as the service account. Protecting this external RSA private key is important, because if this key is compromised, an attacker will have full access to all the resources that the service account is authorized to access.
Service accounts are an incredibly important aspect of the cloud. Any application that needs to access Google Cloud APIs will be leveraging service accounts. Imagine, for example, that your application needs to upload data to a storage bucket. How do you expect that application to upload the data? The application needs to be able to authenticate, to be authorized to perform the action in the target resource, and to programmatically perform a desired action. Service accounts can also be leveraged to run workloads in on-premises workstations or data centers that call Google Cloud APIs. Your application will assume the identity of the service account when it performs the action.

Managing Service Account Keys
In GCP, there are two types of service account keys:

- GCP-managed keys: These keys are used by Google Cloud APIs such as Google App Engine, Google Cloud Storage, and Google Compute Engine. You can’t download these keys, and they’re automatically rotated approximately once a week and are used for signing for a maximum of two weeks. (I won’t get into Kubernetes here because it takes a much deeper dive with respect to key management than what this exam covers. So you can research that on your own.)

- User-managed keys: These keys are created, downloadable, and managed by your users. Once these keys are deleted from a service account, you can no longer use them to authenticate. If you’re using user-managed keys, you need to think about some of the top key management requirements such as key rotation, storage, distribution, revocation, recovery, and access.

Keys that are stored in code by developers seem to be one of the hottest security weaknesses in the last few years. Every few months, we hear about a developer who stored a key in code and published the code to GitHub, where hackers and bots scour every new code change for explicitly stored keys. It’s important that developers be taught to use best practices when managing keys, especially to ensure that they don’t paste keys in their code.

You can create a process to use the IAM service account API to rotate your service account keys automatically. Most enterprises use some type of vault system to manage their keys. HashiCorp Vault is a top third-party solution in this space that has a close integration with GCP. With Vault, you can use its secrets engine to generate service account keys and OAuth tokens dynamically based on IAM policies. There is typically a secrets engine and a storage backend that is built to handle most of your key management tasks.
You can also create short-lived service account credentials, most commonly OAuth 2.0 tokens or OpenID Connect (OIDC) tokens if you need short-term elevated privileges. Imagine, for example, that you’re fighting a production issue and need to troubleshoot it by impersonating a service account to determine the root cause.

Default vs. Custom Service Accounts
In GCP, there are two types of service accounts: default service accounts and custom service accounts. Default service accounts are automatically generated for Compute Engine instances upon project creation. Compute Engine needs service accounts to access other GCP resources. Upon project creation, these service accounts are entitled to a privileged editor role by default. Don’t use the default Compute Engine service account because it’s overly permissive, and you can do a better job of separating duties and minimizing privileges by creating your own application-specific service accounts. Instances depend on service accounts to access other resources. So be very certain that you’ve modified these dependencies before you delete a service account, because you might accidently break some of your VMs. Custom service accounts are user-created service accounts that can be used for various applications, including applications running on-premises or from another cloud environment.

IAM Roles
In the RBAC model, users are not granted permissions directly to their user accounts, based on the discretion of the application owner, or based on security labels. Users are granted access based on a role in the organization that they perform. As mentioned earlier, a role is a collection of permissions. Roles are bound together with members inside an IAM policy, which is attached to a resource or an enforcement point. You cannot grant users permissions directly in GCP as you can in traditional, on-premises computing environments. When you grant users a role, they get access to all the permissions granted for that role. There are three types of roles in GCP: primitive roles, predefined roles, and custom roles. I

Primitive Roles
Primitive roles are historically available in the Cloud Console. These include roles such as Owner, Editor, and Viewer. These roles are no longer recommended to use today, and you should avoid them where possible because they are overly permissive.

Predefined Roles
Predefined roles offer finer-grained access control than primitive roles and are preconfigured by GCP to accomplish certain common functions. An example of a predefined role is a Pub/Sub Publisher, which in the console is shown as the roles/pubsub.publisher role. This role grants access to publishing messages with a Pub/Sub topic. Imagine, for example, that you have an Editor primitive role in a GCP project, which basically grants permissions to do any sort of editing across all of the resources within your project. It is recommended that you use predefined roles where you can.

Custom Roles
You can use a custom role to create a set of permissions that are tailored to the needs of your organization when the predefined roles do not meet your criteria. Given the careful development and criteria of predefined roles, custom roles aren’t really used too often in GCP. There is usually a predefined role available to perform any desired action that meets the principle of least privileges and separated duties. Use these as needed.
IAM Policies: As discussed earlier, an IAM policy is a configuration that binds together one or more members and roles for the purpose of enforcing only approved access patterns through a collection of statements. These policies are represented by a Cloud IAM Policy object, which consists of a list of bindings. A binding binds a list of members to a role.

An example of IAM Policy binding:
- A role is specified as role/service.roleName. Here’s an example of an object creator role in Cloud Storage: role/storage.objectCreator
- Members are identified with a prefix:
- Google Accounts = user:
- Service account = serviceAccount:
- Google Group = group:
- G Suite or Cloud Identity domain = domain:

IAM Conditions
The next evolution of a RBAC is the ability to augment your RBAC model with conditions in which a user can access a resource, such as what time of day a user can access a resource, which IP ranges they’re permitted to originate from, and how long they’re permitted to access a system. This is where IAM Conditions comes into play. IAM Conditions is an attribute-based access control model that lets you define the conditions in which a user is able to be authorized to access a resource. Today there are a few conditions that you can implement, but GCP continues to evolve and grow this feature with new request attributes. Conditions are added to your role bindings of your Cloud IAM policy, and you use the Common Expression Language (CEL) to specify the expression in the Cloud IAM Condition.

You most likely won’t see anything about IAM Conditions on the exam, because it’s a recent generally available (GA) feature. It’s a critical feature to use, though, especially for your highly sensitive crown jewel projects.

BeyondCorp
BeyondCorp is certainly an access model that the most elite organizations implement and companies are striving to achieve.
BeyondCorp is Google’s internal implementation of the zero trust security model that builds on best practices regarding how employees are authenticated and authorized internally. It is based on years of zero trust research and technologies and is intended to enable every employee to work from an untrusted network without the use of a VPN. Today, it is used effectively by Google users around the world.
It’s almost impossible to assume that every user will be working from a secure location, and the use of a VPN can be a bottleneck in itself. In the BeyondCorp access model, Google has shifted access controls from the network perimeter to the users and devices. The high-level components of BeyondCorp include an SSO implementation, an access proxy, an access control engine, a user inventory, a device inventory, a security policy, and a trust repository.
Having never used a VPN at Google myself, I can say that I do not miss VPNs whatsoever. Being able to access any resources with biometrics from wherever in the world I am working has been a blessing in terms of productivity. I strongly encourage the strongest innovators to do a deep dive into the BeyondCorp zero trust model to see if it’s something that is worth implementing at your organization. Google has a list of major partners, and one in particular, Dito, champions its ability in implementing the BeyondCorp model at the most complex of enterprises.

Accounting and Technical Compliance
The third A in the AAA security model is…? You guessed it: accounting (or auditing). I’ve said it so many times by now that even I’m sick of hearing it! I’m going to use auditing from this point on in the book. Another part of having a strong identity and access model is having the necessary telemetry data to ensure that you are monitoring for security and technical compliance. Who did what, where, and when? The Cloud Audit Logs security tool helps you get all of this data. Cloud Audit Logs are, well, exactly what they sound like: audit logs that provide the necessary authentication and access information for each Google Cloud project, folder, and organization.

There are three types of Cloud Audit Logs:
- Admin Activity audit logs: These contain log entries for API calls and other administrative actions that can modify configurations or metadata of resources. Log entries are generated, for example, when a user makes a modification to an IAM policy.
- Data Access audit logs: These contain API calls that read the configuration or metadata of resources and user-driven API calls against user-provided resource data. The logs are disabled by default because they are large, and large means expensive. It’s highly recommended, however, that you enable these logs in your most critical environments.
- System Event audit logs: These contain administrative actions that modify the configuration of resources. They’re generated by systems, not by user actions. A. a cloud administrator or security professional, you probably want to ensure that your configurations are not modified. Here’s another big vulnerability of the day: customer-made misconfigurations are the leading causes of security breaches that happen in the cloud. To prevent this, you probably need to have a third-party vendor solution that helps you identify misconfiguration, such as Prisma Cloud from Palo Alto Networks or open-source Forseti Security. Both solutions offer a means to scan against misconfigurations in the cloud. In Forseti, you can build custom scanner rules or utilize ones that are on public GitHub pages. These scanners can, for example, ensure that there are no IAM policies on “All Users,” ensure that service account keys are being rotated, or ensure that no Google accounts have access to production systems.

Additional References
If you’d like more information about the topics discussed in this chapter, check out these sources:
- Cloud IAM Overview https://cloud.google.com/iam/docs/overview
- BeyondCorp https://cloud.google.com/beyondcorp
- Audit Logging https://cloud.google.com/iam/docs/audit-logging