Develop better ACLs for prow build clusters and e2e projects

[spiffxp]

At present, I basically copied what was done for the aaa cluster and the kubernetes-public project, and applied that to:

• k8s-infra-prow-build/prow-build
• k8s-infra-prow-build-trusted/prow-build-trusted

There are some problems with this setup:

• I'm listed as the only owner (org owners incidentally have owner privileges, I think)
• Nobody else has the project editor role
• The existing set of people who have access to k8s-prow-builds/prow don't have access to these clusters (IIRC they basically have the project owner role for their clusters)

I'd like to get us to the point where we have something better, possibly:

• the ability for a larger group of people to be able to view things (logging, monitoring) for both prow build clusters
• the ability for a smaller trusted group of people to be able to write to the prow-build cluster
• the ability for a (even smaller? different?) trusted group of people to read secrets and write to the prow-build-trusted cluster
• the ability for people to see what's happening in a given e2e cluster (maybe v0 of this is predefining a role that can be manually/selectively granted)

ref: #752, followup to: #830

[spiffxp]

Spoke with test-infra-oncall team, if I can't add the group they use, I have permission to create a new @kubernetes.io group for them here

[spiffxp]

Will work on this over next two weeks

[spiffxp]

#919 setup the following:

• k8s-infra-prow-oncall@kubernetes.io - oncall/break-glass access to prow project and e2e projects
• k8s-infra-sig-scalability-oncall@kubernetes.io - oncall/break-glass access to k8s-infra-e2e-boskos-scale-* projects
• k8s-infra-prow-viewers@kubernetes.io - readonly access to prow project and e2e projects

They're only using primitive roles (owner and viewer)

[spiffxp]

k8s-infra-prow-viewers@kubernetes.io is significantly more useful now thanks to the custome prow.viewer role added in #1061

[spiffxp]

Revisiting the description

I'd like to get us to the point where we have something better, possibly:

• the ability for a larger group of people to be able to view things (logging, monitoring) for both prow build clusters

Members of k8s-infra-prow-viewers@kubernetes.io can do this

• the ability for a smaller trusted group of people to be able to write to the prow-build cluster
• the ability for a (even smaller? different?) trusted group of people to read secrets and write to the prow-build-trusted cluster

I question whether it's worth making the distinction between "can access secrets" and "can write to cluster". The more valuable thing would be to build trust and staff k8s-infra-prow-oncall@kubernetes.io. What do others think?

• the ability for people to see what's happening in a given e2e cluster (maybe v0 of this is predefining a role that can be manually/selectively granted)

Members of k8s-infra-prow-viewers@kubernetes.io can do this

RFC: what else do people think needs to be done to close this out?

[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-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[spiffxp]

/close
Calling this done, we can open separate issues if we'd like to adjust prow-related ACL's

[k8s-ci-robot]

@spiffxp: Closing this issue.

In response to this:

/close
Calling this done, we can open separate issues if we'd like to adjust prow-related ACL's

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.