Repository: kubernetes/security
Branch: main
Commit: bb1a57766f37
Files: 29
Total size: 96.0 KB
Directory structure:
gitextract_q9uzkq0d/
├── .github/
│ └── ISSUE_TEMPLATE/
│ └── distributors-application.md
├── CONTRIBUTING.md
├── LICENSE
├── OWNERS
├── OWNERS_ALIASES
├── README.md
├── SECURITY.md
├── SECURITY_CONTACTS
├── cna-handbook.md
├── code-of-conduct.md
├── comms-templates/
│ ├── clickjacking-response.md
│ ├── container-vuln-response.md
│ ├── distributors-announcement-email.md
│ ├── distributors-removal-email.md
│ ├── non-vuln-response.md
│ ├── spf-record-response.md
│ ├── vulnerability-announcement-email.md
│ ├── vulnerability-announcement-issue.md
│ ├── vulnerability-announcement-placeholder-issue.md
│ └── vulnerability-announcement-slack.md
├── cve-requests.md
├── emeritus.md
├── playbook/
│ └── token-leak-process.md
├── private-distributors-list.md
├── security-release-process.md
├── severity-ratings.md
├── src-onboarding-offboarding.md
├── src-oncall.md
└── tools/
└── patchformat.py
================================================
FILE CONTENTS
================================================
================================================
FILE: .github/ISSUE_TEMPLATE/distributors-application.md
================================================
---
name: Distributors Application
title: Distributors Application for <YOUR DISTRIBUTION HERE>
about: Apply for memborship of distributors-announce@kubernetes.io
---
<!--
Please answer the following questions and provide supporting evidence for
meeting the membership criteria.
-->
**Actively monitored security email alias for our project:**
**1. Be an actively maintained and CNCF certified distribution of Kubernetes components.**
**2. Have a user base not limited to your own organization.**
**3. Have a publicly verifiable track record up to present day of fixing security issues.**
**4. Not be a downstream or rebuild of another distribution.**
**5. Be a participant and active contributor in the community.**
**6. Accept the Embargo Policy.**
<!-- https://github.com/kubernetes/security/blob/master/private-distributors-list.md#embargo-policy -->
**7. Be willing to contribute back.**
<!-- Per https://github.com/kubernetes/security/blob/master/private-distributors-list.md#contributing-back -->
**8. Have someone already on the list vouch for the person requesting membership on behalf of your distribution.**
================================================
FILE: CONTRIBUTING.md
================================================
# Contributing Guidelines
Welcome to Kubernetes. We are excited about the prospect of you joining our [community](https://git.k8s.io/community)! The Kubernetes community abides by the CNCF [code of conduct](code-of-conduct.md). Here is an excerpt:
_As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities._
## Getting Started
We have full documentation on how to get started contributing here:
<!---
If your repo has certain guidelines for contribution, put them here ahead of the general k8s resources
-->
- [Contributor License Agreement](https://git.k8s.io/community/CLA.md) Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests
- [Kubernetes Contributor Guide](https://git.k8s.io/community/contributors/guide) - Main contributor documentation, or you can just jump directly to the [contributing section](https://git.k8s.io/community/contributors/guide#contributing)
- [Contributor Cheat Sheet](https://git.k8s.io/community/contributors/guide/contributor-cheatsheet) - Common resources for existing developers
## Mentorship
- [Mentoring Initiatives](https://git.k8s.io/community/mentoring) - We have a diverse set of mentorship programs available that are always looking for volunteers!
## Contact Information
- [Mailing list](https://groups.google.com/forum/#!forum/kubernetes-security-discuss)
================================================
FILE: LICENSE
================================================
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
APPENDIX: How to apply the Apache License to your work.
To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets "{}"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same "printed page" as the copyright notice for easier
identification within third-party archives.
Copyright {yyyy} {name of copyright owner}
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
================================================
FILE: OWNERS
================================================
# See the OWNERS docs at https://go.k8s.io/owners
approvers:
- committee-security-response
labels:
- committee/security-response
================================================
FILE: OWNERS_ALIASES
================================================
# See the OWNERS_ALIASES docs at https://go.k8s.io/owners#owners_aliases
aliases:
committee-security-response:
- cjcullen
- enj
- joelsmith
- micahhausler
- natherz97
- puerco
- stlaz
- tabbysable
- vinayakankugoyal
- Vyom-Yadav
================================================
FILE: README.md
================================================
# Security
Kubernetes Security Release Process and Security Committee documentation.
To report a vulnerability, please refer to https://kubernetes.io/security.
## Security Response Committee (SRC)
The Security Response Committee (SRC) is responsible for triaging and handling the security issues for Kubernetes. Following are the current Security Response Committee members:
- Adolfo García Veytia (**[@puerco](https://github.com/puerco)**) `<adolfo.garcia@uservers.net>`
- CJ Cullen (**[@cjcullen](https://github.com/cjcullen)**) `<cjcullen@google.com>`
- Joel Smith (**[@joelsmith](https://github.com/joelsmith)**) `<joelsmith@redhat.com>` [4096R/0x1688ADC79BECDDAF]
- Micah Hausler (**[@micahhausler](https://github.com/micahhausler)**) `<mhausler@amazon.com>`
- Mo Khan (**[@enj](https://github.com/enj)**) `<i@monis.app>`
- Nathan Herz (**[@natherz97](https://github.com/natherz97)**) `<nathan.herz97@gmail.com>`
- Standa Láznička (**[@stlaz](https://github.com/stlaz)**) `<slznika@microsoft.com>`
- Tabitha Sable (**[@tabbysable](https://github.com/tabbysable)**) `<tabitha.c.sable@gmail.com>`
- Vinayak Goyal (**[@vinayakankugoyal](https://github.com/vinayakankugoyal)**) `<vinayakankugoyal@gmail.com>`
- Vyom Yadav (**[@Vyom-Yadav](https://github.com/Vyom-Yadav)**) `<vyom.yadav@canonical.com>`
### Contacting the SRC
There are a number of contact points for the SRC and release managers in charge of security releases. Please use the correct forum for the best and fastest response.
| List or Group | Visibility | Uses |
| ------------- | ---------- | ---- |
| security@kubernetes.io | Private | Kubernetes security disclosures. This list is closely monitored and triaged by the SRC. [See the disclosure guide for full details.](http://kubernetes.io/security) |
| [kubernetes-security-discuss Google Group](https://groups.google.com/forum/#!forum/kubernetes-security-discuss) | Public | Discussion about security disclosure handling, this document, and other updates. |
| release-managers-private@kubernetes.io | Private | Release Managers private discussion. All members are subscribed to security@kubernetes.io. |
| security-discuss-private@kubernetes.io | Private | SRC private discussion. All members are subscribed to security@kubernetes.io |
## Community, discussion, contribution, and support
Learn how to engage with the Kubernetes community on the [community page](http://kubernetes.io/community/).
### Code of conduct
Participation in the Kubernetes community is governed by the [Kubernetes Code of Conduct](code-of-conduct.md).
================================================
FILE: SECURITY.md
================================================
# Security Policy
## Security Announcements
Join the [kubernetes-security-announce] group for security and vulnerability announcements.
You can also subscribe to an RSS feed of the above using [this link][kubernetes-security-announce-rss].
## Reporting a Vulnerability
Instructions for reporting a vulnerability can be found on the
[Kubernetes Security and Disclosure Information] page.
## Supported Versions
Information about supported Kubernetes versions can be found on the
[Kubernetes version and version skew support policy] page on the Kubernetes website.
[kubernetes-security-announce]: https://groups.google.com/forum/#!forum/kubernetes-security-announce
[kubernetes-security-announce-rss]: https://groups.google.com/forum/feed/kubernetes-security-announce/msgs/rss_v2_0.xml?num=50
[Kubernetes version and version skew support policy]: https://kubernetes.io/docs/setup/release/version-skew-policy/#supported-versions
[Kubernetes Security and Disclosure Information]: https://kubernetes.io/docs/reference/issues-security/security/#report-a-vulnerability
================================================
FILE: SECURITY_CONTACTS
================================================
# Defined below are the security contacts for this repo.
#
# They are the contact point for the Security Response Committee to reach out
# to for triaging and handling of incoming issues.
#
# Yes, this is absurd because this repo is for use by the Security Response
# Committee, and as a tautology, we know how to contact ourselves. Creating
# this file avoids the need to special-case our own repos in the bot.
#
# The below names agree to abide by the
# [Embargo Policy](https://git.k8s.io/security/private-distributors-list.md#embargo-policy)
# and will be removed and replaced if they violate that agreement.
#
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE
# INSTRUCTIONS AT https://kubernetes.io/security/
committee-security-response
================================================
FILE: cna-handbook.md
================================================
# CVE Numbering Authority tasks
<!-- toc -->
- [CVE Numbering Authority tasks](#cve-numbering-authority-tasks)
- [CNA-trained Security Response Committee members](#cna-trained-security-response-committee-members)
- [References](#references)
- [Common CNA tasks](#common-cna-tasks)
- [Track CVE ID status](#track-cve-id-status)
- [Requesting CVE IDs](#requesting-cve-ids)
- [cvelib](#cvelib)
- [Setup](#setup)
- [User admin](#user-admin)
- [Assign a CVE ID to vulnerability](#assign-a-cve-id-to-vulnerability)
- [Populate CVE details](#populate-cve-details)
- [Reject unused CVEs](#reject-unused-cves)
- [Uncommon tasks](#uncommon-tasks)
- [Splitting, merging, amending CVEs](#splitting-merging-amending-cves)
<!-- /toc -->
## CNA-trained Security Response Committee members
The following members of the Security Response Committee have completed CNA training and can request/assign/publish CVEs for the Kubernetes CNA:
- CJ Cullen (**[@cjcullen](https://github.com/cjcullen)**) `<cjcullen@google.com>`
- Joel Smith (**[@joelsmith](https://github.com/joelsmith)**) `<joelsmith@redhat.com>`
- Micah Hausler (**[@micahhausler](https://github.com/micahhausler)**) `<mhausler@amazon.com>`
- Mo Khan (**[@enj](https://github.com/enj)**) `<i@monis.app>`
- Sri Saran Balaji (**[@SaranBalaji90](https://github.com/SaranBalaji90)**) `<srajakum@amazon.com>`
- Tabitha Sable (**[@tabbysable](https://github.com/tabbysable)**) `<tabitha.c.sable@gmail.com>`
## References
CNA documents are hosted by MITRE at https://cve.mitre.org/about/documents.html#cna, notably:
* CNA onboarding guides: https://cveproject.github.io/docs/cna/onboarding/index.html
* Also available in video form: https://www.youtube.com/playlist?list=PLWfD9RQVdJ6c4eMkdqbOKqF7zPCqXkgX3
* CNA Rules: https://www.cve.org/ResourcesSupport/AllResources/CNARules
A walkthrough of this handbook is also available in [video form](https://youtu.be/pcmAaEP7HD4).
## Common CNA tasks
### Track CVE ID status
As of 2022, CVE IDs are dynamcally reserved from MITRE's CVE API. CNA-trained SRC members can use an open-source CLI to reserve new CVE IDs as they are needed. Newly reserved CVE IDs and those previously allocated the Kubernetes project are accessible to the Security Response Committee [here](https://docs.google.com/spreadsheets/d/178eqxFxShR0I2BeoZ-YUynYnl0fo_0oU0VfmVfBpAQ0/edit)
### Requesting CVE IDs
If a new CVE ID is needed to assign to a new issue, and reserved IDs for the current year are exhausted, you can use the command line client [cvelib][cvelib].
[cvelib]: https://github.com/RedHatProductSecurity/cvelib
Once the CVE ID is received, add it to the [tracking sheet] as unassigned IDs for future assignment.
### cvelib
#### Setup
If you want to run cvelib in a container, use the following
```bash
# Don't quote the values
echo << EOF > env.txt
CVE_USER=${YOUR_EMAIL}
CVE_ORG=kubernetes
CVE_API_KEY=${YOUR_API_KEY}
EOF
cat << EOF > Dockerfile
FROM python:3-slim
RUN pip install cvelib
ENTRYPOINT ["/usr/local/bin/cve"]
EOF
docker build -t $USER/cvelib:latest .
docker run --env-file=env.txt -it --rm $USER/cvelib:latest
```
By not specifying any arguments, the help output will be displayed. You can then explore the various sub arguments in the CLI. To see the arguments for reserving a single CVE, you can run the following command:
```bash
docker run --env-file=env.txt -it --rm $USER/cvelib:latest reserve -h
```
#### User admin
To see help output on resetting your own API key, you can run the following command:
```bash
docker run --env-file=env.txt -it --rm $USER/cvelib:latest user reset-key -h
```
To see help output on creating a new CNA admin user, you can run the following command:
```bash
docker run --env-file=env.txt -it --rm $USER/cvelib:latest user create -h
```
### Assign a CVE ID to the vulnerability
When a vulnerability report is received, follow the [CNA decision tree](https://cve.mitre.org/cve/cna/rules.html#Appendix_C)
to determine if this is a valid vulnerability, in scope for the Kubernetes CNA, that has not yet been assigned a CVE ID,
and if so, how many distinct vulnerabilities exist in the report.
If a reserved ID is not available, run the following to reserve a new CVE ID or a batch of IDs:
```bash
docker run --env-file=env.txt -it --rm $USER/cvelib:latest reserve -h
```
Assign a reserved ID to the issue, and add at least the following information in the [tracking sheet]:
* Date reserved
* Description
* Link to the tracking issue in https://github.com/kubernetes-security/security-disclosures/issues (created as part of [on-call workflow](src-oncall.md#incident-response-workflow))
### Populate CVE Details after Public Disclosure
1. Ensure there is a Kubernetes github issue labeled `area/security` whose title contains the CVE ID.
This will appear in the issue query linked from https://kubernetes.io/cve.
1. Once a vulnerability is made public, populate the CVE details in https://github.com/CVEProject/cvelist. This should be done as soon as reasonably possible after the vulnerability is made public (ideally, O(days)).
1. Generate the CVElist json file
* See https://github.com/CVEProject/cvelist/blob/master/2023/2xxx/CVE-2023-2727.json as an example.
* https://vulnogram.github.io/#editor is a useful tool for generating the CVE details, but should only be used once the vulnerability has been made public.
Fill in or update the relevant fields, including:
* State: `PUBLIC`
* Assigner: `security@kubernetes.io`
* Affects: List historical minor versions affected and "prior to 1.x.y" patch versions affected
* Credits: The vulnerability reporter's name
* Description: `The Kubernetes <component> command/component in versions <affected versions> <vulnerability>`
* Impact: CVSS impact
* Problem type: Select a problem type from https://cwe.mitre.org/data/definitions/699.html if applicable
* References: Link to the Kubernetes github issue(s) (with type `issue-tracking`) and mailing list announcement (with type `mailing-list`)
* Source: Link to the Kubernetes github issue(s) and indicate if it was discovered internally or externally
* Work around: indicate workaround steps, if applicable
1. Once the cvelist json file is generated, request a review from a CNA-approved SRC member.
1. Once the json file is reviewed, a CNA approved member should run the following to push the update
```bash
docker run --env-file=env.txt -v ${PWD}/CVE-xxxx-xxxx.json:/tmp/CVE-xxxx-xxxx.json -it --rm $USER/cvelib:latest publish CVE-xxxx-xxxx -f /tmp/CVE-xxxx-xxxx.json
```
1. Once the cvelist json file in https://github.com/CVEProject/cvelist is updated, indicate in the [tracking sheet] that the CVE has been populated.
### Reject unused CVEs
Once a calendar year has completed, all untriaged reports from that year have been resolved,
and no new CVE assignments for that year will be made, update any reserved but unassigned CVE IDs
for that calendar year to indicate they were rejected and unused.
1. Run the following:
```bash
docker run --env-file=env.txt -it --rm $USER/cvelib:latest reject -h
```
1. Update the [tracking sheet] to indicate those CVEs were rejected (see CVE-2019-11256 through CVE-2019-11267 as an example)
## Uncommon tasks
### Splitting, merging, amending CVEs
This is rarely required, but if later inspection reveals a single CVE was actually two separate vulnerabilities, or two separate CVEs were actually a single vulnerability, CVEs can be split or merged following the process described at https://cve.mitre.org/cve/cna/rules.html#Appendix_E
[tracking sheet]: https://github.com/kubernetes-security/security-disclosures#cna-tracker
================================================
FILE: code-of-conduct.md
================================================
# Kubernetes Community Code of Conduct
Please refer to our [Kubernetes Community Code of Conduct](https://git.k8s.io/community/code-of-conduct.md)
================================================
FILE: comms-templates/clickjacking-response.md
================================================
Thank you for your interest in helping improve the security of Kubernetes.
The public Kubernetes website is a read-only resource that does not collect or process any personal information, and as such, we do not believe that clickjacking is a threat to the project or its users. If you believe you have discovered a particular instance in which clickjacking can be used to harm a user or the project, please supply additional details.
Thank you,
The Kubernetes Security Response Committee
================================================
FILE: comms-templates/container-vuln-response.md
================================================
Thank you for your message.
Because these are public CVEs, please use one of these public options instead:
- kubernetes-security-discuss@googlegroups.com
- open an issue: http://issues.k8s.io/new/choose
- #kubernetes-security slack channel: http://slack.k8s.io/
Thank you,
The Kubernetes Security Response Committee
================================================
FILE: comms-templates/distributors-announcement-email.md
================================================
_Use this email template for pre-disclosing security vulnerabilities to distributors-announce._
_Note that distributors-announce@kubernetes.io has moderation enabled. When you send the email, remember to release the email from moderation queue._
TO: `distributors-announce@kubernetes.io`
SUBJECT: `[EMBARGOED] $CVE: $SUMMARY`
---
### EMBARGOED
The information contained in this email is **[under embargo](https://github.com/kubernetes/security/blob/master/private-distributors-list.md#embargo-policy)** until the public disclosure is sent. The disclosure is scheduled to be sent on $DATE at or after 9AM PT.
_Additional details on the embargo conditions._
- _If a patch is provided, can it be deployed?_
- _Is the patch itself under embargo?_
### Issue Details
A security issue was discovered in Kubernetes where $ACTOR may be able to $DO_SOMETHING. <optional> Kubernetes clusters are only affected if $CONDITION </end optional>
This issue has been rated **$SEVERITY** (link to CVSS calculator https://www.first.org/cvss/calculator/3.1) (optional: $SCORE), and assigned **$CVE_NUMBER**
_Additional background and high level description of the vulnerability._
### Affected Components and Configurations
_How to determine if a cluster is impacted. Include:_
- _Vulnerable configuration details_
- _Commands that indicate whether a component, version or configuration is used_
#### Affected Versions
- $COMPONENT $VERSION_RANGE_1
- $COMPONENT $VERSION_RANGE_2 ...
- ...
### Mitigations
_If a patch is provided, describe it here._
_(If fix has side effects)_ **Fix impact:** details of impact.
_(If additional steps required after upgrade)_
**ACTION REQUIRED:** The following steps must be taken to mitigate this
vulnerability: ...
_(If possible):_ Prior to upgrading, this vulnerability can be mitigated by ...
### Detection
_How can exploitation of this vulnerability be detected?_
If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io
Thank You,
$PERSON on behalf of the Kubernetes Security Response Committee
================================================
FILE: comms-templates/distributors-removal-email.md
================================================
TO: `$MEMBER_EMAIL`
CC: `security-discuss-private@kubernetes.io`
SUBJECT: `Kubernetes Disclosure List Removal Due to Uncertified Status`
---
Hello $MEMBER-
The [Kubernetes Security Response Committee][psc] has removed $EMAIL from the distributors-announce@kubernetes.io Google Group.
This is because $PRODUCT is no longer a [certified Kubernetes Distribution][conformance], a requirement for membership to this list.
If $PRODUCT recertifies, and meets all other criteria, please submit a [request to re-join using the normal process][join-process].
Thank You,
$PERSON on behalf of the Kubernetes Security Response Committee
[src]: https://git.k8s.io/security/security-release-process.md#security-response-committee-src
[conformance]: https://www.cncf.io/certification/software-conformance/
[criteria]: https://git.k8s.io/security/private-distributors-list.md#membership-criteria
[join-process]: https://git.k8s.io/security/private-distributors-list.md#request-to-join
================================================
FILE: comms-templates/non-vuln-response.md
================================================
Thank you for your message.
It appears this report is neither a vulnerability report nor a security incident. Consider one of these public options instead:
- kubernetes-security-discuss@googlegroups.com
- open an issue: http://issues.k8s.io/new/choose
- #kubernetes-security slack channel: http://slack.k8s.io/
Thank you,
The Kubernetes Security Response Committee
================================================
FILE: comms-templates/spf-record-response.md
================================================
Thank you for your interest in helping improve the security of Kubernetes.
Kubernetes is an open-source project, and does not have customers or regularly send emails from the kubernetes.io domain. As such, we do not believe that the current configuration of our SPF record poses a threat to the project or its users. If you believe you have discovered a particular instance in which the configuration of our SPF record can be used to harm a specific user or the project, please supply additional details.
Thank you,
The Kubernetes Security Response Committee
================================================
FILE: comms-templates/vulnerability-announcement-email.md
================================================
_Use this email template for publicly disclosing security vulnerabilities._
_The email should be **concise** and **actionable**. Assume the audience are not
Kubernetes developers. Non-actionable information (e.g. technical discussion of
the vulnerability) should be deferred to the [vulnerability
issue](vulnerability-announcement-issue.md)._
TO: `kubernetes-announce@googlegroups.com, dev@kubernetes.io, kubernetes-security-announce@googlegroups.com, kubernetes-security-discuss@googlegroups.com, distributors-announce@kubernetes.io`
SUBJECT: `[Security Advisory] $CVE: $SUMMARY`
_A separate email should be sent for `oss-security@lists.openwall.com`, with `[kubernetes]` in the subject:_
TO: `oss-security@lists.openwall.com`
SUBJECT: `[kubernetes] $CVE: $SUMMARY`
_A separate email should be sent to the forum from the `security@kubernetes.io` Google group and cc `kubernetes+announcements@discoursemail.com`:_
TO: `security@kubernetes.io`
cc: `kubernetes+announcements@discoursemail.com`
SUBJECT: `[Security Advisory] $CVE: $SUMMARY`
_See [Fix disclosure process](security-release-process.md#fix-disclosure-process) for additional places the announcement should be posted._
---
Hello Kubernetes Community,
A security issue was discovered in Kubernetes where $ACTOR may be able to $DO_SOMETHING.
This issue has been rated **$SEVERITY** (link to CVSS calculator https://www.first.org/cvss/calculator/3.1) (optional: $SCORE), and assigned **$CVE_NUMBER**
### Am I vulnerable?
_How to determine if a cluster is impacted. Include:_
- _Vulnerable configuration details_
- _Commands that indicate whether a component, version or configuration is used_
#### Affected Versions
- $COMPONENT $VERSION_RANGE_1
- $COMPONENT $VERSION_RANGE_2 ...
- ...
### How do I mitigate this vulnerability?
_(If additional steps required after upgrade)_
**ACTION REQUIRED:** The following steps must be taken to mitigate this vulnerability: ...
_(If possible):_ Prior to upgrading, this vulnerability can be mitigated by ...
#### Fixed Versions
- $COMPONENT $VERSION
- $COMPONENT $VERSION
- ...
_(If fix has side effects)_ **Fix impact:** details of impact.
To upgrade, refer to the documentation: ... ($COMPONENT upgrade documentation)
_For core Kubernetes:_ https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/
### Detection
_How can exploitation of this vulnerability be detected?_
If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io
#### Additional Details
See the GitHub issue for more details: $GITHUBISSUEURL
#### Acknowledgements
This vulnerability was reported by $REPORTER.
_(optional):_ The issue was fixed and coordinated by $FIXTEAM and $RELEASE_MANAGERS.
Thank You,
$PERSON on behalf of the Kubernetes Security Response Committee
================================================
FILE: comms-templates/vulnerability-announcement-issue.md
================================================
_Use this issue template for filling out CVE placeholder issues._
TITLE: `CVE-####-######: $SUMMARY`
---
<!-- Copy URL after # as the link text -->
CVSS Rating: [CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L)
_Description of vulnerability_
<!-- Copy these sections from the announcement email -->
### Am I vulnerable?
_How to determine if a cluster is impacted. Include:_
- _Vulnerable configuration details_
- _Commands that indicate whether a component, version or configuration is used_
#### Affected Versions
- $COMPONENT $VERSION_RANGE_1
- $COMPONENT $VERSION_RANGE_2 ...
- ...
### How do I mitigate this vulnerability?
_(If additional steps required after upgrade)_
**ACTION REQUIRED:** The following steps must be taken to mitigate this
vulnerability: ...
_(If possible):_ Prior to upgrading, this vulnerability can be mitigated by ...
#### Fixed Versions
<!-- Add links to PRs & main/master branch -->
- $COMPONENT main/master - fixed by #12345678
- ...
_(If fix has side effects)_ **Fix impact:** details of impact.
To upgrade, refer to the documentation: ... ($COMPONENT upgrade documentation)
_For core Kubernetes:_ https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade
### Detection
_How can exploitation of this vulnerability be detected?_
If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io
## Additional Details
_Optional details:_
- Vulnerability background
- Technical explanation of vulnerability and/or fix
- Reproduction steps (avoid disclosing unnecessary details)
#### Acknowledgements
This vulnerability was reported by $REPORTER.
_(optional):_ The issue was fixed and coordinated by $FIXTEAM and $RELEASE_MANAGERS.
<!-- labels -->
/area security
/kind bug
/committee security-response
/label official-cve-feed
/sig $RELEVANT_SIGS
/area $IMPACTED_COMPONENTS
================================================
FILE: comms-templates/vulnerability-announcement-placeholder-issue.md
================================================
_Use this issue template for filing CVE placeholder issues._
TITLE: PLACEHOLDER ISSUE
---
/triage accepted
/lifecycle frozen
/area security
/kind bug
/committee security-response
================================================
FILE: comms-templates/vulnerability-announcement-slack.md
================================================
_Use this slack message template for publicly disclosing security vulnerabilities on slack._
_This message should be posted to the `#announcements` channel, which requires special permissions._
---
The Security Response Committee has posted a security advisory for $COMPONENT that $SUMMARY. This
issue has been rated **$SEVERITY** and assigned **$CVE**. Please see $ISSUE for more details.
---
_Example_
The Security Response Committee has posted a security advisory for the kube-apiserver that could
allow node updates to bypass a Validating Admission Webhook. This issue has been rated **Medium**
and assigned **CVE-2021-25735**. Please see https://github.com/kubernetes/kubernetes/issues/100096
for more details.
================================================
FILE: cve-requests.md
================================================
# CVE Number Requests
The Kubernetes project is a registered [CVE Numbering Authority](http://cve.mitre.org/cve/request_id.html#k) (CNA) with MITRE.
Requests for CVE numbers for components residing within https://github.com/kubernetes/kubernetes
should be directed to [security@kubernetes.io](mailto:security@kubernetes.io).
CVE numbers are typically requested by the fix lead for a particular issue as part of the [security release process](security-release-process.md).
================================================
FILE: emeritus.md
================================================
Emeritus committee members:
- Brandon Philips (**[@philips](https://github.com/philips)**) `<bphilips@redhat.com>`
- Jess Frazelle (**[@jessfraz](https://github.com/jessfraz)**) `<jess@linux.com>`
- Jonathan Pulsifer (**[@jonpulsifer](https://github.com/jonpulsifer)**) `<jonathan.pulsifer@shopify.com>`
- Jordan Liggitt (**[@liggitt](https://github.com/liggitt)**) `<jordan@liggitt.net>` [4096R/0x39928704103C7229]
- Swamy Shivaganga Nagaraju (**[@swamymsft](https://github.com/swamymsft)**) `<gaswamy@microsoft.com>`
- Tim Allclair (**[@tallclair](https://github.com/tallclair)**) `<timallclair@gmail.com>`
- Luke Hinds (**[@lukehinds](https://github.com/lukehinds)**) `lhinds@protonmail.com`
- Sri Saran Balaji (**[@SaranBalaji90](https://github.com/SaranBalaji90)**) `<srajakum@amazon.com>`
- Craig Ingram (**[@cji](https://github.com/cji)**) `<cji@linux.com>`
- Rita Zhang (**[@ritazh](https://github.com/ritazh)**) `<ritazh@microsoft.com>`
================================================
FILE: playbook/token-leak-process.md
================================================
# GitHub Token Leak Response Process
The SRC may become aware that a Kubernetes Org member has leaked a GitHub token. Because Org membership can confer privileges, it is important to ensure leaked GitHub tokens are revoked. This process describes how to do so.
## Investigate
* Thank the reporter -- they have done us a kindness by letting us know about the problem
* If you can, get the first few characters of the leaked token in case GitHub support needs it for revocation
* Check to see if the user is an OWNER - an OWNER token leak would be more severe than that of an ordinary Org member
* https://cs.k8s.io/?i=fosho&files=OWNERS&q=the-user-name-goes-here
## Contact
* Contact the user via email if possible, letting them know about the token leak. You can usually get an email from their GitHub profile or recent commits to Kubernetes.
>Dear `USER`,
>
>We were recently notified that a personal GitHub token has been leaked (say a little about how the token was leaked, if possible. e.g. "via CI logs visible on https://example.net/ci-logs").
>
>Please revoke the leaked GitHub token, to protect yourself and your projects. Let us know if you need any further information.
>
>Best,
>
>`YOUR NAME HERE`
>Kubernetes SRC
* If the user is an OWNER or might have other privileged roles in the project, contact a ContribEx chair or Steering to discuss whether further incident response is needed
* Contact a Kubernetes GitHub org adminstrator (ask for one to DM you in #sig-contribex on Slack). Have them submit a support ticket asking for the token to be revoked. They should cc Kubernetes's contacts at GitHub, who will escalate with the term “3rd party revocation”
## Followup
* Perform any necessary incident response as identified with the SRC, ContribEx, and Steering
================================================
FILE: private-distributors-list.md
================================================
## Private Distributors List
This list is used to provide actionable information to multiple distribution
vendors at once. This list is not intended for individuals to find out about
security issues.
### Embargo Policy
The patch files and any derived patched binaries are included in the embargo,
and must not be distributed or made available to external parties before the
public disclosure is made.
However, a fully-hosted patched kube-apiserver can be deployed
prior to the embargo lift date if users do not have direct access to the binary and if the patch only applies to the kube-apiserver.
Other fully-hosted patched components can also be deployed prior to the embargo
lift date only if all users with access to the components and/or
clusters are internal to the Kubernetes distributor.
Members of distributors-announce@kubernetes.io must share list information only
within their teams, on a need-to-know basis to get the related issue fixed in
their distribution. The information members and others receive from the list
must not be made public, shared, nor even hinted at otherwise, except with the
list's explicit approval. This holds true until the public disclosure date/time
that was agreed upon by the list.
Before any information from the list is shared with respective members of your
team required to fix an issue, they must agree to the same terms and only
find out information on a need-to-know basis.
As a clarifying example, this policy forbids SRC members (or others who don't
work on a distribution) from sharing list information with their non-distributor
employers.
In the unfortunate event you share the information beyond what is allowed by
this policy, you _must_ urgently inform the security@kubernetes.io mailing list
of exactly what information leaked and to whom, as well as the steps that will
be taken to prevent future leaks.
Repeated offenses may lead to the removal from the distributors list.
### Contributing Back
This is a team effort. As a member of the list you must carry some water. This
could be in the form of the following:
- Review and/or test the proposed patches and point out potential issues with
them (such as incomplete fixes for the originally reported issues, additional
issues you might notice, and newly introduced bugs), and inform the list of the
work done even if no issues were encountered.
### Membership
Group membership is managed through the Kubernetes domain group administration
configuration: http://git.k8s.io/k8s.io/groups/committee-security-response/groups.yaml,
under the `distributors-announce` section.
### Membership Criteria
To be eligible for the distributors-announce@kubernetes.io mailing list, your
distribution should:
0. Have an actively monitored security email alias for our project.
1. Be an actively maintained and [CNCF certified distribution of
Kubernetes][conformance] components.
2. Have a user base not limited to your own organization.
3. Have a publicly verifiable track record up to present day of fixing security
issues.
4. Not be a downstream or rebuild of another distribution.
5. Be a participant and active contributor in the community.
6. Accept the [Embargo Policy](#embargo-policy) that is outlined above.
7. Be willing to [contribute back](#contributing-back) as outlined above.
8. Have someone already on the list vouch for the person requesting membership
on behalf of your distribution.
[conformance]: https://www.cncf.io/certification/software-conformance/
**Removal**: If your distribution stops meeting one or more of these criteria
after joining the list then you will be unsubscribed.
### Request to Join
File an issue
[here](https://github.com/kubernetes/security/issues/new?template=distributors-application.md),
filling in the criteria template.
================================================
FILE: security-release-process.md
================================================
# Security Release Process
Kubernetes is a large growing community of volunteers, users, and vendors. The Kubernetes community has adopted this security disclosures and response policy to ensure we responsibly handle critical issues.
<!-- toc -->
- [Security Response Committee (SRC)](#security-response-committee-src)
- [Security Response Committee Membership](#security-response-committee-membership)
- [Nomination](#nomination)
- [Member selection](#member-selection)
- [Stepping Down](#stepping-down)
- [Responsibilities](#responsibilities)
- [Incident Commander](#incident-commander)
- [Triage](#triage)
- [SIG Release Roles](#sig-release-roles)
- [Disclosures](#disclosures)
- [Private Disclosure Processes](#private-disclosure-processes)
- [Public Disclosure Processes](#public-disclosure-processes)
- [Patch, Release, and Public Communication](#patch-release-and-public-communication)
- [Fix Team Organization](#fix-team-organization)
- [Fix Development Process](#fix-development-process)
- [Fix Disclosure Process](#fix-disclosure-process)
- [Private Distributors List](#private-distributors-list)
- [Retrospective](#retrospective)
- [Severity](#severity)
- [Severity Thresholds - How We Do Vulnerability Scoring](#severity-thresholds---how-we-do-vulnerability-scoring)
<!-- /toc -->
## Security Response Committee (SRC)
Security vulnerabilities should be handled quickly and sometimes privately. The primary goal of this process is to reduce the total time users are vulnerable to publicly known exploits.
The [Security Response Committee (SRC)](README.md#security-response-committee-src) is responsible for organizing the entire response including internal communication and external disclosure but will need help from relevant developers and release managers to successfully run this process.
### Security Response Committee Membership
New SRC members are nominated by current SRC members, and selected by the
[steering committee](https://github.com/kubernetes/community/tree/master/committee-steering).
The SRC is currently capped at 10 members.
#### Nomination
New members are nominated to the SRC by current SRC members. If you are interested in joining the
SRC, the best way to secure a nomination is through sustained participation and contributions in the
Kubernetes security community.
To encourage diversity members will also abide by a 1/2 maximal representation from any one company at any time. If representation changes due to job shifts or mergers, then members are encouraged to grow the team or replace themselves through mentoring new members. Being overlimit should not continue for longer than 12 months to give time to identify and mentor new members.
A nomination should include:
1. Relevant credentials, including Kubernetes and security experience
2. Statement of support from the nominating SRC member(s): ~1-3 sentences of why this person is a good candidate.
3. Statement of intent from the nominee: ~1-3 sentences of why they want to join the committee and are a good fit.
In the event that an SRC member has concerns with a nomination, they should privately reach out to
the steering committee via steering-private@kubernetes.io.
Nominations will be collected into a private Google doc shared between the SRC and Steering.
Nominations may be reused for new openings, but in that case both the SRC member and nominee should
reconfirm (or update) their statements.
#### Member selection
After the nomination deadline is passed, nominations will be shared with the Steering Committee.
Steering is encouraged to discuss the nominations in the next private monthly meeting, and reach out
to the SRC with any questions.
The final selection is made by discussion & lazy consensus, with a fallback to a vote.
In the event that an individual is on both the SRC and Steering Committee, they will be expected to
excuse themselves from the steering discussion & selection process (but may submit SRC nominations).
#### Stepping Down
Members may step down at anytime, and may nominate a replacement when they do.
#### Responsibilities
- Members should remain active and responsive, and participate in the [oncall rotation](src-oncall.md).
- Members going on extended leave for up to 3 months (1-2 rotations) may pause their oncall duties, but should coordinate with other members to ensure the role is adequately staffed during the leave.
- Longer leaves of absense should be discussed on a case-by-case basis.
- Members of a role should remove any other members that have not communicated a leave of absence and either cannot be reached for more than 2 months or are not fulfilling their documented responsibilities for more than 2 months. This may be done through a super-majority vote of members.
New members are *not* expected to join the oncall rotation immediately, but are expected to start
learning the processes and ramping up. During that time, they are expected to complete a shadow and
reverse shadow rotation. The ramp-up time does not need to be formalized, but 2-3 months should be a
reasonable expectation.
##### Incident Commander
One of the primary responsibilities of the SRC is to coordinate incident response when a
vulnerability is discovered. The incident commander is responsible for coordinating all the
different parts of the security release process (but not handling all those responsibilities
themselves), and seeing the incident through to the end (or handing off).
The incident commander defaults to the current oncall, but may be handed off to other SRC or Kubernetes maintainers.
##### Triage
The current oncall is responsible for triaging incoming vulnerability reports (both through the bug
bounty and email). For more details on the triage process, see [oncall
workflow](SRC-oncall.md).
#### SIG Release Roles
Included on the [private Release Managers list](https://groups.google.com/a/kubernetes.io/forum/#!forum/release-managers-private)
are the following members:
- [Release Managers](https://github.com/kubernetes/website/blob/main/content/en/releases/release-managers.md#release-managers)
(manage build and release aspects when a security fix must be delivered)
- [SIG Release Chairs](https://github.com/kubernetes/website/blob/main/content/en/releases/release-managers.md#chairs)
It is the responsibility of the [SIG Release Chairs](https://github.com/kubernetes/website/blob/main/content/en/releases/release-managers.md#chairs)
to curate and maintain the various release role access controls across release cycles.
## Disclosures
### Private Disclosure Processes
The Kubernetes Community asks that all suspected vulnerabilities be privately and responsibly disclosed via the Private Disclosure process available at [https://kubernetes.io/security](https://kubernetes.io/security).
### Public Disclosure Processes
If you know of a publicly disclosed security vulnerability please IMMEDIATELY email [security@kubernetes.io](mailto:security@kubernetes.io) to inform the Security Response Committee (SRC) about the vulnerability so they may start the patch, release, and communication process.
If possible the SRC will ask the person making the public report if the issue can be handled via a private disclosure process. If the reporter denies the request, the SRC will move swiftly with the fix and release process. In extreme cases you can ask GitHub to delete the issue but this generally isn't necessary and is unlikely to make a public disclosure less damaging.
## Patch, Release, and Public Communication
For each vulnerability a member of the SRC will volunteer to lead coordination
with the Fix Team and Release Managers, and is responsible for sending disclosure
emails to the rest of the community. This lead will be referred to as the Fix Lead.
The role of Fix Lead should rotate round-robin across the SRC.
All of the timelines below are suggestions and assume a Private Disclosure.
The Fix Lead drives the schedule using their best judgment based on severity,
development time, and release manager feedback. If the Fix Lead is dealing with
a Public Disclosure all timelines become ASAP. If the fix relies on another
upstream project's disclosure timeline, that will adjust the process as well.
We will work with the upstream project to fit their timeline and best protect
our users.
### Fix Team Organization
These steps should be completed within the first 24 hours of Disclosure.
- The Fix Lead will work quickly to identify relevant engineers and release managers from the affected projects and packages and CC those engineers into the disclosure thread. This selected developers are the Fix Team. A best guess is to invite all assignees in the OWNERS file from the affected packages.
- The Fix Lead may get the Fix Team access to private security repos in the kubernetes-security GitHub org to develop the fix as required.
- The Fix Lead should start by sharing a quick overview of the entire security release process as outlined in the [Disclosures](#disclosures) section in this document.
Note: The kubernetes-security GitHub org is co-owned and viewable by the SRC and Kubernetes Release Managers. Management of the org is done by SIG Contributor Experience's [GitHub management subproject](https://git.k8s.io/community/github-management).
### Fix Development Process
These steps should be completed within the 1-7 days of Disclosure.
- The Fix Lead and the Fix Team will create a [CVSS](https://www.first.org/cvss/specification-document) score using the [CVSS Calculator](https://www.first.org/cvss/calculator/3.0). They will also use the [Severity Thresholds - How We Do Vulnerability Scoring](#severity-thresholds---how-we-do-vulnerability-scoring) to determine the effect and severity of the bug. The Fix Lead makes the final call on the calculated risk; it is better to move quickly than make the perfect assessment.
- The Fix Lead will [Assign a CVE ID to the vulnerability from the CVE Numbering Authority](/cna-handbook.md#assign-a-cve-id-to-the-vulnerability).
- The Fix Team will notify the Fix Lead that work on the fix branch is complete once there are LGTMs on all commits in the private repo from one or more relevant assignees in the relevant OWNERS file.
If the CVSS score is under ~4.0
([a low severity score](https://www.first.org/cvss/specification-document#i5))
or the assessed risk is low the Fix Team can decide to slow the release process
down in the face of holidays, developer bandwidth, etc. These decisions must be
discussed on the security@kubernetes.io mailing list.
If the CVSS score is under ~7.0 (a medium severity score), the Fix Lead may
choose to carry out the fix semi-publicly. This means that PRs are made directly
in the public kubernetes/kubernetes repo, while restricting discussion of the
security aspects to private channels. The fix lead will make the determination
whether there would be user harm in handling the fix publicly that outweighs the
benefits of open engagement with the community.
Critical and High severity vulnerability fixes will typically receive an out-of-band release. Medium and Low severity vulnerability fixes will be released as part of the next Kubernetes [patch release](https://github.com/kubernetes/website/blob/main/content/en/releases/patch-releases.md).
Note: CVSS is convenient but imperfect. Ultimately, the Fix Lead has discretion
on classifying the severity of a vulnerability.
No matter the CVSS score, if the vulnerability requires
[User Interaction](https://www.first.org/cvss/user-guide#5-4-User-Interaction),
especially in client components like kubectl, or otherwise has a
straightforward, non-disruptive mitigation, the Fix Lead may choose to disclose
the vulnerability before a fix is developed if they determine that users would
be better off being warned against a specific interaction.
### Low CVEs that can Skip Private Disclosures
Sometimes a Low CVE may not require private disclosures, Fix lead should facilitate:
- Code owner to submit public PR and cherrypick PRs any time before the next patch releases deadline. PRs should not mention the CVE, only the fix.
- BEFORE the next patch releases are out, Fix lead to provide the CVE feed yaml to the release team.
- AFTER the next patch releases are out, Fix lead to follow the `Communications process` listed below under "Fix Release Day" to open a public issue and make all the public announcements.
### Fix Disclosure Process
With the Fix Development underway the Fix Lead needs to come up with an overall communication plan for the wider community. This Disclosure process should begin after the Fix Team has developed a Fix or mitigation so that a realistic timeline can be communicated to users. Emergency releases for critical and high severity issues or fixes for issues already made public may affect the below timelines for how quickly or far in advance notifications will occur.
**Advance Vulnerability Disclosure to Private Distributors List** (Completed within 1-4 weeks prior to public disclosure):
- The [Private Distributors List](#private-distributors-list) will be given advance notification of any vulnerability that is assigned a CVE, at least 7 days before the planned public disclosure date. The notification will include all information that can be reasonably provided at the time of the notification. This may include patches or links to PRs, proofs of concept or instructions to reproduce the vulnerability, known mitigations, and timelines for public disclosure. When applicable, patches for all supported versions should be included. Distributors should read about the [Private Distributors List](#private-distributors-list) to find out the requirements for being added to this list.
- **What if a vendor breaks embargo?** The SRC will assess the damage. The Fix Lead will make the call to release earlier or continue with the plan. When in doubt push forward and go public ASAP.
**Fix Release Day**
Release process:
- The Fix Lead will cherry-pick the patches onto the master branch and all relevant release branches. The Fix Team will `/lgtm` and `/approve`.
- The Release Managers will merge these PRs as quickly as possible. Changes shouldn't be made to the commits at this point, to prevent potential conflicts with the patches sent to distributors, and conflicts as the fix is cherry-picked around branches.
- The Release Managers will ensure all the binaries are built, publicly available, and functional.
- The Fix Lead will remove the Fix Team from the private security repo once it is no longer needed.
Communications process:
- The [Private Distributors List](#private-distributors-list) will be notified at least 24 hours in
advance of a pending release containing security vulnerability fixes with the public messaging,
date, and time of the announcement.
- The Fix Lead will announce the new releases, the CVE number, severity, and impact, and the
location of the binaries to get wide distribution and user action. As much as possible this
announcement should be actionable, and include any mitigating steps users can take prior to
upgrading to a fixed version. The recommended target time is 4pm UTC on a non-Friday weekday. This
means the announcement will be seen morning Pacific, early evening Europe, and late evening Asia.
The announcement will be sent via the following channels:
- General announcement email ([template](comms-templates/vulnerability-announcement-email.md)) to
multiple Kubernetes lists
- OSS-Security announcement email
([template](comms-templates/vulnerability-announcement-email.md)) to
`oss-security@lists.openwall.com`
- `#announcements` slack channel ([template](comms-templates/vulnerability-announcement-slack.md))
- [discuss.kubernetes.io](https://discuss.kubernetes.io/c/announcements) forum (this should be
posted automatically using the general announcement email template)
- Tracking issue opened in https://github.com/kubernetes/kubernetes/issues
([template](comms-templates/vulnerability-announcement-issue.md)) and prefixed with the
associated CVE ID (if applicable). Add `/label official-cve-feed` so it will be part of https://kubernetes.io/docs/reference/issues-security/official-cve-feed/. Close the issue after the announcement is made.
- Once all communications are sent, fixes are released, and the CVE data has been populated, close out the public tracking issue.
- Medium and Low severity vulnerability fixes that will be released as part of the next Kubernetes
[patch release](https://github.com/kubernetes/website/blob/main/content/en/releases/patch-releases.md)
will have the fix details included in the patch release notes. Any public announcement sent for
these fixes will link to the release notes.
- For Kubernetes core components that are part of a Kubernetes release, provide the CVE feed yaml to the release team, https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/branch-manager.md#announcing-security-fixes
- After public disclosure, [populate CVE details as soon as possible](/cna-handbook.md#populate-cve-details-after-public-disclosure)
## Private Distributors List
This list is used to provide actionable information to multiple distribution
vendors at once.
See the [private distributor list doc](private-distributors-list.md) for more information.
## Retrospective
These steps should be completed 1-3 days after the Release Date. The retrospective process [should be blameless](https://landing.google.com/sre/book/chapters/postmortem-culture.html).
- The Fix Lead will send a retrospective of the process to kubernetes-dev@googlegroups.com including details on everyone involved, the timeline of the process, links to relevant PRs that introduced the issue, if relevant, and any critiques of the response and release process.
- The Release Managers and Fix Team are also encouraged to send their own feedback on the process to kubernetes-dev@googlegroups.com. Honest critique is the only way we are going to get good at this as a community.
## Severity
The Security Response Committee evaluates vulnerability severity on a case-by-case basis, guided by
[CVSS 3.1](https://www.first.org/cvss/v3.1/specification-document).
TODO(#147): Document a guide to how the SRC interprets CVSS for Kubernetes.
## Severity Thresholds - How We Do Vulnerability Scoring
Moved to [Severity Ratings](severity-ratings.md).
================================================
FILE: severity-ratings.md
================================================
# Severity Ratings
The Security Response Committee evaluates vulnerability severity on a case-by-case basis, guided by
[CVSS 3.1](https://www.first.org/cvss/v3.1/specification-document). If you have questions about why
a vulnerability is rated the way it is, please feel free to comment on the associated GitHub
tracking issue.
## Severity Thresholds - Heuristics
The content presented below outlines basic heuristics for considering the effect
of bugs disclosed to the Security Response Committee and their severity. These apply
mostly to items in "core" Kubernetes but could be abstractly applied to those in other
components as well.
### Server
The "server" pertains to any "server-side components" (see below) we distribute,
but you can specifically think of `kube-apiserver` and `kubelet` being the main ones.
"Server-side components" pertains to:
- Components built from source in the `kubernetes` github organization and
[all current organizations in use](https://git.k8s.io/community/github-management/README.md#actively-used-github-organizations)
- Container images under the `k8s.gcr.io` and `registry.k8s.io` repositories
- Containers included in the [core addons directory](https://git.k8s.io/kubernetes/cluster/addons)
The server classification is usually not appropriate when user interaction
is part of the exploitation process, those should fall under the
[client](#client) classifications as "client" implies user interaction with a
client.
If a "Critical" vulnerability exists only on server
components, and is exploited in a way that requires user interaction and results
in the compromise of the server, the severity may be reduced from "Critical" to
"High" in accordance with the data definition of extensive user
interaction presented at the start of the client severity pivot.
#### Critical
Network worms or _unavoidable_ cases where the server is "compromised."
##### Elevation of privilege
The ability to either execute arbitrary code or obtain more privilege than
authorized.
- [Remote Anonymous User](#remote-anonymous-user)
- Unauthorized access. Examples:
- read, write, or delete access to sensitive API objects
- arbitrary writing/deletion to the file system or anywhere in the
cluster that should not typically be modifiable
- getting data from the server or server components
- Execution of arbitrary code (remote code execution in the server)
This includes all write access violations.
##### Information disclosure (targeted)
Cases where an unprivileged user can locate and read highly sensitive
information from anywhere on the system, including system information that was
not intended or designed to be exposed.
- [Remote Anonymous User](#remote-anonymous-user)
- Unauthorized access. Examples:
- Personally identifiable information (PII) disclosure
(email addresses, cloud provider credentials)
- Attacker can collect private data without user consent or in a covert fashion
- Secrets data
- System credentials
#### High
"Critical" attacks are downgraded to "High" when requiring
[adjacent network access](#adjacent-network-access).
Non-default (or non-typical) critical scenarios or cases where
mitigations exist that can help prevent critical scenarios.
##### Denial of service
Must be "easy to exploit" by sending a small amount of data or be otherwise
quickly induced.
- [Remote Anonymous User](#remote-anonymous-user)
- Persistent DoS. Examples:
- Sending a single malicious request results in
[service failure](#service-failure)
- Sending a small number of requests that causes a
[service failure](#service-failure)
- Temporary DoS. Examples:
- Sending a small number of requests that causes the system to be
unusable for a period of time
- Server being down for a minute or longer
- A single remote client consuming all available resources
(sessions, memory) on a server by establishing sessions and keeping them open
- [Authenticated User](#authenticated-user)
- Persistent DoS against a [high value asset](#high-value-asset). Example:
- Sending a small number of requests that causes a
[service failure](#service-failure) for a
[high value asset](#high-value-asset)
##### Elevation of privilege
The ability to either execute arbitrary code or obtain more privilege than
authorized. This includes all write access violations.
- [Authenticated User](#authenticated-user)
- Unauthorized access. Examples:
- arbitrary writing to the file system or server components like etcd,
where the user should not have the ability to write
- reading or writing to API objects where the user should not be able
to
- getting data from the server or server components, where the user
should not have the ability to read
- execution of arbitrary code (like creating a pod or remote code execution
attacks)
Breaking or bypassing any security feature provided. A vulnerability in a
security feature is rated “High” by default, but the rating may be adjusted
based on other considerations as documented here.
Examples:
- Disabling or bypassing a `NetworkPolicy` or `PodSecurityPolicy` without
informing users or gaining consent
- Reconfiguring a `NetworkPolicy` and allowing connections to other processes
without consent
An entity (computer, server, user, process) is able to masquerade as a
specific entity (user or computer) of his/her choice.
Examples:
- Service masquerades as the API server for the cluster and effectively
man-in-the-middle's the real API server.
- API server uses client certificate authentication (SSL) improperly to allow
an attacker to be identified as any user of his/her choice
- RBAC bug that allows a malicious remote user to be seen as a different user
of his or her choice
##### Information disclosure (targeted)
Cases where an anonymous user can easily read sensitive information on the
system from specific locations, including system information that was not
intended/designed to be exposed.
Examples:
- Targeted disclosure of the existence of an arbitrary file
- Arbitrary filesystem or application data that should not typically be accessed
- Arbitrary API resources that should not typically be accessed
- Workload & namespace names or identifying metadata
- System & workload logs that are not typically exposed
- Workload or user-created metrics
#### Medium
"High" attacks are downgraded to "Medium" when requiring [local
access](#local-access) or when there is a straight-forward mitigation.
##### Information disclosure (targeted)
Cases where an anonymous user can easily read anonymous (non-sensitive)
information on the system, including system metrics that were not intended to be
exposed.
Examples:
- System metrics common to most Kubernetes installs that were not intended to be
public
- Non-identifying workload metadata (e.g. UIDs, creationTimestamps,
resourceVersions)
#### Low
"Medium" attacks are downgraded to "Low" when there is a straight-forward
mitigation and the attack requires quite a few non-default or very untypical
scenarios to trigger.
##### Tampering
Temporary modification of data in a specific scenario that does not persist.
### Client
"User interaction" can only happen in client-driven scenario.
Using `kubectl` or a client library are considered user interaction.
The target is a user or user's computer in these scenarios.
The effect of user interaction is not one level reduction in severity,
but is a reduction in severity in certain circumstances where user interaction
is required.
The distinction exists to help differentiate
fast-spreading and wormable attacks from those where because
the user interacts, the attack is slowed down.
#### Critical
Network worms or _unavoidable_ cases where the client is "compromised" without
warnings or prompts.
##### Elevation of privilege
The ability to either execute arbitrary code or obtain more privilege than
authorized. This includes all write access violations.
- [Remote Anonymous User](#remote-anonymous-user)
- Unauthorized access. Examples:
- read, write, and delete access to sensitive API objects
- arbitrary writing/reading/deletion to/from the file system
- Execution of arbitrary code (remote code execution on the client's system)
##### Information disclosure (targeted)
Cases where the attacker can locate and read information from anywhere on the
system, including system information that was not intended or designed to be
exposed.
- [Remote Anonymous User](#remote-anonymous-user)
- Unauthorized access. Examples:
- Personally identifiable information (PII) disclosure (email addresses, local data)
- Client "phone-ing home" without permission
#### High
Non-default critical scenarios or cases where mitigations exist that can help
prevent critical scenarios.
##### Denial of service
System corruption DoS requires re-installation of system and/or components.
Examples:
- Calling a `kubectl` command makes the local machine unbootable.
##### Elevation of privilege
The ability to either execute arbitrary code or obtain more privilege than
authorized. This includes all write access violations.
- [Authenticated User](#authenticated-user)
- Unauthorized access. Examples:
- arbitrary writing/deletion on the file system,
where the user should not have the ability to do so
- reading or writing to API objects where the user should not be able
to
- local low privilege user can elevate themselves to another user,
administrator, or local system.
- Execution of arbitrary code (remote code execution via the client)
Breaking or bypassing any security feature provided. A vulnerability in a
security feature is rated “High” by default, but the rating may be adjusted
based on other considerations as documented here.
Examples:
- Disabling or bypassing a RBAC without informing users or gaining consent
- Reconfiguring RBAC without consent
##### Tampering
Modification of any user data or data used to make trust decisions
in a common or default scenario where the modification persists.
This includes permanent or persistent modification of any user or system data
used in a common or default scenario.
Examples:
- Modification of application data files such as `~/.kube` in a specific
scenario
- Modification of cluster or objects without user consent in a specific scenario
#### Medium
##### Tampering
Modification of any user data or data used to make trust decisions
in a specific scenario where the modification persists.
This includes permanent or persistent modification of any user or system data
used in a specific scenario.
Examples:
- Modification of application data files such as `~/.kube` in a specific scenario
- Modification of cluster or objects without user consent in a specific scenario
#### Low
##### Denial of service
Temporary DoS requires restart of the client application.
Example:
- Running a `kubectl` command crashes itself or the API server in a way that is
recoverable.
##### Tampering
Temporary modification of data in a specific scenario that does not persist.
### Glossary
#### Adjacent Network Access
On the private network. They can access internal IP addresses.
#### Authenticated User
An authenticated user can be:
- Unprivileged: authenticated, but with no privileges
- Privileged: authenticated, with some privileges
#### Local Access
On the same physical host (or VM).
#### Remote Anonymous User
Remote implies from an arbitrary network location. The attacker can only access
externally exposed, public facing IP addresses.
Anonymous implies the attacker requires no credentials or Authentication.
#### High Value Asset
A mission critical component such that if/when it has failed the entire cluster
is unusable. For example, if the master services/nodes are
unreachable or in a failure mode, the entire cluster is basically unusable.
#### Service Failure
Failure in such a way that the system/service requires intervention from
a human operator to recover.
================================================
FILE: src-onboarding-offboarding.md
================================================
# On-boarding / Off-boarding Procedure for Security Response Committee Members
This document outlines the process for individual(s) both joining or leaving
the Kubernetes SRC (Security Response Committee).
For the purpose of example, we will use a placeholder name of **Jane Doe** with
a github username **`jdoe`** and a company name of **ACME LTD**.
<!-- toc -->
- [Required file and access grant updates.](#required-file-and-access-grant-updates)
- [kubernetes/committee-security-response repository](#kubernetessecurity-repository)
- [kubernetes/k8s.io repository](#kubernetesk8sio-repository)
- [kubernetes/community repository](#kubernetescommunity-repository)
- [kubernetes/org repository](#kubernetesorg-repository)
- [Add/remove from HackerOne](#addremove-from-hackerone)
- [Add/remove from OpsGenie rotation](#addremove-from-opsgenie-rotation)
- [Add/ Remove SRC Owner permission from Kubernetes Security Mailing Lists](#add-remove-src-owner-permission-from-kubernetes-security-mailing-lists)
- [Discuss Account](#discuss-account)
- [kubernetes-security github org](#kubernetes-security-github-org)
- [Slack](#slack)
- [Calendar](#calendar)
- [Google Docs](#google-docs)
- [Checklist](#checklist)
<!-- /toc -->
### Required file and access grant updates.
Once the SRC has promoted an individual(s) to a full SRC member, various
systems require updating. Likewise, should a SRC member leave the SRC - the
reverse is required, with the user being removed from each system.
#### kubernetes/committee-security-response repository
All SRC member discussion & approval must happen on the `kubernetes/committee-security-response`
repository first and only once approved by means of the pull request being
merged, should pull requests be approved / merged in the `kubernetes/community`
repository, and the user added to the mailing lists and ACLs.
##### file: https://github.com/kubernetes/committee-security-response/blob/master/README.md
Add / remove the SRC member(s) github name from `committee-security-response/README.md`
to the appropriate list of committee members, according to the usernames
alphabetical placing.
```
The initial Security Response Committee will consist of volunteers subscribed to the private [Kubernetes Security](https://groups.google.com/a/kubernetes.io/forum/#!forum/security) list. These are the people who have been involved in the initial discussion and volunteered:
- Jane Doe (**[@jdoe](https://github.com/jdoe)**) `<jdoe@acme.com>` [GPG_KEY]
```
If removing a SRC member, move them to the list of emeritus members.
##### file: https://github.com/kubernetes/committee-security-response/blob/master/OWNERS_ALIASES
Add / remove the SRC member(s) github name from `committee-security-response/OWNERS_ALIASES` to the
existing `security-response-committee` field, according to the usernames
alphabetical placing:
```yaml
aliases:
security-response-committee:
- jdoe
```
#### kubernetes/k8s.io repository
##### file: https://github.com/kubernetes/k8s.io/blob/main/groups/committee-security-response/groups.yaml
`groups.yaml` is the source of truth for membership to the
security-response-committee mailing lists. Update the `owners` field for the
following lists:
- `security@kubernetes.io`
- `security-discuss-private@kubernetes.io`
- `distributors-announce@kubernetes.io`
Ensure the 3 lists match.
##### file: https://github.com/kubernetes/k8s.io/blob/main/OWNERS_ALIASES
```yaml
aliases:
security-response-committee:
- jdoe
```
#### kubernetes/community repository
##### file: https://github.com/kubernetes/community/blob/master/sigs.yaml
Add / remove the SRC member(s) github name from `community/sigs.yaml` to the
existing `label`| `leadership` field, according to the usernames alphabetical
placing:
```yaml
label: security-response
leadership:
chairs:
- github: jdoe
name: Jane Doe
company: Acme LTD
```
Once the yaml is updated, run `make generate` to regenerate the markdown
versions.
This will then automatically create the following files:
* kubernetes/community/OWNERS_ALIASES
* kubernetes/community/security-response-committee/README.md
* kubernetes/community/sig-list.md
##### file: https://github.com/kubernetes/community/blob/master/communication/slack-config/usergroups.yaml
Add / remove the SRC member(s) github name from the `security-response-committee` user group.
#### kubernetes/org repository
##### file: https://github.com/kubernetes/org/blob/master/config/kubernetes/org.yaml
Add / remove the SRC member(s) github username from `config/kubernetes/org.yaml`
to the existing `security-response-committee` | `members` field. The usernames
should be alphabetized:
```yaml
security-response-committee:
description: Please report security issues to https://kubernetes.io/security
members:
- alice
- bob
- jdoe
```
Once merged, [peribolos](https://git.k8s.io/test-infra/prow/cmd/peribolos) will
automatically run and update the members of the GitHub group
https://github.com/orgs/kubernetes/teams/security-response-committee
#### Add/remove from HackerOne
To add or remove members from the Kubernetes HackerOne project, navigate to
https://hackerone.com/organizations/linux_foundation/settings/users
Click `Remove` next to a member to remove.
Click `Invite user` to add a new SRC member. Add them to the `Kubernetes Team`,
`Standard` and `Admin` groups.
We also request that new members enable 2-factor auth. Once they've accepted the
invitation, you can verify the status in the `2FA` column on the user management
page.
After verifying 2FA status, make the new member an "Organization Administrator"
by selecting "Edit user" from the context menu, then enabling "Organization
Administrator".
#### Add/remove from OpsGenie rotation
##### url: https://app.opsgenie.com/teams/dashboard/633ac733-665f-4d62-871e-cbc011f37037
Once the user account has been created in OpsGenie, they must add a
`github=GITHUB_USERNAME` tag to their OpsGenie profile for the tool to work.
See the below example.
##### url: https://kubernetes.app.opsgenie.com/settings/schedule/detail/f835cdef-8df9-4ddc-9a39-911cb9e521b5
Click `Edit Rotation` next to "PST Rotation", and add/remove the new member from the participants list.
#### Add/ Remove SRC Owner permission from Kubernetes Security Mailing Lists
New SRC members are added to various security lists and upgraded to "owner" (or
downgraded to member if they are leaving the SRC)
To add members and assign the "owner" role:
1. Visit the groups URL as a user authenticated as an existing "owner".
2. Select the 'Manage group' or 'Manage Members' link.
3. Within the left side panel, select 'Direct add member'.
4. Enter the new SRC members email address
5. Select the 'All members' link, or search for the new member in the search box.
6. Select the new member and change the drop down role to "Owner" (or "Manager" in the case of kubernetes-announce)
---
**Existing Accounts**
It may be the case, that the user has already joined the group / mailing list.
If this is the case, steps 1 to 4 can be ignored and you can proceed to change
the role of their existing account.
---
To downgrade existing owners to members:
1. Visit the groups URL as a user authenticated as an existing "owner".
2. Select the 'All members' link, or search for the existing owner in the search box.
3. Select the owner and change the drop down role to "Member".
| Mailing List | URL |
| ------------- | ------------- |
| Security Discuss | https://groups.google.com/forum/#!forum/kubernetes-security-discuss |
| Security Announce | https://groups.google.com/forum/#!forum/kubernetes-security-announce |
| Kubernetes Announce | https://groups.google.com/forum/#!forum/kubernetes-announce (Manager)|
| Kubernetes Dev | https://groups.google.com/forum/#!forum/kubernetes-dev (Member) |
_Note: the @kubernetes.io addresses are now managed through `groups.yaml`_
#### Discuss Account
A verified [discuss account](https://discuss.kubernetes.io/) is required.
#### kubernetes-security github org
Update the kubernetes-security github org team members for the additions or
removals.
Navigate to https://github.com/orgs/kubernetes-security/people, and invite new
members or remove existing members. Note that several non-SRC members have
access to this org (primarily release managers).
Once a new SRC member has accepted the invite, they should be granted `Owner`
permissions.
For members stepping down, please ensure they are not assigned any issues in
the vulnerability trackers:
- https://github.com/kubernetes-security/security-disclosures/issues
- https://github.com/kubernetes-security/security-disclosures-low/issues
#### Slack
SRC members must enable slack 2-factor authentication: https://slack.com/help/articles/204509068-Set-up-two-factor-authentication
New members must be manually added to the private channels on slack by someone
who is already a member of those channels:
1. `#SRC-private` for private SRC-only discussion
2. `#security-release-team` for private discussions with the security-release-team
Members who are stepping down must leave the channels themselves.
Finally, ask a `#slack-admins` member to add the new SRC member to the list of people who can post in `#announcements`.
If a member is stepping down, we must let the admins know to remove the `#announcements` permission.
#### Calendar
Update the Google calendar entries to add or remove the member:
1. SRC Monthly (monthly, first Thursday)
2. HackerOne sync (every 3 months, second Thursday)
#### Google Docs
Update the sharing settings for the following docs:
- "SRC Monthly Agenda & Notes" (owner: timallclair@gmail.com)
- "Kubernetes CNA Tracker" (owner: timallclair@gmail.com) - Only for [CNA trained members](https://github.com/kubernetes/committee-security-response/blob/master/cna-handbook.md)
### Checklist
The following checklist can be pasted into an onboarding issue to track all the steps that need to be taken:
```
- [ ] kubernetes/committee-security-response PR:
- [ ] README.md
- [ ] OWNERS_ALIASES
- [ ] SECURITY_CONTACTS
- [ ] kubernetes/k8s.io PR:
- [ ] groups/security-response-committee/groups.yaml
- `security@kubernetes.io`
- `security-discuss-private@kubernetes.io`
- `distributors-announce@kubernetes.io`
- [ ] OWNERS_ALIASES
- [ ] kubernetes/community PR:
- [ ] sigs.yaml
- [ ] communication/slack-config/usergroups.yaml
- [ ] Verify slack 2-factor auth
- [ ] `make generate`
- [ ] kubernetes/org PR:
- [ ] config/kubernetes/org.yaml
- [ ] HackerOne project membership
- [ ] Verify 2-factor auth
- [ ] OpsGenie rotation
- [ ] Add new user
- [ ] Update rotation
- [ ] Mailing lists
- [ ] [Security Discuss](https://groups.google.com/forum/#!forum/kubernetes-security-discuss) - owner
- [ ] [Security Announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce) - owner
- [ ] [Kubernetes Announce](https://groups.google.com/forum/#!forum/kubernetes-announce) - manager
- [ ] [Kubernetes Dev](https://groups.google.com/forum/#!forum/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
```
================================================
FILE: src-oncall.md
================================================
# Security Response Committee Oncall
SRC Oncall is a business-hours only oncall. That means you are not expected to
respond to issues outside of your normal daily working hours or on weekends or
holidays. If you are taking vacation or will be unable to perform your oncall
duties, please swap oncalls or find coverage for that week. See [managing oncall
rotation](#appendix-managing-oncall-rotation).
<!-- toc -->
- [Responsibilities](#responsibilities)
- [Triage Workflow](#triage-workflow)
- [HackerOne triage details](#hackerone-triage-details)
- [security@kubernetes.io Triage](#securitykubernetesio-triage)
- [Incident Response Workflow](#incident-response-workflow)
- [Handoff](#handoff)
- [Appendix: Managing Oncall Rotation](#appendix-managing-oncall-rotation)
- [Adding the rotation to your calendar](#adding-the-rotation-to-your-calendar)
- [Swapping shifts or adding coverage](#swapping-shifts-or-adding-coverage)
<!-- /toc -->
## Responsibilities
Daily:
- Triage vulnerability reports. We target 1 business day for initial response.
- HackerOne reports ([query](https://hackerone.com/bugs?subject=kubernetes&view=k8s_triage)),see
[HackerOne Workflow](#hackerone-triage-details) for details.
- security@kubernetes.io emails, see [securit@kubernetes.io Triage](#securitykubernetesio-triage)
for details.
- Handle incident response for ongoing issues
- Drive progress on assigned issues ([query](https://github.com/kubernetes-security/security-disclosures/issues/assigned/@me))
- See [incident response](#incident-response-workflow) for details
- Ping incident commander of critical issues
([query](https://github.com/kubernetes-security/security-disclosures/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+label%3Aseverity%2Fcritical))
if last update > 2 days ago
Weekly (ideally at the beginning of your shift):
- Ping incident commander of high severity issues
([query](https://github.com/kubernetes-security/security-disclosures/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+label%3Aseverity%2Fhigh))
if last update was > 7 days ago
- Ping incident commander of medium severity issues
([query](https://github.com/kubernetes-security/security-disclosures/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+label%3Aseverity%2Fmedium))
if last update was > 1 month ago
- Check for new issues in this repository, especially distributor list join requests. Triage, assign or handle new issues, as appropriate.
([query](https://github.com/kubernetes/security/issues))
- Check for new PRs in this repository and address open PRs where possible
([query](https://github.com/kubernetes/security/pulls))
## Triage Workflow
### HackerOne triage details
**1. Assess assigned issues**
The recommended way of reviewing hackerone issues needing triage is to check
over the assigned issues daily:
https://hackerone.com/bugs?subject=kubernetes&view=k8s\_triage
This view tracks issues that are assigned to the Kubernetes Team (SRC), but
don't yet have a bounty awarded, which is a heuristic for whether the report
needs attention.
**1.a. Needs more information or Invalid**
If the report needs more information or is invalid, you can either respond
directly to the reporter (Add comment > All participants), or respond in a
private comment (Team only) and ask (reassign) the H1 Triage team to relay the
message.
**2. Set severity & tier**
Once you've determined that the report is valid and have an understanding of the
impact, set the [severity][] of the issue based on the CVSS score, and set the
tier (custom field) based on the [Kubernetes definition of
tiers](https://hackerone.com/kubernetes) (under "Rewards").
_TODO: Refine the definition of reward tiers._
[severity]: security-release-process.md#severity-thresholds---how-we-do-vulnerability-scoring
**3. File tracking issue**
Every non-public issue that we decide to take action on should get filed as a
GitHub issue in the https://github.com/kubernetes-security/security-disclosures
repo.
From the HackerOne report, you can use the GitHub integration to auto-file the tracking issue, and
sync updates with the H1 report:
1. Click "References" (in the right sidebar)
2. Select "Kubernetes HackerOne Robot" to automatically create the issue.
- If the issue was already created manually, or is being created in a different repo (e.g. for a
public issue), select "Manual Integration" instead.
3. Click "Create"
4. Assign the created issue to the appropriate assignee (usually yourself), and apply any relevant
labels.
**4. Award bounty**
Once you're confident that we've sufficiently assessed the severity and tier
(try to get an approval from someone else on the committee), it's time to award
the bounty. Note that you _do not_ need to wait until the issue is resolved
before awarding the bounty.
Choose the corresponding amount from the tiered bounty tables on
https://hackerone.com/kubernetes (under "rewards"). Then, scroll down to the
comment box on the report and change the action to "Set award". Enter the
amount, leave a comment if you'd like, and click "Set award". Congratulations,
you've completed triage on this report (continue on to incident response).
**5. Mark resolved & Disclose**
**Pending Resolution tab:** Once the issue has been resolved or fully handed off to the public
Kubernetes community, it should be marked as resolved. Select "Close report" from the action
drop-down over the comment box, and set the status to "Resolved". Add a comment about the final
resolution (often a link to the public announcement).
**Needs Disclosure tab:** Most issues should be publicly disclosed, unless there is a specific
reason not to. From the drop-down, choose "Request disclosure". "Full Disclosure" should be used in
most cases. It discloses all the details from the report, except for team-only comments (red comment
boxes). Specific details can be redacted.
Unfortunately there is no way to mark a report as "do not disclose". If the report shouldn't be
disclosed for any reason, leave a team-only comment with `DO NOT DISCLOSE` and a justification.
**Pending Disclosure tab:** Once disclosure has been requested, we give the original reporter 1
month to respond to the disclosure request. If there hasn't been a repsonse for over 1 month, you
can just disclose it. Select "Disclose" from the drop-down menu, and confirm the disclosure type.
### security@kubernetes.io Triage
We leverage Google Groups [collaborative
inbox](https://support.google.com/a/users/answer/167430?hl=en) features to triage incoming emails to
the list.
1. Every actionable email should have an assignee who is accountable for ensuring the report is
followed up and responded to in a timely manner.
- Note: we have an auto-responder which encourages reporters to resubmit reports through the
HackerOne bug bounty, so keep an eye out for duplicates.
2. Unacctionable emails should be marked as such.
3. Issues which have been resolved should be marked as completed.
4. Legitimate vulnerability reports should be copied into a tracking issue
- Include a link back to Google Groups thread (original report field in the template)
- Add the `Tracked` label to the groups thread
Spam: when a spam message is received, please use the "Report abuse" button. Reporting a message as
abuse only hides it for the reporter, so after reporting it please delete the original.
## Incident Response Workflow
## Handoff
When your shift ends, you may be the incident commander on one or more ongoing
incidents. If you are already invested in the incident and have the bandwidth
for it, you can continue managing the incident (thanks!), but _you are not
obligated to continue managing the incident!_
If you would like to handoff incident command:
1. Start by **ensuring the tracking issue is up to date** - review the
information in the issue description, and fill in or correct any missing
details.
2. **Leave a comment** to dump any additional context and state you have on the
issue. Make sure to list any open questions or decisions and any pending
action items.
3. Reassign the issue to the next oncall.
Finally, reach out to the next oncall (email, slack, VC, your choice) to make
sure they're aware of the handoff and to answer any questions. _Until they've
explicitly acknowledged the handoff you are still the incident commander!_
## Appendix: Managing Oncall Rotation
### Adding the rotation to your calendar
1. Navigate to the SRC oncall rotation:
https://kubernetes.app.opsgenie.com/settings/schedule/detail/f835cdef-8df9-4ddc-9a39-911cb9e521b5
2. Click "Open calendar" (appears on hover), add to your calendar.
### Swapping shifts or adding coverage
0. Find someone to agree to swap shifts or cover for days you will be
unavailable.
1. Navigate to the SRC oncall rotation:
https://kubernetes.app.opsgenie.com/settings/schedule/detail/f835cdef-8df9-4ddc-9a39-911cb9e521b5
2. Click "Add override", fill in the appropriate details.
- Select the user who will be taking the shift
- Select the SRC rotation
- Enter the dates for the override
_Note: If you're swapping shifts, you'll need to do this twice, once for your
shift and once for the shift you're swapping for._
================================================
FILE: tools/patchformat.py
================================================
import argparse
from ghapi.core import GhApi
import os
import time
username = os.environ['GH_USERNAME']
# When creating github personal access token, be sure to check all permissions under the repo scope to access private repos
github_token = os.environ['GH_TOKEN']
api = GhApi(owner='kubernetes-security', repo='kubernetes',token=github_token)
parser = argparse.ArgumentParser(description='Format patch files')
required = parser.add_argument_group('required arguments')
required.add_argument('--pr', help='Pull Request Number in kubernetes-security/kubernetes with the fix (e.g. 63)', required=True)
required.add_argument('--cve', help='CVE for the vulnerability', required=True)
required.add_argument('-r', '--release', help='Kubernetes release branch (e.g. 1.30)', required=True)
parser.add_argument('-v', '--version', help='Patch version, if a correction is being sent')
args = parser.parse_args()
pull = api.pulls.get(args.pr)
patch = api(pull.url, headers={'Accept': 'application/vnd.github.patch'})
patch_split = patch.splitlines()
patch_list = []
local_time = time.localtime()
patch_list.append('From: distributors-announce <distributors-announce@kubernetes.io>')
patch_list.append('Date: ' + time.strftime('%a, %d %b %Y %H:%M:%S %z', local_time))
patch_list.append('Subject: Fix ' + args.cve)
patch_list.append('')
started = False
for line in patch_split:
if line != '---' and not started:
pass
else:
started = True
patch_list.append(line)
if args.version:
filename = args.cve.split('-')[2] + '_v' + args.release + '_v' + args.version + '.patch'
else:
filename = args.cve.split('-')[2] + '_v' + args.release + '.patch'
f = open(filename, 'w')
f.write('\n'.join(patch_list))
f.write('\n')
f.close()
gitextract_q9uzkq0d/
├── .github/
│ └── ISSUE_TEMPLATE/
│ └── distributors-application.md
├── CONTRIBUTING.md
├── LICENSE
├── OWNERS
├── OWNERS_ALIASES
├── README.md
├── SECURITY.md
├── SECURITY_CONTACTS
├── cna-handbook.md
├── code-of-conduct.md
├── comms-templates/
│ ├── clickjacking-response.md
│ ├── container-vuln-response.md
│ ├── distributors-announcement-email.md
│ ├── distributors-removal-email.md
│ ├── non-vuln-response.md
│ ├── spf-record-response.md
│ ├── vulnerability-announcement-email.md
│ ├── vulnerability-announcement-issue.md
│ ├── vulnerability-announcement-placeholder-issue.md
│ └── vulnerability-announcement-slack.md
├── cve-requests.md
├── emeritus.md
├── playbook/
│ └── token-leak-process.md
├── private-distributors-list.md
├── security-release-process.md
├── severity-ratings.md
├── src-onboarding-offboarding.md
├── src-oncall.md
└── tools/
└── patchformat.py
Condensed preview — 29 files, each showing path, character count, and a content snippet. Download the .json file or copy for the full structured content (102K chars).
[
{
"path": ".github/ISSUE_TEMPLATE/distributors-application.md",
"chars": 1129,
"preview": "---\nname: Distributors Application\ntitle: Distributors Application for <YOUR DISTRIBUTION HERE>\nabout: Apply for membors"
},
{
"path": "CONTRIBUTING.md",
"chars": 1615,
"preview": "# Contributing Guidelines\n\nWelcome to Kubernetes. We are excited about the prospect of you joining our [community](https"
},
{
"path": "LICENSE",
"chars": 11357,
"preview": " Apache License\n Version 2.0, January 2004\n "
},
{
"path": "OWNERS",
"chars": 133,
"preview": "# See the OWNERS docs at https://go.k8s.io/owners\n\napprovers:\n - committee-security-response\n\nlabels:\n- committee/secur"
},
{
"path": "OWNERS_ALIASES",
"chars": 272,
"preview": "# See the OWNERS_ALIASES docs at https://go.k8s.io/owners#owners_aliases\n\naliases:\n committee-security-response:\n - "
},
{
"path": "README.md",
"chars": 2560,
"preview": "# Security\n\nKubernetes Security Release Process and Security Committee documentation.\n\nTo report a vulnerability, please"
},
{
"path": "SECURITY.md",
"chars": 1069,
"preview": "# Security Policy\n\n## Security Announcements\n\nJoin the [kubernetes-security-announce] group for security and vulnerabili"
},
{
"path": "SECURITY_CONTACTS",
"chars": 772,
"preview": "# Defined below are the security contacts for this repo.\n#\n# They are the contact point for the Security Response Commit"
},
{
"path": "cna-handbook.md",
"chars": 7754,
"preview": "# CVE Numbering Authority tasks\n\n<!-- toc -->\n- [CVE Numbering Authority tasks](#cve-numbering-authority-tasks)\n - [CNA"
},
{
"path": "code-of-conduct.md",
"chars": 148,
"preview": "# Kubernetes Community Code of Conduct\n\nPlease refer to our [Kubernetes Community Code of Conduct](https://git.k8s.io/co"
},
{
"path": "comms-templates/clickjacking-response.md",
"chars": 491,
"preview": "Thank you for your interest in helping improve the security of Kubernetes.\n\nThe public Kubernetes website is a read-only"
},
{
"path": "comms-templates/container-vuln-response.md",
"chars": 320,
"preview": "Thank you for your message.\n\nBecause these are public CVEs, please use one of these public options instead:\n\n- kubernete"
},
{
"path": "comms-templates/distributors-announcement-email.md",
"chars": 2083,
"preview": "_Use this email template for pre-disclosing security vulnerabilities to distributors-announce._\n\n_Note that distributors"
},
{
"path": "comms-templates/distributors-removal-email.md",
"chars": 976,
"preview": "TO: `$MEMBER_EMAIL`\nCC: `security-discuss-private@kubernetes.io`\nSUBJECT: `Kubernetes Disclosure List Removal Due to Unc"
},
{
"path": "comms-templates/non-vuln-response.md",
"chars": 368,
"preview": "Thank you for your message.\n\nIt appears this report is neither a vulnerability report nor a security incident. Consider "
},
{
"path": "comms-templates/spf-record-response.md",
"chars": 562,
"preview": "Thank you for your interest in helping improve the security of Kubernetes.\n\nKubernetes is an open-source project, and do"
},
{
"path": "comms-templates/vulnerability-announcement-email.md",
"chars": 2824,
"preview": "_Use this email template for publicly disclosing security vulnerabilities._\n\n_The email should be **concise** and **acti"
},
{
"path": "comms-templates/vulnerability-announcement-issue.md",
"chars": 1959,
"preview": "_Use this issue template for filling out CVE placeholder issues._\n\nTITLE: `CVE-####-######: $SUMMARY`\n\n---\n\n<!-- Copy UR"
},
{
"path": "comms-templates/vulnerability-announcement-placeholder-issue.md",
"chars": 182,
"preview": "_Use this issue template for filing CVE placeholder issues._\n\nTITLE: PLACEHOLDER ISSUE\n\n---\n\n/triage accepted\n/lifecycle"
},
{
"path": "comms-templates/vulnerability-announcement-slack.md",
"chars": 722,
"preview": "_Use this slack message template for publicly disclosing security vulnerabilities on slack._\n\n_This message should be po"
},
{
"path": "cve-requests.md",
"chars": 475,
"preview": "# CVE Number Requests\n\nThe Kubernetes project is a registered [CVE Numbering Authority](http://cve.mitre.org/cve/request"
},
{
"path": "emeritus.md",
"chars": 947,
"preview": "Emeritus committee members:\n\n- Brandon Philips (**[@philips](https://github.com/philips)**) `<bphilips@redhat.com>`\n- Je"
},
{
"path": "playbook/token-leak-process.md",
"chars": 1786,
"preview": "# GitHub Token Leak Response Process\n\nThe SRC may become aware that a Kubernetes Org member has leaked a GitHub token. B"
},
{
"path": "private-distributors-list.md",
"chars": 3803,
"preview": "## Private Distributors List\n\nThis list is used to provide actionable information to multiple distribution\nvendors at on"
},
{
"path": "security-release-process.md",
"chars": 18470,
"preview": "# Security Release Process\n\nKubernetes is a large growing community of volunteers, users, and vendors. The Kubernetes co"
},
{
"path": "severity-ratings.md",
"chars": 12267,
"preview": "# Severity Ratings\n\nThe Security Response Committee evaluates vulnerability severity on a case-by-case basis, guided by\n"
},
{
"path": "src-onboarding-offboarding.md",
"chars": 11649,
"preview": "# On-boarding / Off-boarding Procedure for Security Response Committee Members\n\nThis document outlines the process for i"
},
{
"path": "src-oncall.md",
"chars": 9806,
"preview": "# Security Response Committee Oncall\n\nSRC Oncall is a business-hours only oncall. That means you are not expected to\nres"
},
{
"path": "tools/patchformat.py",
"chars": 1757,
"preview": "import argparse\nfrom ghapi.core import GhApi\nimport os\nimport time\n\nusername = os.environ['GH_USERNAME']\n# When creating"
}
]
About this extraction
This page contains the full source code of the kubernetes/security GitHub repository, extracted and formatted as plain text for AI agents and large language models (LLMs). The extraction includes 29 files (96.0 KB), approximately 22.5k tokens. Use this with OpenClaw, Claude, ChatGPT, Cursor, Windsurf, or any other AI tool that accepts text input. You can copy the full output to your clipboard or download it as a .txt file.
Extracted by GitExtract — free GitHub repo to text converter for AI. Built by Nikandr Surkov.