Process and communication improvements for Release Engineering

[justaugustus]

Some near term goals in my head:

• (Ensure SIG Release Chairs own all SIG Release assets #897) Ensure SIG Release Chairs own all SIG Release assets
• Dedupe SIG Release communication channels where possible/appropriate
• Grant access to release GCP projects via Google Groups, instead of per user

So concretely, what I'd like to do:

• (SIG Release) Have all SIG Release Chairs, Patch Release Team members, Branch Managers, and Build Admins agree to uphold the security embargo
• (PSC) Grant access for SIG Release Chairs to manage [email protected]
• (SIG Release) Rename [email protected] to [email protected]
• (SIG Release) Ensure all SIG Release Chairs, Patch Release Team members, Branch Managers, and Build Admins are members of [email protected]
• (kubernetes.io GSuite Admins (@kubernetes/steering-committee)) Create [email protected], which would include Release Manager Associates and could nest [email protected]
• (SIG Release) Delete/archive Release Mgmt Google Groups:
  • [email protected]
  • [email protected]
• (SIG Release) Assign the "OSS Kubernetes Release Manager" IAM role to [email protected] in the kubernetes-release-test GCP project, which will allow members to cut releases on behalf of the project
• (SIG Release) Develop a descoped viewer role for the kubernetes-release-test GCP project and assign it to [email protected], to allow Associates some limited access to follow along
• (SIG Release) Audit and prune extraneous user and service accounts from the kubernetes-release-test GCP project
• (SIG Release/k8s Infra) Leverage repo-based configs in k/k8s.io to manage Release Manager Google Groups

(Started from conversation on k-security-discuss.)

/assign
/cc @kubernetes/sig-release-admins @kubernetes/release-engineering @kubernetes/product-security-committee
/area release-eng
/priority important-soon
/kind feature cleanup
/milestone v1.16

[liggitt]

(PSC) Grant access for SIG Release Chairs to manage [email protected]

@tpepper and @justaugustus are added as managers of the list, and can add/manager additional members/managers

[liggitt]

Rename [email protected] to [email protected]

Given the type of communications sent to the security release team list, I think the list name should reflect its security-sensitive or private nature. (e.g. [email protected], [email protected], etc)

[justaugustus]

@liggitt @jonpulsifer -- sounds good.
How's:

• private: [email protected]
• public: [email protected]

[liggitt]

that seems reasonable

[jonpulsifer]

+1, sgtm

[idealhack]

+1

Let me know which I can help with.

[cpanato]

+1
let me know as well where i can help

[justaugustus]

@idealhack @cpanato -- Most of this will need to be handled by administrators of the relevant properties (SIG Chairs, PSC, kubernetes.io GSuite Admins), but I'll let you know if there's anything we can delegate! :)

[tallclair]

+1, lgtm

[philips]

@justaugustus what will the [email protected] list be used for? Do you think we should consider using the https://github.com/kubernetes/k8s.io/blob/fc4218bdc7de25fc2fe4b7dca00d61c5bde61366/groups/groups.yaml automation?

[dims]

@philips i have been thinking the same thing. though currently the automation that drives the groups.yaml has a hard coded prefix k8s-infra- to avoid stomping existing google groups. i have to figure out how to do better ..

[justaugustus]

@philips -- @jbeda created the group for me earlier. I've closed out the steering issue (kubernetes/steering#115). We'll use [email protected] for general communications for all Release Managers and [email protected] for private comms (PSC + internal comms for Patch Release Team, SIG Chairs, and Build Admins). Both will also be used for permissions to SIG Release projects on GCP.

And yes, I definitely want to use the yaml-based configs eventually, but as @dims mentioned, there is currently a restriction on group naming. I've added an item for it above.

[justaugustus]

The mailing list changes have been approved in this thread.
I've issued a PR (#747) to change the references to mailing lists and a lazy consensus period of Wednesday, 8/7 at 6pm ET.

I'll wait until that time passes and all potential members of the private mailing list have agreed to uphold the security embargo before proceeding with any group membership changes/renames/archivals.

[justaugustus]

Notified k-security-discuss, release-managers, k-release-managers-private, k-sig-release, k-release-team, steering, community of changes and lazy consensus period: https://groups.google.com/d/topic/kubernetes-sig-release/xHrHQcjwWjk/discussion

[justaugustus]

Lazy consensus for mailing lists changes has been achieved.

@jbeda has granted me owner access to [email protected] and I've changed the list email address to [email protected].
Holds have been released on #747 and kubernetes/test-infra#13793.

[justaugustus]

Documentation updates: kubernetes/committee-security-response#45, #751

[justaugustus]

Before granting [email protected] GCP access, I'd like to clean up membership leaving only Release Managers. IIUC, the PSC was only on this list to manage membership, which is no longer required.

Any issues with removing the following people?

• sc1 (@philips)
• @cjcullen
• @liggitt
• @tallclair

Additionally, can we create [email protected], which would contain:

• [email protected]
• [email protected]

Per @tallclair's suggestion on the thread, this (and unnesting release-managers-private@ from security@) would allow us to minimize traffic to release-managers-private@ to be only release-focused.

Will send to ML as well.

[justaugustus]

Most of the non-nebulous, cross-group tasks here have been completed, so we're just about ready to close this out.

@kubernetes/product-security-committee -- How do we want to handle coordinating security releases?

Option 1

Continue as-is, with release-managers-private@ nested within security@.
Allows Patch Release Team advance heads-up on potential CVEs and minimizes list sprawl

Option 2

Use security-release-team@.
Right now, I'm the only member, but this would be expanded to nest:

• release-managers-private@
• security@

Here, Patch Release Team members would have to be explicitly added to the thread to action on coordinating a release.

Let me know what you think.

[justaugustus]

Ping @kubernetes/release-engineering for any last-minute thoughts...

[onlydole]

Looks good to me! 👍

[justaugustus]

@kubernetes/product-security-committee -- How do we want to handle coordinating security releases?

PSC is trending towards option two, so I've opened kubernetes/k8s.io#492 for discussion/review.

Opened #896 to track documentation updates.

[justaugustus]

kubernetes/k8s.io#492 has merged and I've confirmed that the security-release-team@ list is now active: https://groups.google.com/a/kubernetes.io/d/topic/security/QzotN1Lq93U/discussion

The remaining tasks on the list have been opened as individual issues:

• Ensure SIG Release Chairs own all SIG Release assets: Ensure SIG Release Chairs own all SIG Release assets #897
• Audit and prune extraneous user and service accounts from the kubernetes-release-test GCP project: Audit and prune extraneous user and service accounts from SIG Release GCP projects #898

/close

[k8s-ci-robot]

@justaugustus: Closing this issue.

In response to this:

kubernetes/k8s.io#492 has merged and I've confirmed that the security-release-team@ list is now active: https://groups.google.com/a/kubernetes.io/d/topic/security/QzotN1Lq93U/discussion

The remaining tasks on the list have been opened as individual issues:

• Ensure SIG Release Chairs own all SIG Release assets: Ensure SIG Release Chairs own all SIG Release assets #897
• Audit and prune extraneous user and service accounts from the kubernetes-release-test GCP project: Audit and prune extraneous user and service accounts from SIG Release GCP projects #898

/close

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.