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 about: Apply for memborship of distributors-announce@kubernetes.io --- **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.** **7. Be willing to contribute 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: - [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)**) `` - CJ Cullen (**[@cjcullen](https://github.com/cjcullen)**) `` - Joel Smith (**[@joelsmith](https://github.com/joelsmith)**) `` [4096R/0x1688ADC79BECDDAF] - Micah Hausler (**[@micahhausler](https://github.com/micahhausler)**) `` - Mo Khan (**[@enj](https://github.com/enj)**) `` - Nathan Herz (**[@natherz97](https://github.com/natherz97)**) `` - Standa Láznička (**[@stlaz](https://github.com/stlaz)**) `` - Tabitha Sable (**[@tabbysable](https://github.com/tabbysable)**) `` - Vinayak Goyal (**[@vinayakankugoyal](https://github.com/vinayakankugoyal)**) `` - Vyom Yadav (**[@Vyom-Yadav](https://github.com/Vyom-Yadav)**) `` ### 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 - [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) ## 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)**) `` - Joel Smith (**[@joelsmith](https://github.com/joelsmith)**) `` - Micah Hausler (**[@micahhausler](https://github.com/micahhausler)**) `` - Mo Khan (**[@enj](https://github.com/enj)**) `` - Sri Saran Balaji (**[@SaranBalaji90](https://github.com/SaranBalaji90)**) `` - Tabitha Sable (**[@tabbysable](https://github.com/tabbysable)**) `` ## 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 command/component in versions ` * 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. Kubernetes clusters are only affected if $CONDITION 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` --- 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_ ### 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 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. /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)**) `` - Jess Frazelle (**[@jessfraz](https://github.com/jessfraz)**) `` - Jonathan Pulsifer (**[@jonpulsifer](https://github.com/jonpulsifer)**) `` - Jordan Liggitt (**[@liggitt](https://github.com/liggitt)**) `` [4096R/0x39928704103C7229] - Swamy Shivaganga Nagaraju (**[@swamymsft](https://github.com/swamymsft)**) `` - Tim Allclair (**[@tallclair](https://github.com/tallclair)**) `` - Luke Hinds (**[@lukehinds](https://github.com/lukehinds)**) `lhinds@protonmail.com` - Sri Saran Balaji (**[@SaranBalaji90](https://github.com/SaranBalaji90)**) `` - Craig Ingram (**[@cji](https://github.com/cji)**) `` - Rita Zhang (**[@ritazh](https://github.com/ritazh)**) `` ================================================ 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. - [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) ## 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**. - [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) ### 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)**) `` [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. ![User Configuration](/images/user-tag.png) ##### 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. ![Edit Rotation](/images/opsgenie-edit-rotation.png) #### 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). - [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) ## 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 ![Triage workflow flowchart](images/src-oncall-triage-flow.png) ### 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. ![HackerOne comment](images/src-oncall-h1-triage-comment.png) ![HackerOne reassign](images/src-oncall-h1-triage-reassign.png) **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._ ![Set the severity & tier on HackerOne](images/src-oncall-h1-triage-severity.png) [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). ![Set HackerOne reward](images/src-oncall-h1-triage-reward.png) **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 ![Incident response flowchart](images/src-oncall-incident-flow.png) ## 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. ![Oncall calendar](images/src-oncall-calendar.png) ### 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._ ![Edit the oncall schedule](images/src-oncall-override.png) ================================================ 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 ') 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()