The first article in this series discussed the basic building blocks of cloud security and Google Cloud Platform, and how they relate to workloads running on GCP. This article dives into resource management, and identity and access management (IAM), including industry best practices for GCP.
Proper management of GCP resources is essential. Just like web security for GCP, resource management must not be an afterthought. But what are resources, and why is it so vital to manage them correctly? A resource is anything you provision: a virtual machine (perhaps to run a cloud WAF), a database instance, storage bucket, or anything else your organization creates in GCP.
To be able to create resources in GCP, it’s necessary to create a project. Resources always exist inside projects and cannot be moved to another project after being created, so it is imperative to consider a proper project structure.
While it is possible to have all resources inside a single project, this is a bad idea for several reasons. You’ll want employees (and perhaps externals) to be able to create resources and modify existing ones. But you’ll also want to restrict them to a set of resources they are allowed to manage. The best approach to access control is to grant employees access to only the projects they need to access to get their work done. Doing so increases GCP security in case of unauthorized access to employee accounts, and, at the same time, decreases the blast radius of any changes.
Also, when executing API operations towards resources in GCP, it is necessary to specify the project in which the API calls are taking effect. A good project structure will ensure that applications and scripts can only affect their relevant resources; even if an API caller had sufficient permissions, it can’t affect resources in other projects.
The actual project structure will depend on the organization’s complexity and data security requirements.
In addition to projects, there are two other hierarchical resource types: organizations and folders. If your company is already using G Suite or Cloud Identity, then you already have an Organization tied to your company domain name. For users that signed up to Google Cloud using a regular Gmail account, there is no Organization resource automatically created.
While the Organization resource is not required, the owner of a project without an Organization resource in GCP is the employee who created it. Upon employment termination, the ex-employee would have to transfer the project to another GCP user. When using the Organization resource, the company keeps ownership of all of its resources, regardless of which employee created them. For businesses, regardless of size, it is always recommended to use an Organization resource, either by using G Suite, or through Cloud Identity, which can synchronize with an existing Active Directory or LDAP directory.
Folders are the last of the management resources available. They exist between organizations and projects. Folders can be nested, just like folders on your computer. A significant advantage of using folders is that IAM policies are inherited, and folders can have IAM policies the same way that Organization resources and projects can. By using policy inheritance correctly, it can become much easier to manage and secure access to resources.
One final advantage of hierarchies is cost management. The billing portal in GCP shows a cost breakdown per folder and project, allowing you to keep different organizational units and team expenses in check.
One last aspect that’s worth considering in terms of resource management is organization policies. As the name implies, it is possible to enforce constraints through these policies in projects and folders as well, not just in Organization resources, as the name seems to imply. And just like IAM policies, they are also inherited.
Constraints do not define who can access which resources (IAM does); instead, they define which resources are allowed. These policies can help ensure compliance. They can, for example, restrict GCP services that are not permitted by the organization and limit the number of geographical regions to an allowed list.
Create multiple small projects, especially in larger organizations, if at all possible. With small projects, in the case of a buggy batch change to resources, the maximum it can affect is a single project. At the very minimum, separate your different environments (e.g., test, staging, production) into separate projects so that changes to resources in a test environment can never affect production resources, even in the case of a faulty script. This separation can also restrict employees from accessing production environments and their data when they have no reason to do so, while still allowing them to use the development environments they need for everyday work.
Use new projects for experiments. When you finish an experiment, deleting a project deletes all of its resources automatically. By enforcing this practice throughout your organization, employees can quickly try out new ideas and GCP products without the risk of making changes to unrelated resources. There is also no need to worry about forgetting to delete potentially expensive resources when the experimentation phase is over.
Identity and Access Management (IAM) is often daunting to someone who hasn’t encountered it before. However, there are just a few key concepts to understand. The purpose of IAM is to control access to cloud resources.
Members, Roles, and Policies
Members define who has access. A member can be anyone who can log in through a Google Account, which can be either a personal account or a G Suite or Google Cloud Identity user. Because managing individual accounts separately for IAM can be a repetitive task, it’s also possible to assign an entire Google Group or domain from G Suite or Google Cloud Identity. A member may also be software that needs to access GCP resources, either running inside or outside of GCP. Service accounts (described below), exist for precisely this purpose.
Roles define a collection of permissions that are allowed on resources. Permissions themselves are very granular. For example, listing Google Cloud Storage buckets, listing the objects inside buckets, and reading the objects themselves are all separate permissions. But by combining all three permissions into a single role, it can now be reused for anyone who needs this kind of read access. Hundreds of pre-made roles exist for all GCP services. It is also possible to create custom roles from any set of permissions.
Lastly, policies are the glue between members, roles, and resources. A policy binds a set of members to a set of roles and is attached to a resource. As previously mentioned in resource management, IAM policies are inherited. A policy can be attached to a single resource or to a project, folder, or organization, in which case it would apply to all resources under it.
Service accounts are accounts generated for applications and virtual machines and do not belong to users. Service accounts do not have passwords like user accounts, and they are not able to log in to the Google Cloud Console.
To programmatically authenticate using a service account, a service account key pair is needed. While it is possible to supply Google with just a public key to use, it’s usually a better idea to let GCP handle the service account keys so that you don’t need to worry about key rotation best practices. Cloud IAM can generate Google-managed keys, or you can use the Cloud Key Management Service (KMS).
Always follow the principle of least privilege. Attach policies to the lowest level resource required. For employees, this may be a folder or project, but for applications using service accounts that only need a handful of resources, attach policies directly to the resources if possible.
Take advantage of resource management. A well-thought-out hierarchy with folders and projects makes it easier to apply IAM policies at the correct level, making the whole organization more secure. At the same time, remember that policies are inherited. Fortunately, when seeing the policies for any resource, the Google Cloud Console displays what the attached policies versus inherited ones are.