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
: