We’re conducting quarterly disaster recovery tests and hitting a blocker when trying to restore Compute Engine instances from custom images stored in a separate backup project. The DR test involves spinning up instances in our DR project using images from our backup project, but we’re getting permission errors.
The error message:
ERROR: Permission denied on resource 'projects/backup-project/global/images/prod-web-server-20241115'
The user does not have permission to access image
Our setup: Production instances run in project-prod, we create custom images nightly and store them in project-backup for isolation, and DR tests spin up instances in project-dr. The service account used for DR automation has compute.instanceAdmin role in project-dr, but apparently that’s not enough to access images from project-backup.
This is blocking our DR validation - we need to prove we can recover within our RTO, but we can’t even start instances from the backup images. What IAM configuration do we need for cross-project image access in disaster recovery scenarios?
Thanks, that makes sense. I granted compute.imageUser to the DR service account in the backup project, but now I’m getting a different error about not being able to create instances with images from another project. Do I need additional permissions beyond imageUser? Also, is there a way to automate this permission setup so that new images created by our nightly backup process automatically have the right permissions for DR?
You might also need compute.instances.create permission in your DR project, which should come from your instanceAdmin role. But there’s another gotcha - if your images reference resources like custom networks or subnets, your service account needs permissions on those as well. Cross-project DR can get complex quickly with all the IAM dependencies. Consider using organization-level policies to simplify permission management across projects.
The issue is that IAM permissions on images are separate from compute instance permissions. Your DR service account needs explicit permissions on the images themselves, not just the ability to create instances. You’ll need to grant roles/compute.imageUser on the backup project or on individual images to your DR service account.
For automation, you should set IAM bindings on images at creation time using the --image-project flag and gcloud commands. We use a Cloud Build pipeline that creates images and immediately sets the appropriate IAM policies so they’re ready for DR scenarios. This prevents the permission issues you’re seeing. You can also use image families to simplify referencing the latest backup image without hardcoding specific image names in your DR scripts.
We had the exact same problem during our first DR test. The solution involves setting up proper IAM bindings in the backup project. The service account that creates instances in the DR project needs the compute.imageUser role in the backup project where the images are stored. Also make sure your images aren’t set to private visibility - they need to be at least shared with specific projects or service accounts.