k8s-infra-prow-oncall members should be empowered to manage and troubleshoot prow infrastructure

[spiffxp]

This is intended to be a punch list for ensuring test-infra-oncall has the access they're used to with k8s-prow and k8s-prow-builds (or identifying a subset of permissions/access that is more appropriate for k8s-infra). Beyond that, this list should ensure that group members have sufficient permissions to use our scripts/terraform to manage prow infrastructure.

Up until now I've mostly been managing prow infrastructure as an account that has organization.admin and roles/owner for the kubernetes.io organization. As able, I will switch to an alternate account that is solely within the oncall group.

It would also be helpful to get folks from @kubernetes/ci-signal in k8s-infra-prow-viewers@ to raise issues they have about being unable to see things they expect to.

Thanks to @ameukam and @cjwagner for pointing out some gaps to get me started:

• Remote states access for k8s-infra-oncall #1681 - access to gcs bucket storing remote terraform state for prow clusters
  (co-mingled with state for aaa cluster, should split out)
• TBD - unable to run ensure-e2e-projects.sh (should either get permission to link billing accounts, or ensure_project shouldn't require these privileges when the project already exists)
• TBD - unable to view custom org roles within GCP console
• Update k8s-infra-prow-build README to clarify access instructions. #1735 - instructions for how to access prow clusters out of date
• TBD - consider moving these projects to a folder within the organization, and setting bindings here instead of per-project

I'll update this with what the group has access to, but for now:

• roles/owner for cluster projects: k8s-infra-prow-build, k8s-infra-prow-build-trusted
• roles/owner for e2e projects: k8s-infra-e2e-*

/sig testing
/area prow
/area access
/priority important-soon

[spiffxp]

/assign @spiffxp

[ameukam]

/milestone v1.22

[ameukam]

/milestone v1.22

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale