By default, users in your project can create persistent disks or copy images using any of the public images and any images that your project members can access through IAM roles. However, in some situations you might want to restrict your project members so that they can create boot disks only from images that contain approved software that meets your policy or security requirements.
Use the Trusted image feature to define an organization policy that allows your project members to create persistent disks only from images in specific projects.
To restrict the locations where your images can be used, read restricting use of your shared images, disks, and snapshots.
Before you begin
- If you want to use the command-line examples in this guide:
- If you want to use the API examples in this guide, set up API access.
- Read the Using constraints page.
- Read Understanding hierarchy evaluation to learn how organization policies propagate.
Trusted image policies do not restrict access to the following images:
Custom images in your local project.
Image files in Cloud Storage buckets.
Trusted image policies do not prevent users from creating image resources in their local projects.
Setting image access constraints
Enact an image access policy by setting a
constraint on your project, your organization, or your folder. You must have
permission to modify organization policies to set these constraints. For
has permission to set these constraints. For more information about managing
policies at the organization level, see
- Go to the Organization policies page.
- In the policies list, click Define trusted image projects.
- Click Edit to edit your existing trusted image constraints.
Set constraints to allow or deny one or more projects from which your project can obtain images. The allowed and denied list of publisher projects is a list of strings in the following format:
where [PROJECT_ID] is the project ID of the project that you want to mark as a trusted source for images.
If your organization or folder has existing constraints, those constraints might conflict with project-level constraints that you set.
Click Save to apply the constraint settings.
Get the existing policy settings for your project.
gcloud beta resource-manager org-policies describe \ compute.trustedImageProjects --effective \ --project [PROJECT_ID] > policy.yaml
[PROJECT_ID]is your project ID.
policy.yamlfile in a text editor and modify the
compute.trustedImageProjectsconstraint. Add the restrictions that you need and remove the restrictions that you no longer require. When you have finished editing the file, save your changes. For example, you might set the following constraint entry in your policy file:
constraint: constraints/compute.trustedImageProjects listPolicy: allowedValues: - projects/debian-cloud - projects/cos-cloud deniedValues: - projects/unwanted-images
Optionally, you might want to deny access to all images outside of the custom images in your project. For that situation, use the following example:
constraint: constraints/compute.trustedImageProjects listPolicy: allValues: DENY
policy.yamlfile to your project. If your organization or folder has existing constraints, those constraints might conflict with project-level constraints that you set.
gcloud beta resource-manager org-policies set-policy \ --project [PROJECT_ID] policy.yaml
[PROJECT_ID]is your project ID.
When you have finished configuring the constraints, test those constraints to ensure that they create the restrictions that you need.
- Learn more about the Organization policy service.
- See what Public images are available for you to use by default.
- Share your private image with other projects.
- Learn how to restrict use of your shared images, disks, and snapshots.
- Learn how to start an instance from an image.