search

kubernetes / release

Release infrastructure for Kubernetes and related components
Apache License 2.0
485 stars 502 forks source link

Adding security details to release notes #1354

Closed cji closed 3 years ago

cji commented 4 years ago

What would you like to be added:

The Product Security Committee would like the ability to include details about security fixes in release notes just prior to release announcements going out.

Why is this needed:

There are situations where a vulnerability with a Medium or Low severity may be fixed semi-publicly (for example with a public PR but not mentioning the security implications). When the commit(s) are cherry-picked, they would not include any of the CVE/impact/other details in the release notes.

@justaugustus provided an example of how this could work:

  • from k-security org (or some other private method) PSC files some yaml, maybe: 
    cve: CVE-57687939425739480235
description: Really bad SSRF in KCM
impact: low|medium|high|critical
mitre_link: https://blah
kubernetes_tracking: https://github.com/kubernetes/issues/87945258935
  • that's reviewed and merged via some pipeline that PSC + Releng have visibility into
  • post-submit scrapes these and copies them to a private releng staging bucket
  • existing release notes tool is extended to look in that bucket during staging/release process

/cc @kubernetes/release-engineering /cc @kubernetes/product-security-committee

tallclair commented 4 years ago

The described process sounds good, but it might be overkill. On release day, what time are releases usually cut? We typically aim to lift embargoes at 9am PT (negotiable), so I'm wondering whether we could simply merge a public PR right around that time, and start the release after?

EDIT: To clarify, I think we should have the release notes ready & approved before hand, so the public PR doesn't need to be reviewed.

k8s-release-robot commented 4 years ago

We’ve gotten to be a bit follow the sun. We sometimes do start building on morning of release day much closer to the international date line (eg: Japan, China, Europe) than Pacific Time’s start of day.

-- Tim Pepper Orchestration Lead VMware Open Source Technology Center

From: Tim Allclair notifications@github.com Reply-To: kubernetes/release reply@reply.github.com Date: Thursday, June 11, 2020 at 4:42 PM To: kubernetes/release release@noreply.github.com Cc: Kubernetes Release Robot release-managers-private@kubernetes.io, Team mention team_mention@noreply.github.com Subject: Re: [kubernetes/release] Adding security details to release notes (#1354)

The described process sounds good, but it might be overkill. On release day, what time are releases usually cut? We typically aim to lift embargoes at 9am PT (negotiable), so I'm wondering whether we could simply merge a public PR right around that time, and start the release after?

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHubhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkubernetes%2Frelease%2Fissues%2F1354%23issuecomment-642984046&data=02%7C01%7Ctpepper%40vmware.com%7C819bf8f2ecce475c269908d80e612653%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637275157721590219&sdata=4Xjl7lfyy43B%2FuR1agbpes7AV2iWvxMI4fJTBOVc31Q%3D&reserved=0, or unsubscribehttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAH7UBLEIIFY56QGHC3HDP6LRWFTXPANCNFSM4N3XUTSQ&data=02%7C01%7Ctpepper%40vmware.com%7C819bf8f2ecce475c269908d80e612653%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637275157721600211&sdata=zsdsj8dJS0YFEzwECU2TBNihRGRWd5c2n6wCWNmIZzQ%3D&reserved=0.

You received this message because you are subscribed to the Google Groups "release-managers-private" group. To unsubscribe from this group and stop receiving emails from it, send an email to release-managers-private+unsubscribe@kubernetes.iomailto:release-managers-private+unsubscribe@kubernetes.io. To view this discussion on the web visit https://groups.google.com/a/kubernetes.io/d/msgid/release-managers-private/kubernetes/release/issues/1354/642984046%40github.comhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fkubernetes.io%2Fd%2Fmsgid%2Frelease-managers-private%2Fkubernetes%2Frelease%2Fissues%2F1354%2F642984046%2540github.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=02%7C01%7Ctpepper%40vmware.com%7C819bf8f2ecce475c269908d80e612653%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637275157721600211&sdata=Inm7fMRCsZySQBxXKTVpAh6%2BlvY9A9KtGq4b07r%2BvvM%3D&reserved=0.

puerco commented 4 years ago

Another approach, easier to implement IMHO, could be to have the PSC publish the vulnerability info on a known location in k/security and we would modify the release notes tool to scan for that data before cutting a new patch version. That file could tie together commits that have been cherry picked and have them treated separately in the doc and would enable us to get a unified security release note on all branches, with links to every related commit.

To make the release notes process independent from the embargo lift time, those files could be published at any time encrypted in kms with a key shared with one the releng groups (say k8s-infra-release-editors). That group would need to have the kms/decrypter role in the project, of course. This would keep the vulnerability hidden right until the release is cut and leave full control of the disclosure with the PSC, no PR reviews needed.

saschagrunert commented 4 years ago

Alright, sounds like a plan. How about this design proposal:

  1. Find a flexible format for generally mapping release notes, for example: 
    - pull-requests:
- 12345
- 67890
release-note: This release note has been modified
cve:  # optional
id: CVE-2019-1010260
description: Really bad SSRF in KCM
published: 2020-10-05
score: 5.2
issues:  # optional
  - 9876
  - 9875
  2. Update krel [release-notes,changelog] and release-notes to be able to consume these mappings during release notes generation (recursively scraping directories and files)
  3. Add a feature to be able to consume the mappings from a private remote resource (a git repo?)
saschagrunert commented 4 years ago

I think we could solve multiple issues with the above mentioned proposal:

The first rough idea (without proposing a KEP) would be to add the minimal feature of being able to map notes from A to B. Then we could demo that at one of the next SIG Release meetings and discuss possible process changes around it.

k8s-release-robot commented 4 years ago

I like this. It would be a lot easier than trying to do all of patch/test on a separate repo, or making late changes to mainline repo with explicit synchronization to not release without all needed changes.

If we do this, I think we should still edit the PR on mainline for visibility after release.

One unfortunately gap that would remain is not having the information directly in mainline git commit history. We can’t rewrite history there. I’d prefer a solid git history that is authoritative, without being tied to GitHub artifacts, but…I’m not sure how many people use git directly anymore. Much of Kubernetes is tightly coupled with GitHub-specific artifacts at this point.

-- Tim Pepper Orchestration Lead VMware Open Source Technology Center

From: Sascha Grunert notifications@github.com Reply-To: kubernetes/release reply@reply.github.com Date: Tuesday, June 16, 2020 at 8:07 AM To: kubernetes/release release@noreply.github.com Cc: Kubernetes Release Robot release-managers-private@kubernetes.io, Team mention team_mention@noreply.github.com Subject: Re: [kubernetes/release] Adding security details to release notes (#1354)

I think we could solve multiple issues with the above mentioned proposal:

The first rough idea (without proposing a KEP) would be to add the minimal feature of being able to map notes from A to B. Then we could demo that at one of the next SIG Release meetings and discuss possible process changes around it.

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHubhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkubernetes%2Frelease%2Fissues%2F1354%23issuecomment-644824607&data=02%7C01%7Ctpepper%40vmware.com%7C1efb302024e7456a626508d81206f04d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637279168306653737&sdata=H5kFfzCFAhJsYgVVOCAajgLaCHWeZVRN3xuzJsvOiVk%3D&reserved=0, or unsubscribehttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAH7UBLGYL6PDFVVDBO6LAETRW6DBXANCNFSM4N3XUTSQ&data=02%7C01%7Ctpepper%40vmware.com%7C1efb302024e7456a626508d81206f04d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637279168306663727&sdata=HTib3nB8Q1VnZxYQsn4vbVkj4XyvR7QrTdLcumzO7w4%3D&reserved=0.

You received this message because you are subscribed to the Google Groups "release-managers-private" group. To unsubscribe from this group and stop receiving emails from it, send an email to release-managers-private+unsubscribe@kubernetes.iomailto:release-managers-private+unsubscribe@kubernetes.io. To view this discussion on the web visit https://groups.google.com/a/kubernetes.io/d/msgid/release-managers-private/kubernetes/release/issues/1354/644824607%40github.comhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fkubernetes.io%2Fd%2Fmsgid%2Frelease-managers-private%2Fkubernetes%2Frelease%2Fissues%2F1354%2F644824607%2540github.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=02%7C01%7Ctpepper%40vmware.com%7C1efb302024e7456a626508d81206f04d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637279168306663727&sdata=sp8j157a5fB7ujspcbHPt7nT6h8ZKqEJp7oR1sV%2BnJI%3D&reserved=0.

tpepper commented 4 years ago

/assign @puerco

lauriapple2 commented 4 years ago

/assign @puerco

puerco commented 4 years ago

We already have the mechanism in place to add the CVE information to the release notes and changelog. The current proposal for the MD format is in PR#1441, a sample of the markdown output can be seen here.

Could the interested parties comment on the output so that we can move forward with it?

lasomethingsomething commented 4 years ago

/priority important-soon

fejta-bot commented 4 years ago

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

saschagrunert commented 4 years ago

/remove-lifecycle stale

fejta-bot commented 3 years ago

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