K8s release managers updates
Tim Pepper
During the past year as a release team member and SIG Release chair I've been working to get a better handle on the project's release process and enable a bit broader set of folks to participate. Our goal in changes is to have better response times, more reliable processes, and not be burning folks out.
We've shifted from each patch release stream (ie: 1.12 and prior) having one person handling all of the patch/build/release flow for nine months to instead have a team collaborating across time zones on all supported branches:
https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md
This team is staffed by folks who've previously been branch managers. While a team, this is still a very limited set of hands on the steering wheel. Today this is:
- Aleksandra Malinowska (@aleksandra-malinowska)
- Hannes Hörl (@hoegaarden)
- Pengfei Ni (@feiskyer)
- Tim Pepper (@tpepper)
all of whom are of course signed off on the embargo process.
But at the link above you'll also see reference to this newer page:
https://github.com/kubernetes/sig-release/blob/master/release-managers.md
and there you'll see quite a few more names and roles on our side.
And there we'd like to engage in conversation with the Product Security Committee and community on a couple "security release team" topics:
- Patch Release Team: The security release team includes the above four patch managers each by name, though management of their membership is delegated to us, with manager priv's on the security google group. We have our own kubernetes-releas...@googlegroups.com nowadays. Would it be better separation of concerns to have our list nested in the security list and us not have manager priv's on your Google Group? And if so, should we add a security team member to our list's mgmt ACL for ya'll to be able to audit our membership?
- There are a few places additional folks on our side may to some extent come in contact with PSC embargoed information, while not formally members of the security release team. We don't think any of these three sets of folks need explicitly included in the private groups, but we want to remind PSC they may come into security conversations and work, ask for an ACK that we can manage this on our side with all involved abiding the embargo process, and ask for any other guidance or requirement PSC might have:
- SIG Release Chairs: Potentially can access the embargoed chain as Google Group and Slack admins for SIG Release's subprojects. Also generally a privileged reviewer/approver set of folks in the build/release pipeline.
- Branch Managers: Each release team lead is on the private security list for their three month release cycle. Branch manager(s) within each release team are currently not on the security private list and this should be ok as they're primarily engaged in master branch public work. But there is a chance late in a release cycle a CVE needs quick handling and the branch managers are pulled in.
- Build Admins: There are a few parts of the build/release process which still require a Googler to press some buttons. These individuals are pulled in at the point we are planning a date on which to make a release. They generally do not have or need access to CVE detail information, but will be involved in the private release managers' discussions to insure specific patch artifacts are correctly built and published on the target date.
- Associates: We're starting our own associate program. We want to work additional folks through the progression from helper, to privileged on upcoming release (master alpha/beta/rc), to privileged on stable release branches. This will give us a pipeline of helpers with time to establish trust. By default the associates would not be involved with embargoed flows until they've graduated up into branch or patch release management so this is roughly as per today. Are there additional considerations the PSC would like us to make here?
I've also noted a broken url in the Security Release Process document related to this so have also opened a PR to update the docs: https://github.com/kubernetes/security/pull/42
--
Tim Pepper
Orchestration & Containers Lead
VMware Open Source Technology Center
Tim Allclair
During the past year as a release team member and SIG Release chair I've been working to get a better handle on the project's release process and enable a bit broader set of folks to participate. Our goal in changes is to have better response times, more reliable processes, and not be burning folks out.
We've shifted from each patch release stream (ie: 1.12 and prior) having one person handling all of the patch/build/release flow for nine months to instead have a team collaborating across time zones on all supported branches:
https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md
This team is staffed by folks who've previously been branch managers. While a team, this is still a very limited set of hands on the steering wheel. Today this is:
- Aleksandra Malinowska (@aleksandra-malinowska)
- Hannes Hörl (@hoegaarden)
- Pengfei Ni (@feiskyer)
- Tim Pepper (@tpepper)
all of whom are of course signed off on the embargo process.
But at the link above you'll also see reference to this newer page:
https://github.com/kubernetes/sig-release/blob/master/release-managers.md
and there you'll see quite a few more names and roles on our side.
And there we'd like to engage in conversation with the Product Security Committee and community on a couple "security release team" topics:
- Patch Release Team: The security release team includes the above four patch managers each by name, though management of their membership is delegated to us, with manager priv's on the security google group. We have our own kubernetes-releas...@googlegroups.com nowadays. Would it be better separation of concerns to have our list nested in the security list and us not have manager priv's on your Google Group? And if so, should we add a security team member to our list's mgmt ACL for ya'll to be able to audit our membership?
- There are a few places additional folks on our side may to some extent come in contact with PSC embargoed information, while not formally members of the security release team. We don't think any of these three sets of folks need explicitly included in the private groups, but we want to remind PSC they may come into security conversations and work, ask for an ACK that we can manage this on our side with all involved abiding the embargo process, and ask for any other guidance or requirement PSC might have:
- SIG Release Chairs: Potentially can access the embargoed chain as Google Group and Slack admins for SIG Release's subprojects. Also generally a privileged reviewer/approver set of folks in the build/release pipeline.
- Branch Managers: Each release team lead is on the private security list for their three month release cycle. Branch manager(s) within each release team are currently not on the security private list and this should be ok as they're primarily engaged in master branch public work. But there is a chance late in a release cycle a CVE needs quick handling and the branch managers are pulled in.
- Build Admins: There are a few parts of the build/release process which still require a Googler to press some buttons. These individuals are pulled in at the point we are planning a date on which to make a release. They generally do not have or need access to CVE detail information, but will be involved in the private release managers' discussions to insure specific patch artifacts are correctly built and published on the target date.
- Associates: We're starting our own associate program. We want to work additional folks through the progression from helper, to privileged on upcoming release (master alpha/beta/rc), to privileged on stable release branches. This will give us a pipeline of helpers with time to establish trust. By default the associates would not be involved with embargoed flows until they've graduated up into branch or patch release management so this is roughly as per today. Are there additional considerations the PSC would like us to make here?
I've also noted a broken url in the Security Release Process document related to this so have also opened a PR to update the docs: https://github.com/kubernetes/security/pull/42
--
Tim Pepper
Orchestration & Containers Lead
VMware Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups "kubernetes-security-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-security...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-security-discuss/5BE25C0D-4C3D-426D-BAA8-6319B34B3890%40vmware.com.
Stephen Augustus
- 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
- (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 security-r...@kubernetes.io
- (SIG Release) Rename security-r...@kubernetes.io to release-...@kubernetes.io
- (SIG Release) Ensure all SIG Release Chairs, Patch Release Team members, Branch Managers, and Build Admins are members of release-...@kubernetes.io
- (kubernetes.io GSuite Admins) Create release-ma...@kubernetes.io, which would include Release Manager Associates and could nest release-...@kubernetes.io
- (SIG Release) Delete/archive Release Mgmt Google Groups:
- (SIG Release) Assign the "OSS Kubernetes Release Manager" IAM role to release-...@kubernetes.io 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 release-ma...@kubernetes.io, 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
Stephen Augustus
Stephen Augustus
Joe Beda
Hey Stephen – I thought I created this yesterday. You still need something here? Or am I confused?
Joe
From: Stephen Augustus <Ste...@agst.us>
Date: Tuesday, August 6, 2019 at 10:03 AM
To: "comm...@kubernetes.io" <comm...@kubernetes.io>, steering <stee...@kubernetes.io>
Cc: Tim Allclair <tall...@google.com>, Tim Pepper <tpe...@vmware.com>, "kubernetes-se...@googlegroups.com" <kubernetes-se...@googlegroups.com>, Caleb Miles <cmi...@pivotal.io>
Subject: [k8s-steering] Re: K8s release managers updates
Just pinging again on this one.
-- Stephen
On Mon, Jul 29, 2019 at 2:33 PM Stephen Augustus <Ste...@agst.us> wrote:
Community / Steering--
Can one of you lovely folks help out with creating release-...@kubernetes.io and adding me as a manager/owner for that (ste...@agst.us)?
Context is below, with active convo happening on https://github.com/kubernetes/sig-release/issues/732.
-- Stephen
On Thu, Jul 25, 2019 at 8:32 PM Stephen Augustus <Ste...@agst.us> wrote:
Just wanted to ping again on moving this forward.
Caleb and I agree to uphold the security embargo.
--
You received this message because you are subscribed to the Google Groups "steering" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
steering+u...@kubernetes.io.
To view this discussion on the web visit
https://groups.google.com/a/kubernetes.io/d/msgid/steering/CAFQm5yTkrX-R6pGfiZmqMCvkmtBn7nLy9gmPydQbD0JLsQ_uDQ%40mail.gmail.com.
Stephen Augustus
Stephen Augustus
- private: release-mana...@kubernetes.io (security-r...@kubernetes.io to be renamed after lazy consensus)
- public: release-...@kubernetes.io (already created by Joe: https://kubernetes.slack.com/archives/C1TU9EB9S/p1565048027369000?thread_ts=1564422587.170800&cid=C1TU9EB9S)
Stephen Augustus
- private: release-mana...@kubernetes.io
- public: release-...@kubernetes.io
Stephen Augustus
Jordan Liggitt
Before granting release-mana...@kubernetes.io 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?
Additionally, can we create
security...@kubernetes.io, which would contain:Per @tallclair's suggestion on the thread, this (and unnesting
release-managers-private@fromsecurity@) would allow us to minimize traffic torelease-managers-private@to be only release-focused.Setting Tuesday, 8/13 at 5pm ET as the lazy consensus time.
-- Stephen
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-re...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-release/CAFQm5yR5dReUULo%2B5Gd0L_Hn7_rgzRdnxa4bj%2BbQ_T2rmef3pw%40mail.gmail.com.
Stephen Augustus
Yeah, I think I'd prefer one more list, if that helps prevent autocomplete snafus.-- Stephen
Stephen Augustus
Before granting release-mana...@kubernetes.io 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?
Additionally, can we create security...@kubernetes.io, which would contain:
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.
Setting Tuesday, 8/13 at 5pm ET as the lazy consensus time.
-- Stephen
Stephen Augustus
Brandon Philips
You received this message because you are subscribed to the Google Groups "steering" group.
To unsubscribe from this group and stop receiving emails from it, send an email to steering+u...@kubernetes.io.
To view this discussion on the web visit https://groups.google.com/a/kubernetes.io/d/msgid/steering/CAFQm5yReUMStfgs%2BT_JnPooE9yDptfQp1dW0wmEEXaF6xu1HFA%40mail.gmail.com.