Many repositories in Kubernetes do not have repository-specific security contacts listed in their SECURITY_CONTACTS file. Instead, they list the PSC members (current or former). With the exception of k/k, and this repo, the list should not contain only PSC members. I'll update issues or PRs (in the case where the repo has added contacts, but has not removed the PSC) with links back to this master issue.

We should move some of the things in the process doc into the README. In particular:

• who the members are
• how to contact us

Actively monitored security email alias for our project:

[email protected] (ref: kubernetes/k8s.io#1004)

1. Be an actively maintained and CNCF certified distribution of Kubernetes components.

TKG (and variants, like TKGI) are Certified Kubernetes distributions and listed at https://www.cncf.io/certification/software-conformance/.

2. Have a user base not limited to your own organization.

Yes, this is a user-facing/customer-focused distribution.
Website here: https://tanzu.vmware.com/kubernetes-grid

3. Have a publicly verifiable track record up to present day of fixing security issues.

A plan for a TKG-specific security advisories page is in the works.
VMware as a company has an all-product security advisory page: https://www.vmware.com/security/advisories.html

Members of the tkg-cve-disclosure list include @enj (PSC) and myself (SIG Release Chair), both with public track records of responsible disclosure and assisting with fix efforts, both upstream and internally.

4. Not be a downstream or rebuild of another distribution.

Correct. We only consume upstream Kubernetes.

5. Be a participant and active contributor in the community.

Yes. A vast majority of this list is composed of senior contributors to the project (including @enj, @dims, @nikhita, and myself).

6. Accept the Embargo Policy.

We agree to uphold the Kubernetes Embargo Policy.

7. Be willing to contribute back.

We agree to continue contributing to improvements in the overall security posture of the Kubernetes project.

8. Have someone already on the list vouch for the person requesting membership on behalf of your distribution.

Tagging the @kubernetes/product-security-committee for vouchability. :)

Our process documentation includes a bunch of timelines that I don't think we've followed.

We should review the timelines, and update them to something we expect to follow more closely if necessary. Then, we should make an effort to hold ourselves to those timelines.

Also, we should decide how to handle vulnerabilities that are legitimate vulnerabilities, but things we aren't going to prioritize fixing (generally because they're low severity & the fix requires a lot of work).

It seems we all agree, someone with a valid vulnerability deserves an award and we make a point of directing them towards hackerone.

With that in mind, would it be worth us having an auto responder to outline this to any new reports:

"Thank you for contacting kubernetes security If you're reporting a security vulnerability, please consider using the hackerone.com/kubernetes bug bounty program where there is an awards program".

My thinking is that everything goes to hackerone for a first triage and free's us up to focus just on the assigned items, rather than a lot of dupes / non issues?

If an auto respond is not possible, we could still perhaps cookie cut a reply?

Cheers,
Luke

From CVE-2018-1002105 post-mortem

Add distributor pre-announcement template that has placeholders for explicit “you may do X with the embargoed patch or information” statements, add instructions for how to ask for clarification (who to contact), and inclusion of tests for cluster vulnerability

/assign

moved from kubernetes/sig-release#418

Previously release-managers-private@ was nested within security@.

As of kubernetes/sig-release#900, there will be a separate security-release-team@ email address.

The security/security-release-process.md document should outline the new security-release-team@ email address and how this address should be used when wanting to bring the security release team into a discussion and allow release coordination of a security fix.

SECURITY_CONTACTS files currently use github user names, but github doesn't have private messaging, and users don't always have public email addresses.

We need a better solution, so that the PSC is able to reach out to the security contacts through a private channel. A few ideas include:

1. deprecate SECURITY_CONTACTS, and adopt github's new security advisory functionality
2. maintain a private contact information database for security contacts (bleh)
3. Just require email addresses in addition to github user IDs

/help

We (HackerOne) just released a new API endpoint to update the program policy page: https://api.hackerone.com/docs/v1#/programs/policy/update. I heard @kubernetes is interested in this, so I figured it would be good to you guys started.

Using the API endpoint should be fairly straightforward. You can set up an API token as described in the docs and start making API calls. If you don't want to test with your actual HackerOne program (as it logs all changes), you can create a test program via https://hackerone.com/teams/new.

The hardest part is catching the actual changes to https://github.com/kubernetes/security/blob/master/security-release-process.md#security-release-process and trigger an action. I saw Github started testing with Github Actions (https://github.com/features/actions) which might be an option. Otherwise, an after commit hook might be something that could work as well.

Please let me know if you have any questions or comments.

Per notification from Steering, SRC members should PR themselves into the leads@ list here

We also need to add that as a step to the onboarding and offboarding process docs.

From CVE-2018-1002105 post-mortem

"Is there a channel for discussion between members of the distributors list?"

Many of the members are secresponse aliases, so not all recipients of the distributors announcement emails will be members of the mailing list.

/assign @philips

Actively monitored security email alias for our project: [email protected]

1. Be an actively maintained and CNCF certified distribution of Kubernetes components.
Yes, we have Kubermatic and KubeOne https://github.com/kubermatic/kubeone
2. Have a user base not limited to your own organization.
KubeOne is open source and kubermatic is used by several enterprises e.g. https://metakube.syseleven.de
3. Have a publicly verifiable track record up to present day of fixing security issues.
We are working on upstream patches for https://github.com/kubernetes/dashboard
Additional we have an security newsletter where we announce all upstream patches https://www.loodse.com/newsletter/
4. Not be a downstream or rebuild of another distribution.
This does not apply, Kubermatic and KubeOne are unique.
5. Be a participant and active contributor in the community.
We have several member who are working on upstream project e.g.
https://github.com/nikhita
https://github.com/maciaszczykm
https://github.com/floreks
https://github.com/alvaroaleman
6. Accept the Embargo Policy.

We accept it
7. Be willing to contribute back.

We are definitely willing to help!
8. Have someone already on the list vouch for the person requesting membership on behalf of your distribution.
Brandon Philips

• kubernetes/security PR: #141
  • README.md
  • OWNERS_ALIASES
  • SECURITY_CONTACTS
• kubernetes/k8s.io PR: kubernetes/k8s.io#3337
  • groups/security-response-committee/groups.yaml
    • [email protected]
    • [email protected]
    • [email protected]
  • OWNERS_ALIASES
• kubernetes/community PR: kubernetes/community#6419
  • sigs.yaml
  • communication/slack-config/usergroups.yaml
    • Verify slack 2-factor auth
  • make generate
• kubernetes/org PR: kubernetes/org#3227
  • config/kubernetes/org.yaml
• HackerOne project membership
  • Verify 2-factor auth
• OpsGenie rotation
  • Add new user
  • Update rotation
• Mailing lists
  • Security Discuss - owner
  • Security Announce - owner
  • Kubernetes Announce - manager
  • Kubernetes Dev - member
• Verify Discuss account
• github.com/kubernetes-security membership
• Slack
  • Verify 2-factor auth
  • #SRC-private membership
  • #security-release-team membership
• Calendar meetings
• Google Docs access

Develop security guidelines, requirements and/or frameworks for Kubernetes subprojects. Ideally, sub projects would need to meet some minimum bar of requirements before they could be considered GA.

/help

• decide what the PSC's role & involvement should be
• write prescriptive checklist that can be followed by subproject owners without incident response experience
• decide how vulnerabilities are communicated

I'd like to create & document an incident response process that we can delegate better. This should include specific steps to follow, action items, timelines, etc. Ideally it could be handed off to non-SRC members who have never been involved in a Kubernetes security response before, and they'd be able to follow the instructions to lead a security response.

Considerations for non-SRC incident responders:

• They don't have access to HackerOne, distributors list, etc. An SRC member will still need to act in a comms role, minimally for H1 involvement and to post announcements.
• They don't (shouldn't) have access to our issues tracker. We need a workflow where individual issues can be shared on a need-to-know basis. Ideas: google doc (meh, requires google account), GitHub security advisories on a dedicated org (SRC needs to be repo admins)
• Every non-SRC IC should have a dedicated SRC contact. Regular status updates should be shared with the SRC member.

Update security release process and disclosure checklist to include fix team, release team, and PST in review of pre-disclosure announcement draft

From CVE-2018-1002105 post-mortem

/assign

Many Kubernetes vulnerabilities would have a very different severity score for a single user cluster vs. a multi tenant cluster. It would be nice if we had a well-defined (small) set of cluster configurations / security models that we evaluated against, and published multiple CVSS scores for. We would still need a "main" score to assign the vulnerability (and award a bounty), but for that we could just pick the "default" security model.

/cc @cjcullen

We need on-boarding and off-boarding docs for committee members. We have some of it documented here:

#16
#11

Define in security-release-process.md how levels (low/medium/high) correspond to an issue being embargoed.

For example, a low should not be embargo.

Actively monitored security email alias for our project: [email protected]

1. Be an actively maintained and CNCF certified distribution of Kubernetes components.
yes, DigitalOcean's managed kubernetes: DOKS

2. Have a user base not limited to your own organization.
yes, since DOKS is available to users of DigitalOcean

3. Have a publicly verifiable track record up to present day of fixing security issues.
yes, one of our biggest examples is with Spectre and Meltdown

