IssueTracker

Environment: Our GCP presence spans several regions with 100s of service projects in each region communicating with onprem data centers using dedicated interconnects, attached to host projects in shared VPCs. OnPrem DNS resolution for GCP resources is via CloudDNS configured on the host projects.

Scenario: -- Before provisioning a GKE cluster in a service project with the network in the host project, predefined roles need to be granted to the service project's serviceAccount(s)/GKE serviceAgent(s) (https://cloud.google.com/kubernetes-engine/docs/how-to/iam#predefined); one of them being roles/container.hostServiceAgentUser. The role has DNS permissions to manage RPZs (response policy zones). - [1]

- dns.networks.bindDNSResponsePolicy
- dns.networks.bindPrivateDNSPolicy
- dns.networks.bindPrivateDNSZone
- dns.responsePolicies.create
- dns.responsePolicies.delete
- dns.responsePolicies.update
- dns.responsePolicyRules.create
- dns.responsePolicyRules.delete
- dns.responsePolicyRules.list

-- Upon completion of [1], when provisioning the GKE cluster with Cloud DNS as the kubedns provider, default RPZs are created in the host project (https://cloud.google.com/kubernetes-engine/docs/how-to/cloud-dns#created_resources), with RPZ modification permissions available to the service project's serviceAccount(s)/GKE serviceAgent(s).

Problem: Considering RPZs mgmt access is provided at the host project level, this allows the service project's serviceAccount(s)/GKE serviceAgent(s) to add/mod/del RPZs/rules. While the scope is currently cluster-centric, an orchestrated impersonation can ensure RPZ/rule changes are done to any RPZ. Creating unnecessary RPZs/rules also has the potential to create query loops, if left unchecked.

What you expected to happen: The service project's serviceAccount(s)/GKE serviceAgent(s) should not have the ability to modify any/all RPZs under a host project, other than the RPZs/rules created by a GKE cluster.

Steps to reproduce:

1. Create a host project and configure Cloud DNS.
2. Create subnets for 2 GKE clusters.
3. Create a service project and attach it to the host project (perform role binding as a part of this).
4. Provision a GKE cluster in a service project with Cloud DNS as the kubedns provider (term as GKE1).
5. Create another service project and attach it to the host project (perform role binding as a part of this).
6. Provision a GKE cluster in the second service project with Cloud DNS as the kubedns provider (term as GKE2).
7. Via a pod in GKE1, run gcloud commands to add/modify/del GKE2's RPZ/RPZ rules. // perform the same with serviceAccount impersonating the serviceAgent].
8. Via a pod in GKE2, run gcloud commands to add/modify/del GKE1's RPZ/RPZ rules. // perform the same with serviceAccount impersonating the serviceAgent].

Other information (workarounds you have tried, documentation consulted, etc): A custom role with all permissions except DNS RPZ mgmt will help as an interim solution, but is not scalable as the predefined role (GCP recommendation) is preferable and could provide a problem if changes are done that we are unaware of. In addition, Google Support might not assist if custom roles are utilized.