Get more control over your Compute Engine resources with new Cloud IAM features

Today, we are introducing two new Cloud IAM features, resource-level IAM and IAM conditions, to help you better manage security and access control in Google Compute Engine. Resource-level IAM allows you to set IAM policies on individual resources like VM instances and disks. IAM conditions allows you to grant access based on meeting pre-defined conditions, such as resource name prefix, raw request attributes (IP, device, etc.), or a specific time frame.  

Managing resource-level access in Google Compute Engine

At  Google Cloud Next 2018 we introduced Compute Engine resource-level IAM, which allows you to apply IAM policies on VMs, disks, images, and other Compute Engine resources, and provides you with flexibility and fine-grained control of your environment. The following diagram illustrates  the hierarchical resource model within GCP.

You can apply IAM policies at the organization, folder or project level. These policies are inherited by the level(s) below, so that you can grant permissions effectively and efficiently. For example, as in the chart above, if you want to grant the instance admin role to Elizabeth, who works in Department X, you can apply IAM policy at the folder (Department X) level, Now Elizabeth can manipulate instances on all the projects within the Department X folder. In a second example, you can grant powerful permissions for a group of developers who are working together on the Dev/test project, but restrict their access to adjacent Production project.

You may also want to set IAM policies that are even more granular. For example, you may want a group of testers to test a beta image in Project A, but restrict their access to other sensitive images and resources within the same project. If you could only set permissions at the project level or above, the test group would get access to either all or none of the images in the project. Before, in order to limit access to those sensitive images, you would have had to create a separate project just with that beta image, and grant the compute.imageUser role for the tester group on that separate project—a suboptimal workaround.

With Compute Engine resource-level IAM, in the example above, you can easily grant the compute.imageUser role to your tester group on a particular beta testing images without oversharing or workarounds. Let’s look at how you set these permissions:

gcloud beta images set-iam-policy betaTestImage1 betaImagePolicy.json

There are many more common use cases that you can enable with the new resource-level IAM policy support. For example, you can give a colleague and collaborator access to just one VM in a project for troubleshooting, or you can share a disk image with all authorized users within the organization so everyone has access to consistent image versions.

The Compute Engine resource-level IAM features are available in beta through the API, CLI, and the Developer Console. Check out the documentation to learn more.

Managing access with IAM conditions

In addition to setting resource-level IAM policies, you may need to express and enforce context-aware access via IAM policies. For example, you may want members of your on-call support team to perform actions as instance administrators, but limit their access to only on-call hours to help prevent accidental actions, and comply with the principle of least privilege.

IAM conditions allows you to restrict the scope of access rights to a granular set of conditions. You can specify a policy in the form of: Assign X role to Y when it meets condition Z. As introduced at Google Cloud Next ‘18, Compute Engine currently offers you three conditional attributes: name prefix attributes, access-level attributes, and date/time attributes upon which to base policies, and give you more power to manage access control. Here’s a look at each of these conditional attributes.

1. Name prefix attribute

This attribute allows you to express an IAM policy only if the resource name matches a resource name prefix. A common use case involves creating a sandboxed developer playground, where developers build prototypes in the same project to reduce administrative overhead and optimize network performance. You can create this sandbox by inserting conditions in your project’s IAM policy that give the compute.instanceAdmin.v1 role to each developer, but limit each developer's access to only those resources that are named after that developer. Here is an example policy for your lead developer, dev1, to have the instanceAdmin role, but only when manipulating VMs and disks starting with his/her name dev1:

^{*Please note: The resource type format, like compute.instances, is subject to change in future releases of Cloud IAM Conditions.}

By using name prefix matching, you can reduce the scope of access granted, so your developers can explore and develop however they want without disturbing others' resources.

2. Access-level attributes

You can use access-level attributes to help ensure that requests meet specific access levels to be authorized based on the raw attributes of that request, such as IP address or device status.

With access-level attributes, you can express conditions like: “Grant requests from a [Service Account] ONLY if the source VM instance is running the latest company-issued operating system image” or “Remote requests to manipulate instance states are granted ONLY if they originate from the corporate VPN.”

Please note the access-level attributes can only be used with Compute Engine Alpha APIs currently.

3. Date/time attribute

Date/time attributes let you add start and end dates, as well as times for your IAM policy. For example, you can say: “Grant Jane the Stackdriver log viewer role only while she is on call,” or “John is the compute admin for this production project only during an emergency fix.”

Support for IAM conditions provides you with flexible and fine-grained ways to help secure your organization’s cloud computing environment. There’s a private beta available for IAM conditions; if you’re interested, please sign up here. We encourage you to try the new conditional IAM features.