also, we have a changelog for our managed kubernetes https://www.digitalocean.com/docs/kubernetes/changelog/

4. Not be a downstream or rebuild of another distribution.
DOKS is DO's managed Kubernetes, not a rebuild or downstream of another.

5. Be a participant and active contributor in the community.
yes, we have several members who are working on upstream contributions e.g.
https://github.com/morrislaw
https://github.com/timoreimann
https://github.com/bhcleek

6. Accept the Embargo Policy.
yes

7. Be willing to contribute back.
yes!!

8. Have someone already on the list vouch for the person requesting membership on behalf of your distribution.
Not sure, how do I go about requesting that?

This should help streamline sending initial "we have a vuln report" emails, and can provide a place to remind codeowners about careful treatment of non-public vulnerability information.

Add notes on how we use google groups to https://github.com/kubernetes/committee-security-response/blob/main/src-oncall.md

The kubernetes-security fork currently doesn't have functioning CI. There is a lack of clarity around ownership/priority/resourcing of it.

We should work with the PSC, test-infra team, and wg-k8s-infra to develop a game plan with ownership/staffing to properly maintain private test infrastructure for the security fork.

cc: @kubernetes/product-security-committee

• Add/remove from https://github.com/kubernetes/community/blob/master/sigs.yaml#L2602
• Add/remove from OpsGenie rotation
• https://groups.google.com/a/kubernetes.io/forum/#!forum/security owner
• https://groups.google.com/a/kubernetes.io/forum/#!forum/security owner
• https://groups.google.com/forum/#!forum/kubernetes-security-discuss owner
• https://groups.google.com/forum/#!forum/kubernetes-security-announce owner
• https://groups.google.com/a/kubernetes.io/forum/#!forum/distributors-announce owner
• https://github.com/kubernetes-security/security-disclosures/issues access
• ???

After doing this write an onboarding doc.

CVE's 2019-11247 and 2019-11249 were released on 8/5/19, while 2019-11248 was released on 8/6/19. Giving CVEs identifiers based on the issue order can disclose the presence of undisclosed security issues, and should be avoided.

Now that the new Product Security Committee has superseded the Product Security Team, and now that documents have been moved from https://github.com/kubernetes/sig-release to this repo, all of the SECURITY_CONTACTS files across all other Kubernetes project repositories need to be updated. They contain a link to the old location and reference the old PST. I will open PRs across the other repositories, but I need an issue to track all of those open PRs.

More information about the creation of the Product Security Committee and the docs move:

Create the Product Security Committee: kubernetes/steering#89
Create Product Security Committee, update references from PST to PSC: kubernetes/community#3311
Copy docs from sig-release, rename PST to PSC: #1
security: add tombstone files to redirect to new docs: kubernetes/sig-release#537

edit: Sorry that I titled all the PRs SECURITY_OWNERS instead of SECURITY_CONTACTS. Hopefully that wasn't too confusing.

It's not always clear how CVSS maps to Kubernetes. To help ensure consistency and reduce decision fatigue, we should document how we interpret and use various adjustments to rate vulnerabilities.

We now have a lot of different places that include sensitive vulnerability information, including:

• Email lists: [email protected], [email protected], [email protected], [email protected]
• HackerOne
• github.com/kubernetes-security repos
• (maybe) private slack channel
• Private docs (CNA, others?)

We should:

1. Record everywhere that includes sensitive information (a more permanent version of the above list). We may want to keep this list private (maybe in https://github.com/kubernetes-security/security-disclosures)
2. Establish a process for periodically reviewing the access to all these resources.

We haven't historically posted a security announcement for every vulnerability. We should establish a more well defined policy for when an announcement is sent.

Possible policies include:

1. Announcement for every CVE
2. Announcement for every CVE with a severity over X

Another possibility is to migrate off of the current announcement flow, to something like a vulnerability dashboard that we've previously discussed (can't find the issue?).

Kubernetes Community repositories must include a
SECURITY_CONTACTS file to define points of contact that can assist with
triaging security issues when requested by the Security Response Committee.

The template for the file can be found in the kubernetes-template-project.

This issue will periodically comment with reminders until SECURITY_CONTACTS has
been created.

To report any issues with this tool, see here.

Hey folks, I was going to send an email to the team but this solves the same problem 😄

I haven't been available for a number of reasons, and, despite that I keep thinking to myself "I'll get to it later".. later never comes.

I had the chance to catch up with @tallclair in Seattle before travel was restricted and, given that, I'd like to ask that I be offboarded from the PSC, I think the position can better be filled by someone in the community.

Pardon my absenteeism, and thanks for the opportunity friends <3

Actively monitored security email alias for our project: [email protected]

1. Be an actively maintained and CNCF certified distribution of Kubernetes components.
cncf/k8s-conformance#959 (comment)

2. Have a user base not limited to your own organization.
Lokomotive has open-source users, as well as supported users.

3. Have a publicly verifiable track record up to present day of fixing security issues.
This is still early, but releases on https://github.com/kinvolk/lokomotive

4. Not be a downstream or rebuild of another distribution.
Lokomotive has its roots from https://github.com/poseidon/typhoon and still a good relationship, but had differing goals so it fully diverged last year.
Works with upstream otherwise.

5. Be a participant and active contributor in the community.
https://github.com/iaguis
https://github.com/alban
https://github.com/surajssd

6. Accept the Embargo Policy.

yes

7. Be willing to contribute back.

yes

8. Have someone already on the list vouch for the person requesting membership on behalf of your distribution.
Not yet, I will work on this next

Please update the security policy to include how the disclosure of vulnerabilities are handled at the various API stability levels and Feature Stages (alpha, beta, and stable).

The security policy and API versioning documents are not clear on how a reporter should communicate to the security team with regards to finding issues across the various API stability levels and Feature Stages. There is mention of "Breaking or bypassing any security feature provided" in the security policy, however "provided" is not explicitly defined. It would be helpful to understand how to report and what to expect from the security team based on status of component.

Reference --
https://github.com/kubernetes/security/blob/master/security-release-process.md

https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/#using-a-feature

https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-versioning

• Add/remove from https://github.com/kubernetes/community/blob/master/sigs.yaml#L2602
• Add/remove from OpsGenie rotation
• https://groups.google.com/a/kubernetes.io/forum/#!forum/security owner
• https://groups.google.com/a/kubernetes.io/forum/#!forum/security-discuss-private owner
• https://groups.google.com/forum/#!forum/kubernetes-security-discuss owner
• https://groups.google.com/a/kubernetes.io/forum/#!forum/distributors-announce owner
• https://github.com/kubernetes-security/security-disclosures/issues access
• ???

Via #15

As per the email sent to kubernetes-dev[1], please create a SECURITY_CONTACTS
file.

The template for the file can be found in the kubernetes-template repository[2].
A description for the file is in the steering-committee docs[3], you might need
to search that page for "Security Contacts".

Please feel free to ping me on the PR when you make it, otherwise I will see when
you close this issue. :)

Thanks so much, let me know if you have any questions.

(This issue was generated from a tool, apologies for any weirdness.)

[1] https://groups.google.com/forum/#!topic/kubernetes-dev/codeiIoQ6QE
[2] https://github.com/kubernetes/kubernetes-template-project/blob/master/SECURITY_CONTACTS
[3] https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance-template-short.md

See kubernetes/kubernetes-template-project#35. Once that merges into the project template, we need to update all the repos to add the new file.

I added a validation script for Kubernetes CVEs in https://github.com/kubernetes-security/cvelist-public/pull/4, but it would be great to get this hooked up as a github presubmit check.

GitHub has automated dependency alerts for some languages, https://docs.github.com/en/free-pro-team@latest/github/managing-security-vulnerabilities/about-alerts-for-vulnerable-dependencies

You can see all of the alerts that affect a particular project on the repository's Security tab or in the repository's dependency graph. For more information, see "Viewing and updating vulnerable dependencies in your repository."

By default, we notify people with admin permissions in the affected repositories about new Dependabot alerts. GitHub never publicly discloses identified vulnerabilities for any repository. You can also make Dependabot alerts visible to additional people or teams working repositories that you own or have admin permissions for. For more information, see "Managing security and analysis settings for your repository."

We've received some of these within the Kubernetes orgs (I can see these currently by way of email to k8s-ci-robot...)

• Does PSC even care? 🙃

If so:

• Should we rely on repo admins seeing and addressing these?
  • Should we provide some guidance to repo admins WRT this?
• Should we make dependabot alerts visible to PSC?

I'm not sure if there's anything high value here, but I think we should probably have some discussion around it to point back to in the future, at minimum.

I've gone ahead and forwarded one to PSC via [email protected], for reference. see also this slack thread.

Actively monitored security email alias for our project:
[email protected]

1. Be an actively maintained and CNCF certified distribution of Kubernetes components.
Canonical distributes and supports CNCF Kubernetes systems.

2. Have a user base not limited to your own organization.
Yes

3. Have a publicly verifiable track record up to present day of fixing security issues.
Please view usn.ubuntu.com to see the list of issues we have fixed over time.

