OKD on GCP Shared VPC – Why does installer require write access to host project?

[subhanshu-shukla-ril]

Hi community,

I am trying to install OKD on GCP using a Shared VPC setup.

Service Project: Where OKD cluster resources (VMs, disks, etc.) will be deployed.

Host Project: Owns the shared VPC networks, subnets, and firewall rules.

During installation, I hit the following error:

ERROR failed to fetch Cluster: failed to generate asset "Cluster": failed to create cluster: failed during pre-provisioning: failed to add roles for shared VPC: failed to set IAM policy, unexpected error: googleapi: Error 403: Policy update access denied., forbidden
From OKD documentation, I see that the installer’s service account requires permissions in both the service project and the host project, including:

roles/compute.networkAdmin
roles/compute.securityAdmin
roles/compute.networkUser
compute.firewalls.delete
compute.networks.updatePolicy
projects//roles/dns.networks.bindPrivateDNSZone

My question is: Why does the OKD/OpenShift installer need to modify IAM policies and network resources in the host project?
In my case, I do not have write permissions to the host project, and the Shared VPC is centrally managed by another team.

I understand the installer might:
Update network policies or routes

But in large organizations, host projects are tightly controlled, and installer write access is not allowed or read access given.

Questions for the community:

Is there a documented way to pre-create these network resources so the installer doesn’t need write access to the host project?

Can the installer be run in a “no-host-modification” mode where these are skipped, and the host project admins can manually provision them?

Has anyone successfully installed OKD in GCP Shared VPC without granting projects.setIamPolicy or compute.networkAdmin in the host project?

Any guidance or best practices from those who have done Shared VPC installs in restricted environments would be appreciated.

Thanks,