4. Not be a downstream or rebuild of another distribution.
We are not.

5. Be a participant and active contributor in the community.
We are an active participant to the k8s community.

6. Accept the Embargo Policy.

Yes, the security team is aware of and participates in embargoed security issues.

7. Be willing to contribute back.

As a proud member of the Open Source community we would be happy to commit back.

8. Have someone already on the list vouch for the person requesting membership on behalf of your distribution.
Jorge Castro should be able to vouch for us.

Please let me know if you have any questions! -Joe

Actively monitored security email alias for our project: [email protected]

1. Be an actively maintained and CNCF certified distribution of Kubernetes components.
Yes, we have active AWS, Azure, and on-prem distributions.
Sample AWS conformance report: cncf/k8s-conformance#1052

2. Have a user base not limited to your own organization.
Yes, some public customers are listed on our website

3. Have a publicly verifiable track record up to present day of fixing security issues.
We announce changes in our release notes. Two examples with security fixes: 1, 2.

4. Not be a downstream or rebuild of another distribution.
We are our own platform

5. Be a participant and active contributor in the community.
Some public events are listed on our website.
Some individual contributors and PRs from our organization:
https://github.com/njuettner
https://github.com/webwurst
kubernetes/kops#8780
kubernetes-sigs/cluster-api-provider-azure#978
kubernetes/kube-state-metrics#1238

6. Accept the Embargo Policy.
We accept

7. Be willing to contribute back.
Happily

8. Have someone already on the list vouch for the person requesting membership on behalf of your distribution.
Kinvolk has kindly agreed to vouch for us

So this started off as joking around on Twitter:

@jeefy
Okay but like what if we deprecated meetings?

@justaugustus
If we can prove security impact, we might be able to short-circuit the full deprecation period and get rid of them within a cycle!

...but in trying to prove the point, I couldn't easily find anything explicit about what happens when something critical enough emerges in a component that is subject to the deprecation policy.

What's our response in cases like that?
And is it documented somewhere?

cc: @kubernetes/product-security-committee @IanColdwater @tabbysable

From CVE-2018-1002105 post-mortem

Update announcement template to include placeholders for concrete steps to determine if a cluster has a vulnerable version/configuration

/assign

moved from kubernetes/sig-release#419

As per the email sent to kubernetes-dev[1], please create a SECURITY_CONTACTS
file.

The template for the file can be found in the kubernetes-template repository[2].
A description for the file is in the steering-committee docs[3], you might need
to search that page for "Security Contacts".

Please feel free to ping me on the PR when you make it, otherwise I will see when
you close this issue. :)

Thanks so much, let me know if you have any questions.

(This issue was generated from a tool, apologies for any weirdness.)

[1] https://groups.google.com/forum/#!topic/kubernetes-dev/codeiIoQ6QE
[2] https://github.com/kubernetes/kubernetes-template-project/blob/master/SECURITY_CONTACTS
[3] https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance-template-short.md

Should we have a central place where kubernetes security vulnerabilities are published? Our current announcement template includes a lot of mailing lists, and discuss.kubernetes.io. We also usually file a github issue with more details on the vulnerability.

Some ideas include:

• (current process) just use kubernetes-security-announce history
• Create a security bulletin on the website (something similar to GKE security bulletins or AWS security bulletins)
• Use github
  • File github issues with a dedicated label
  • File github issues in a dedicated repo
  • Leverage GitHub security advisories?

/help

I would like to have all issues filed as a result of the Third-party Security Audit Report all link back to a single issue to make it easier to track status. I'd like to keep this issue open until we feel that all raised issues have been satisfactorily addressed.

This list is roughly right:

• product-security-committee in https://github.com/kubernetes/community/blob/master/sigs.yaml
• Kubernetes OpsGenie rotation https://app.opsgenie.com/teams/dashboard/633ac733-665f-4d62-871e-cbc011f37037
• https://groups.google.com/a/kubernetes.io/forum/#!forum/security owner
• https://groups.google.com/a/kubernetes.io/forum/#!forum/security-discuss-private owner
• https://groups.google.com/forum/#!forum/kubernetes-security-discuss owner
• https://groups.google.com/a/kubernetes.io/forum/#!forum/distributors-announce owner
• https://github.com/kubernetes-security/security-disclosures/issues access
• HackerOne triage & management
• ???

Including:

• decision flow documentation around when/whether to do branch freezes and CVE-only patch releases, versus keeping the train moving on a consistent schedule
• how non-k/k projects should handle embargoed releases
• who owns each step in the embargoed release process

Add a step to the onboarding and offboarding documentation to PR SRC members into the OSS-Fuzz contacts list for Kubernetes.