[ { "path": ".github/ISSUE_TEMPLATE/distributors-application.md", "content": "---\nname: Distributors Application\ntitle: Distributors Application for \nabout: Apply for memborship of distributors-announce@kubernetes.io\n---\n\n\n\n**Actively monitored security email alias for our project:**\n\n**1. Be an actively maintained and CNCF certified distribution of Kubernetes components.**\n\n**2. Have a user base not limited to your own organization.**\n\n**3. Have a publicly verifiable track record up to present day of fixing security issues.**\n\n**4. Not be a downstream or rebuild of another distribution.**\n\n**5. Be a participant and active contributor in the community.**\n\n**6. Accept the Embargo Policy.**\n\n\n**7. Be willing to contribute back.**\n\n\n**8. Have someone already on the list vouch for the person requesting membership on behalf of your distribution.**\n" }, { "path": "CONTRIBUTING.md", "content": "# Contributing Guidelines\n\nWelcome 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:\n\n_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._\n\n## Getting Started\n\nWe have full documentation on how to get started contributing here:\n\n\n\n- [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\n- [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)\n- [Contributor Cheat Sheet](https://git.k8s.io/community/contributors/guide/contributor-cheatsheet) - Common resources for existing developers\n\n## Mentorship\n\n- [Mentoring Initiatives](https://git.k8s.io/community/mentoring) - We have a diverse set of mentorship programs available that are always looking for volunteers!\n\n## Contact Information\n\n- [Mailing list](https://groups.google.com/forum/#!forum/kubernetes-security-discuss)\n" }, { "path": "LICENSE", "content": " Apache License\n Version 2.0, January 2004\n http://www.apache.org/licenses/\n\n TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION\n\n 1. Definitions.\n\n \"License\" shall mean the terms and conditions for use, reproduction,\n and distribution as defined by Sections 1 through 9 of this document.\n\n \"Licensor\" shall mean the copyright owner or entity authorized by\n the copyright owner that is granting the License.\n\n \"Legal Entity\" shall mean the union of the acting entity and all\n other entities that control, are controlled by, or are under common\n control with that entity. For the purposes of this definition,\n \"control\" means (i) the power, direct or indirect, to cause the\n direction or management of such entity, whether by contract or\n otherwise, or (ii) ownership of fifty percent (50%) or more of the\n outstanding shares, or (iii) beneficial ownership of such entity.\n\n \"You\" (or \"Your\") shall mean an individual or Legal Entity\n exercising permissions granted by this License.\n\n \"Source\" form shall mean the preferred form for making modifications,\n including but not limited to software source code, documentation\n source, and configuration files.\n\n \"Object\" form shall mean any form resulting from mechanical\n transformation or translation of a Source form, including but\n not limited to compiled object code, generated documentation,\n and conversions to other media types.\n\n \"Work\" shall mean the work of authorship, whether in Source or\n Object form, made available under the License, as indicated by a\n copyright notice that is included in or attached to the work\n (an example is provided in the Appendix below).\n\n \"Derivative Works\" shall mean any work, whether in Source or Object\n form, that is based on (or derived from) the Work and for which the\n editorial revisions, annotations, elaborations, or other modifications\n represent, as a whole, an original work of authorship. For the purposes\n of this License, Derivative Works shall not include works that remain\n separable from, or merely link (or bind by name) to the interfaces of,\n the Work and Derivative Works thereof.\n\n \"Contribution\" shall mean any work of authorship, including\n the original version of the Work and any modifications or additions\n to that Work or Derivative Works thereof, that is intentionally\n submitted to Licensor for inclusion in the Work by the copyright owner\n or by an individual or Legal Entity authorized to submit on behalf of\n the copyright owner. For the purposes of this definition, \"submitted\"\n means any form of electronic, verbal, or written communication sent\n to the Licensor or its representatives, including but not limited to\n communication on electronic mailing lists, source code control systems,\n and issue tracking systems that are managed by, or on behalf of, the\n Licensor for the purpose of discussing and improving the Work, but\n excluding communication that is conspicuously marked or otherwise\n designated in writing by the copyright owner as \"Not a Contribution.\"\n\n \"Contributor\" shall mean Licensor and any individual or Legal Entity\n on behalf of whom a Contribution has been received by Licensor and\n subsequently incorporated within the Work.\n\n 2. Grant of Copyright License. Subject to the terms and conditions of\n this License, each Contributor hereby grants to You a perpetual,\n worldwide, non-exclusive, no-charge, royalty-free, irrevocable\n copyright license to reproduce, prepare Derivative Works of,\n publicly display, publicly perform, sublicense, and distribute the\n Work and such Derivative Works in Source or Object form.\n\n 3. Grant of Patent License. Subject to the terms and conditions of\n this License, each Contributor hereby grants to You a perpetual,\n worldwide, non-exclusive, no-charge, royalty-free, irrevocable\n (except as stated in this section) patent license to make, have made,\n use, offer to sell, sell, import, and otherwise transfer the Work,\n where such license applies only to those patent claims licensable\n by such Contributor that are necessarily infringed by their\n Contribution(s) alone or by combination of their Contribution(s)\n with the Work to which such Contribution(s) was submitted. If You\n institute patent litigation against any entity (including a\n cross-claim or counterclaim in a lawsuit) alleging that the Work\n or a Contribution incorporated within the Work constitutes direct\n or contributory patent infringement, then any patent licenses\n granted to You under this License for that Work shall terminate\n as of the date such litigation is filed.\n\n 4. Redistribution. You may reproduce and distribute copies of the\n Work or Derivative Works thereof in any medium, with or without\n modifications, and in Source or Object form, provided that You\n meet the following conditions:\n\n (a) You must give any other recipients of the Work or\n Derivative Works a copy of this License; and\n\n (b) You must cause any modified files to carry prominent notices\n stating that You changed the files; and\n\n (c) You must retain, in the Source form of any Derivative Works\n that You distribute, all copyright, patent, trademark, and\n attribution notices from the Source form of the Work,\n excluding those notices that do not pertain to any part of\n the Derivative Works; and\n\n (d) If the Work includes a \"NOTICE\" text file as part of its\n distribution, then any Derivative Works that You distribute must\n include a readable copy of the attribution notices contained\n within such NOTICE file, excluding those notices that do not\n pertain to any part of the Derivative Works, in at least one\n of the following places: within a NOTICE text file distributed\n as part of the Derivative Works; within the Source form or\n documentation, if provided along with the Derivative Works; or,\n within a display generated by the Derivative Works, if and\n wherever such third-party notices normally appear. The contents\n of the NOTICE file are for informational purposes only and\n do not modify the License. You may add Your own attribution\n notices within Derivative Works that You distribute, alongside\n or as an addendum to the NOTICE text from the Work, provided\n that such additional attribution notices cannot be construed\n as modifying the License.\n\n You may add Your own copyright statement to Your modifications and\n may provide additional or different license terms and conditions\n for use, reproduction, or distribution of Your modifications, or\n for any such Derivative Works as a whole, provided Your use,\n reproduction, and distribution of the Work otherwise complies with\n the conditions stated in this License.\n\n 5. Submission of Contributions. Unless You explicitly state otherwise,\n any Contribution intentionally submitted for inclusion in the Work\n by You to the Licensor shall be under the terms and conditions of\n this License, without any additional terms or conditions.\n Notwithstanding the above, nothing herein shall supersede or modify\n the terms of any separate license agreement you may have executed\n with Licensor regarding such Contributions.\n\n 6. Trademarks. This License does not grant permission to use the trade\n names, trademarks, service marks, or product names of the Licensor,\n except as required for reasonable and customary use in describing the\n origin of the Work and reproducing the content of the NOTICE file.\n\n 7. Disclaimer of Warranty. Unless required by applicable law or\n agreed to in writing, Licensor provides the Work (and each\n Contributor provides its Contributions) on an \"AS IS\" BASIS,\n WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or\n implied, including, without limitation, any warranties or conditions\n of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A\n PARTICULAR PURPOSE. You are solely responsible for determining the\n appropriateness of using or redistributing the Work and assume any\n risks associated with Your exercise of permissions under this License.\n\n 8. Limitation of Liability. In no event and under no legal theory,\n whether in tort (including negligence), contract, or otherwise,\n unless required by applicable law (such as deliberate and grossly\n negligent acts) or agreed to in writing, shall any Contributor be\n liable to You for damages, including any direct, indirect, special,\n incidental, or consequential damages of any character arising as a\n result of this License or out of the use or inability to use the\n Work (including but not limited to damages for loss of goodwill,\n work stoppage, computer failure or malfunction, or any and all\n other commercial damages or losses), even if such Contributor\n has been advised of the possibility of such damages.\n\n 9. Accepting Warranty or Additional Liability. While redistributing\n the Work or Derivative Works thereof, You may choose to offer,\n and charge a fee for, acceptance of support, warranty, indemnity,\n or other liability obligations and/or rights consistent with this\n License. However, in accepting such obligations, You may act only\n on Your own behalf and on Your sole responsibility, not on behalf\n of any other Contributor, and only if You agree to indemnify,\n defend, and hold each Contributor harmless for any liability\n incurred by, or claims asserted against, such Contributor by reason\n of your accepting any such warranty or additional liability.\n\n END OF TERMS AND CONDITIONS\n\n APPENDIX: How to apply the Apache License to your work.\n\n To apply the Apache License to your work, attach the following\n boilerplate notice, with the fields enclosed by brackets \"{}\"\n replaced with your own identifying information. (Don't include\n the brackets!) The text should be enclosed in the appropriate\n comment syntax for the file format. We also recommend that a\n file or class name and description of purpose be included on the\n same \"printed page\" as the copyright notice for easier\n identification within third-party archives.\n\n Copyright {yyyy} {name of copyright owner}\n\n Licensed under the Apache License, Version 2.0 (the \"License\");\n you may not use this file except in compliance with the License.\n You may obtain a copy of the License at\n\n http://www.apache.org/licenses/LICENSE-2.0\n\n Unless required by applicable law or agreed to in writing, software\n distributed under the License is distributed on an \"AS IS\" BASIS,\n WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\n See the License for the specific language governing permissions and\n limitations under the License.\n" }, { "path": "OWNERS", "content": "# See the OWNERS docs at https://go.k8s.io/owners\n\napprovers:\n - committee-security-response\n\nlabels:\n- committee/security-response\n" }, { "path": "OWNERS_ALIASES", "content": "# See the OWNERS_ALIASES docs at https://go.k8s.io/owners#owners_aliases\n\naliases:\n committee-security-response:\n - cjcullen\n - enj\n - joelsmith\n - micahhausler\n - natherz97\n - puerco\n - stlaz\n - tabbysable\n - vinayakankugoyal\n - Vyom-Yadav\n" }, { "path": "README.md", "content": "# Security\n\nKubernetes Security Release Process and Security Committee documentation.\n\nTo report a vulnerability, please refer to https://kubernetes.io/security.\n\n## Security Response Committee (SRC)\n\nThe Security Response Committee (SRC) is responsible for triaging and handling the security issues for Kubernetes. Following are the current Security Response Committee members:\n\n- Adolfo García Veytia (**[@puerco](https://github.com/puerco)**) ``\n- CJ Cullen (**[@cjcullen](https://github.com/cjcullen)**) ``\n- Joel Smith (**[@joelsmith](https://github.com/joelsmith)**) `` [4096R/0x1688ADC79BECDDAF]\n- Micah Hausler (**[@micahhausler](https://github.com/micahhausler)**) ``\n- Mo Khan (**[@enj](https://github.com/enj)**) ``\n- Nathan Herz (**[@natherz97](https://github.com/natherz97)**) ``\n- Standa Láznička (**[@stlaz](https://github.com/stlaz)**) ``\n- Tabitha Sable (**[@tabbysable](https://github.com/tabbysable)**) ``\n- Vinayak Goyal (**[@vinayakankugoyal](https://github.com/vinayakankugoyal)**) ``\n- Vyom Yadav (**[@Vyom-Yadav](https://github.com/Vyom-Yadav)**) ``\n\n### Contacting the SRC\n\nThere 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.\n\n| List or Group | Visibility | Uses |\n| ------------- | ---------- | ---- |\n| 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) |\n| [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. |\n| release-managers-private@kubernetes.io | Private | Release Managers private discussion. All members are subscribed to security@kubernetes.io. |\n| security-discuss-private@kubernetes.io | Private | SRC private discussion. All members are subscribed to security@kubernetes.io |\n\n## Community, discussion, contribution, and support\n\nLearn how to engage with the Kubernetes community on the [community page](http://kubernetes.io/community/).\n\n### Code of conduct\n\nParticipation in the Kubernetes community is governed by the [Kubernetes Code of Conduct](code-of-conduct.md).\n" }, { "path": "SECURITY.md", "content": "# Security Policy\n\n## Security Announcements\n\nJoin the [kubernetes-security-announce] group for security and vulnerability announcements.\n\nYou can also subscribe to an RSS feed of the above using [this link][kubernetes-security-announce-rss].\n\n## Reporting a Vulnerability\n\nInstructions for reporting a vulnerability can be found on the\n[Kubernetes Security and Disclosure Information] page.\n\n## Supported Versions\n\nInformation about supported Kubernetes versions can be found on the\n[Kubernetes version and version skew support policy] page on the Kubernetes website.\n\n[kubernetes-security-announce]: https://groups.google.com/forum/#!forum/kubernetes-security-announce\n[kubernetes-security-announce-rss]: https://groups.google.com/forum/feed/kubernetes-security-announce/msgs/rss_v2_0.xml?num=50\n[Kubernetes version and version skew support policy]: https://kubernetes.io/docs/setup/release/version-skew-policy/#supported-versions\n[Kubernetes Security and Disclosure Information]: https://kubernetes.io/docs/reference/issues-security/security/#report-a-vulnerability\n" }, { "path": "SECURITY_CONTACTS", "content": "# Defined below are the security contacts for this repo.\n#\n# They are the contact point for the Security Response Committee to reach out\n# to for triaging and handling of incoming issues.\n#\n# Yes, this is absurd because this repo is for use by the Security Response\n# Committee, and as a tautology, we know how to contact ourselves. Creating\n# this file avoids the need to special-case our own repos in the bot. \n#\n# The below names agree to abide by the\n# [Embargo Policy](https://git.k8s.io/security/private-distributors-list.md#embargo-policy)\n# and will be removed and replaced if they violate that agreement.\n#\n# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE\n# INSTRUCTIONS AT https://kubernetes.io/security/\n\ncommittee-security-response\n" }, { "path": "cna-handbook.md", "content": "# CVE Numbering Authority tasks\n\n\n- [CVE Numbering Authority tasks](#cve-numbering-authority-tasks)\n - [CNA-trained Security Response Committee members](#cna-trained-security-response-committee-members)\n - [References](#references)\n - [Common CNA tasks](#common-cna-tasks)\n - [Track CVE ID status](#track-cve-id-status)\n - [Requesting CVE IDs](#requesting-cve-ids)\n - [cvelib](#cvelib)\n - [Setup](#setup)\n - [User admin](#user-admin)\n - [Assign a CVE ID to vulnerability](#assign-a-cve-id-to-vulnerability)\n - [Populate CVE details](#populate-cve-details)\n - [Reject unused CVEs](#reject-unused-cves)\n - [Uncommon tasks](#uncommon-tasks)\n - [Splitting, merging, amending CVEs](#splitting-merging-amending-cves)\n\n\n## CNA-trained Security Response Committee members\n\nThe following members of the Security Response Committee have completed CNA training and can request/assign/publish CVEs for the Kubernetes CNA:\n\n- CJ Cullen (**[@cjcullen](https://github.com/cjcullen)**) ``\n- Joel Smith (**[@joelsmith](https://github.com/joelsmith)**) ``\n- Micah Hausler (**[@micahhausler](https://github.com/micahhausler)**) ``\n- Mo Khan (**[@enj](https://github.com/enj)**) ``\n- Sri Saran Balaji (**[@SaranBalaji90](https://github.com/SaranBalaji90)**) ``\n- Tabitha Sable (**[@tabbysable](https://github.com/tabbysable)**) ``\n\n## References\n\nCNA documents are hosted by MITRE at https://cve.mitre.org/about/documents.html#cna, notably:\n\n* CNA onboarding guides: https://cveproject.github.io/docs/cna/onboarding/index.html\n * Also available in video form: https://www.youtube.com/playlist?list=PLWfD9RQVdJ6c4eMkdqbOKqF7zPCqXkgX3\n* CNA Rules: https://www.cve.org/ResourcesSupport/AllResources/CNARules\n\nA walkthrough of this handbook is also available in [video form](https://youtu.be/pcmAaEP7HD4).\n\n## Common CNA tasks\n\n### Track CVE ID status\n\nAs 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)\n\n### Requesting CVE IDs\n\nIf 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].\n\n[cvelib]: https://github.com/RedHatProductSecurity/cvelib\n\nOnce the CVE ID is received, add it to the [tracking sheet] as unassigned IDs for future assignment.\n\n### cvelib\n\n#### Setup\n\nIf you want to run cvelib in a container, use the following\n\n```bash\n# Don't quote the values\necho << EOF > env.txt\nCVE_USER=${YOUR_EMAIL}\nCVE_ORG=kubernetes\nCVE_API_KEY=${YOUR_API_KEY}\nEOF\n\ncat << EOF > Dockerfile\nFROM python:3-slim\n\nRUN pip install cvelib\n\nENTRYPOINT [\"/usr/local/bin/cve\"]\nEOF\n\ndocker build -t $USER/cvelib:latest .\ndocker run --env-file=env.txt -it --rm $USER/cvelib:latest\n```\n\nBy 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:\n\n```bash\ndocker run --env-file=env.txt -it --rm $USER/cvelib:latest reserve -h\n```\n\n#### User admin\n\nTo see help output on resetting your own API key, you can run the following command:\n\n```bash\ndocker run --env-file=env.txt -it --rm $USER/cvelib:latest user reset-key -h\n```\n\nTo see help output on creating a new CNA admin user, you can run the following command:\n```bash\ndocker run --env-file=env.txt -it --rm $USER/cvelib:latest user create -h\n```\n\n### Assign a CVE ID to the vulnerability\n\nWhen a vulnerability report is received, follow the [CNA decision tree](https://cve.mitre.org/cve/cna/rules.html#Appendix_C)\nto determine if this is a valid vulnerability, in scope for the Kubernetes CNA, that has not yet been assigned a CVE ID,\nand if so, how many distinct vulnerabilities exist in the report.\n\nIf a reserved ID is not available, run the following to reserve a new CVE ID or a batch of IDs:\n\n```bash\ndocker run --env-file=env.txt -it --rm $USER/cvelib:latest reserve -h\n```\n\nAssign a reserved ID to the issue, and add at least the following information in the [tracking sheet]:\n* Date reserved\n* Description\n* 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))\n\n### Populate CVE Details after Public Disclosure \n\n1. Ensure there is a Kubernetes github issue labeled `area/security` whose title contains the CVE ID.\nThis will appear in the issue query linked from https://kubernetes.io/cve.\n1. 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)).\n1. Generate the CVElist json file\n\n * See https://github.com/CVEProject/cvelist/blob/master/2023/2xxx/CVE-2023-2727.json as an example.\n\n * 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.\n\n Fill in or update the relevant fields, including:\n * State: `PUBLIC`\n * Assigner: `security@kubernetes.io`\n * Affects: List historical minor versions affected and \"prior to 1.x.y\" patch versions affected\n * Credits: The vulnerability reporter's name\n * Description: `The Kubernetes command/component in versions `\n * Impact: CVSS impact\n * Problem type: Select a problem type from https://cwe.mitre.org/data/definitions/699.html if applicable\n * References: Link to the Kubernetes github issue(s) (with type `issue-tracking`) and mailing list announcement (with type `mailing-list`)\n * Source: Link to the Kubernetes github issue(s) and indicate if it was discovered internally or externally\n * Work around: indicate workaround steps, if applicable\n\n1. Once the cvelist json file is generated, request a review from a CNA-approved SRC member.\n1. Once the json file is reviewed, a CNA approved member should run the following to push the update\n ```bash\n 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\n ```\n1. Once the cvelist json file in https://github.com/CVEProject/cvelist is updated, indicate in the [tracking sheet] that the CVE has been populated.\n\n### Reject unused CVEs\n\nOnce a calendar year has completed, all untriaged reports from that year have been resolved,\nand no new CVE assignments for that year will be made, update any reserved but unassigned CVE IDs\nfor that calendar year to indicate they were rejected and unused.\n\n1. Run the following:\n\n ```bash\n docker run --env-file=env.txt -it --rm $USER/cvelib:latest reject -h\n ```\n\n1. Update the [tracking sheet] to indicate those CVEs were rejected (see CVE-2019-11256 through CVE-2019-11267 as an example)\n\n## Uncommon tasks\n\n### Splitting, merging, amending CVEs\n\nThis 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\n\n[tracking sheet]: https://github.com/kubernetes-security/security-disclosures#cna-tracker\n" }, { "path": "code-of-conduct.md", "content": "# Kubernetes Community Code of Conduct\n\nPlease refer to our [Kubernetes Community Code of Conduct](https://git.k8s.io/community/code-of-conduct.md)\n" }, { "path": "comms-templates/clickjacking-response.md", "content": "Thank you for your interest in helping improve the security of Kubernetes.\n\nThe 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.\n\nThank you,\n\nThe Kubernetes Security Response Committee\n" }, { "path": "comms-templates/container-vuln-response.md", "content": "Thank you for your message.\n\nBecause these are public CVEs, please use one of these public options instead:\n\n- kubernetes-security-discuss@googlegroups.com\n- open an issue: http://issues.k8s.io/new/choose\n- #kubernetes-security slack channel: http://slack.k8s.io/\n\nThank you,\n\nThe Kubernetes Security Response Committee\n" }, { "path": "comms-templates/distributors-announcement-email.md", "content": "_Use this email template for pre-disclosing security vulnerabilities to distributors-announce._\n\n_Note that distributors-announce@kubernetes.io has moderation enabled. When you send the email, remember to release the email from moderation queue._\n\nTO: `distributors-announce@kubernetes.io`\n\nSUBJECT: `[EMBARGOED] $CVE: $SUMMARY`\n\n---\n\n### EMBARGOED\n\nThe 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.\n\n_Additional details on the embargo conditions._\n- _If a patch is provided, can it be deployed?_\n- _Is the patch itself under embargo?_\n\n### Issue Details\n\nA security issue was discovered in Kubernetes where $ACTOR may be able to $DO_SOMETHING. Kubernetes clusters are only affected if $CONDITION \n\nThis issue has been rated **$SEVERITY** (link to CVSS calculator https://www.first.org/cvss/calculator/3.1) (optional: $SCORE), and assigned **$CVE_NUMBER**\n\n_Additional background and high level description of the vulnerability._\n\n### Affected Components and Configurations\n\n_How to determine if a cluster is impacted. Include:_\n- _Vulnerable configuration details_\n- _Commands that indicate whether a component, version or configuration is used_\n\n#### Affected Versions\n\n- $COMPONENT $VERSION_RANGE_1\n- $COMPONENT $VERSION_RANGE_2 ...\n- ...\n\n### Mitigations\n\n_If a patch is provided, describe it here._\n\n_(If fix has side effects)_ **Fix impact:** details of impact.\n\n_(If additional steps required after upgrade)_\n**ACTION REQUIRED:** The following steps must be taken to mitigate this\nvulnerability: ...\n\n_(If possible):_ Prior to upgrading, this vulnerability can be mitigated by ...\n\n### Detection\n\n_How can exploitation of this vulnerability be detected?_\n\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\n\nThank You,\n\n$PERSON on behalf of the Kubernetes Security Response Committee\n" }, { "path": "comms-templates/distributors-removal-email.md", "content": "TO: `$MEMBER_EMAIL`\nCC: `security-discuss-private@kubernetes.io`\nSUBJECT: `Kubernetes Disclosure List Removal Due to Uncertified Status`\n\n---\n\nHello $MEMBER-\n\nThe [Kubernetes Security Response Committee][psc] has removed $EMAIL from the distributors-announce@kubernetes.io Google Group.\n\nThis is because $PRODUCT is no longer a [certified Kubernetes Distribution][conformance], a requirement for membership to this list.\n\nIf $PRODUCT recertifies, and meets all other criteria, please submit a [request to re-join using the normal process][join-process].\n\nThank You,\n\n$PERSON on behalf of the Kubernetes Security Response Committee\n\n[src]: https://git.k8s.io/security/security-release-process.md#security-response-committee-src\n[conformance]: https://www.cncf.io/certification/software-conformance/\n[criteria]: https://git.k8s.io/security/private-distributors-list.md#membership-criteria\n[join-process]: https://git.k8s.io/security/private-distributors-list.md#request-to-join\n" }, { "path": "comms-templates/non-vuln-response.md", "content": "Thank you for your message.\n\nIt appears this report is neither a vulnerability report nor a security incident. Consider one of these public options instead:\n\n- kubernetes-security-discuss@googlegroups.com\n- open an issue: http://issues.k8s.io/new/choose\n- #kubernetes-security slack channel: http://slack.k8s.io/\n\nThank you,\n\nThe Kubernetes Security Response Committee" }, { "path": "comms-templates/spf-record-response.md", "content": "Thank you for your interest in helping improve the security of Kubernetes.\n\nKubernetes 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.\n\nThank you,\n\nThe Kubernetes Security Response Committee\n" }, { "path": "comms-templates/vulnerability-announcement-email.md", "content": "_Use this email template for publicly disclosing security vulnerabilities._\n\n_The email should be **concise** and **actionable**. Assume the audience are not\nKubernetes developers. Non-actionable information (e.g. technical discussion of\nthe vulnerability) should be deferred to the [vulnerability\nissue](vulnerability-announcement-issue.md)._\n\nTO: `kubernetes-announce@googlegroups.com, dev@kubernetes.io, kubernetes-security-announce@googlegroups.com, kubernetes-security-discuss@googlegroups.com, distributors-announce@kubernetes.io`\n\nSUBJECT: `[Security Advisory] $CVE: $SUMMARY`\n\n_A separate email should be sent for `oss-security@lists.openwall.com`, with `[kubernetes]` in the subject:_\n\nTO: `oss-security@lists.openwall.com`\n\nSUBJECT: `[kubernetes] $CVE: $SUMMARY`\n\n_A separate email should be sent to the forum from the `security@kubernetes.io` Google group and cc `kubernetes+announcements@discoursemail.com`:_\n\nTO: `security@kubernetes.io`\ncc: `kubernetes+announcements@discoursemail.com`\n\nSUBJECT: `[Security Advisory] $CVE: $SUMMARY`\n\n_See [Fix disclosure process](security-release-process.md#fix-disclosure-process) for additional places the announcement should be posted._\n\n---\n\nHello Kubernetes Community,\n\nA security issue was discovered in Kubernetes where $ACTOR may be able to $DO_SOMETHING.\n\nThis issue has been rated **$SEVERITY** (link to CVSS calculator https://www.first.org/cvss/calculator/3.1) (optional: $SCORE), and assigned **$CVE_NUMBER**\n\n### Am I vulnerable?\n\n_How to determine if a cluster is impacted. Include:_\n- _Vulnerable configuration details_\n- _Commands that indicate whether a component, version or configuration is used_\n\n#### Affected Versions\n\n- $COMPONENT $VERSION_RANGE_1\n- $COMPONENT $VERSION_RANGE_2 ...\n- ...\n\n### How do I mitigate this vulnerability?\n\n_(If additional steps required after upgrade)_\n**ACTION REQUIRED:** The following steps must be taken to mitigate this vulnerability: ...\n\n_(If possible):_ Prior to upgrading, this vulnerability can be mitigated by ...\n\n#### Fixed Versions\n\n- $COMPONENT $VERSION\n- $COMPONENT $VERSION\n- ...\n\n_(If fix has side effects)_ **Fix impact:** details of impact.\n\nTo upgrade, refer to the documentation: ... ($COMPONENT upgrade documentation)\n\n_For core Kubernetes:_ https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade/\n\n### Detection\n\n_How can exploitation of this vulnerability be detected?_\n\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\n\n#### Additional Details\n\nSee the GitHub issue for more details: $GITHUBISSUEURL\n\n#### Acknowledgements\n\nThis vulnerability was reported by $REPORTER.\n\n_(optional):_ The issue was fixed and coordinated by $FIXTEAM and $RELEASE_MANAGERS.\n\nThank You,\n\n$PERSON on behalf of the Kubernetes Security Response Committee\n" }, { "path": "comms-templates/vulnerability-announcement-issue.md", "content": "_Use this issue template for filling out CVE placeholder issues._\n\nTITLE: `CVE-####-######: $SUMMARY`\n\n---\n\n\nCVSS 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)\n\n_Description of vulnerability_\n\n\n\n### Am I vulnerable?\n\n_How to determine if a cluster is impacted. Include:_\n- _Vulnerable configuration details_\n- _Commands that indicate whether a component, version or configuration is used_\n\n#### Affected Versions\n\n- $COMPONENT $VERSION_RANGE_1\n- $COMPONENT $VERSION_RANGE_2 ...\n- ...\n\n### How do I mitigate this vulnerability?\n\n_(If additional steps required after upgrade)_\n**ACTION REQUIRED:** The following steps must be taken to mitigate this\nvulnerability: ...\n\n_(If possible):_ Prior to upgrading, this vulnerability can be mitigated by ...\n\n#### Fixed Versions\n\n\n- $COMPONENT main/master - fixed by #12345678\n- ...\n\n_(If fix has side effects)_ **Fix impact:** details of impact.\n\nTo upgrade, refer to the documentation: ... ($COMPONENT upgrade documentation)\n\n_For core Kubernetes:_ https://kubernetes.io/docs/tasks/administer-cluster/cluster-upgrade\n\n### Detection\n\n_How can exploitation of this vulnerability be detected?_\n\nIf you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io\n\n## Additional Details\n\n_Optional details:_\n- Vulnerability background\n- Technical explanation of vulnerability and/or fix\n- Reproduction steps (avoid disclosing unnecessary details)\n\n#### Acknowledgements\n\nThis vulnerability was reported by $REPORTER.\n\n_(optional):_ The issue was fixed and coordinated by $FIXTEAM and $RELEASE_MANAGERS.\n\n\n/area security\n/kind bug\n/committee security-response\n/label official-cve-feed\n/sig $RELEVANT_SIGS\n/area $IMPACTED_COMPONENTS\n" }, { "path": "comms-templates/vulnerability-announcement-placeholder-issue.md", "content": "_Use this issue template for filing CVE placeholder issues._\n\nTITLE: PLACEHOLDER ISSUE\n\n---\n\n/triage accepted\n/lifecycle frozen\n/area security\n/kind bug\n/committee security-response\n" }, { "path": "comms-templates/vulnerability-announcement-slack.md", "content": "_Use this slack message template for publicly disclosing security vulnerabilities on slack._\n\n_This message should be posted to the `#announcements` channel, which requires special permissions._\n\n---\n\nThe Security Response Committee has posted a security advisory for $COMPONENT that $SUMMARY. This\nissue has been rated **$SEVERITY** and assigned **$CVE**. Please see $ISSUE for more details.\n\n---\n\n_Example_\n\nThe Security Response Committee has posted a security advisory for the kube-apiserver that could\nallow node updates to bypass a Validating Admission Webhook. This issue has been rated **Medium**\nand assigned **CVE-2021-25735**. Please see https://github.com/kubernetes/kubernetes/issues/100096\nfor more details.\n" }, { "path": "cve-requests.md", "content": "# CVE Number Requests\n\nThe Kubernetes project is a registered [CVE Numbering Authority](http://cve.mitre.org/cve/request_id.html#k) (CNA) with MITRE.\n\nRequests for CVE numbers for components residing within https://github.com/kubernetes/kubernetes\nshould be directed to [security@kubernetes.io](mailto:security@kubernetes.io).\n\nCVE numbers are typically requested by the fix lead for a particular issue as part of the [security release process](security-release-process.md).\n" }, { "path": "emeritus.md", "content": "Emeritus committee members:\n\n- Brandon Philips (**[@philips](https://github.com/philips)**) ``\n- Jess Frazelle (**[@jessfraz](https://github.com/jessfraz)**) ``\n- Jonathan Pulsifer (**[@jonpulsifer](https://github.com/jonpulsifer)**) ``\n- Jordan Liggitt (**[@liggitt](https://github.com/liggitt)**) `` [4096R/0x39928704103C7229]\n- Swamy Shivaganga Nagaraju (**[@swamymsft](https://github.com/swamymsft)**) ``\n- Tim Allclair (**[@tallclair](https://github.com/tallclair)**) ``\n- Luke Hinds (**[@lukehinds](https://github.com/lukehinds)**) `lhinds@protonmail.com`\n- Sri Saran Balaji (**[@SaranBalaji90](https://github.com/SaranBalaji90)**) ``\n- Craig Ingram (**[@cji](https://github.com/cji)**) ``\n- Rita Zhang (**[@ritazh](https://github.com/ritazh)**) ``\n" }, { "path": "playbook/token-leak-process.md", "content": "# GitHub Token Leak Response Process\n\nThe 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.\n\n## Investigate\n\n* Thank the reporter -- they have done us a kindness by letting us know about the problem\n* If you can, get the first few characters of the leaked token in case GitHub support needs it for revocation\n* Check to see if the user is an OWNER - an OWNER token leak would be more severe than that of an ordinary Org member\n * https://cs.k8s.io/?i=fosho&files=OWNERS&q=the-user-name-goes-here\n\n## Contact\n\n* 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.\n>Dear `USER`,\n>\n>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\").\n>\n>Please revoke the leaked GitHub token, to protect yourself and your projects. Let us know if you need any further information.\n>\n>Best,\n>\n>`YOUR NAME HERE` \n>Kubernetes SRC\n* 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\n* 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”\n## Followup\n* Perform any necessary incident response as identified with the SRC, ContribEx, and Steering\n" }, { "path": "private-distributors-list.md", "content": "## Private Distributors List\n\nThis list is used to provide actionable information to multiple distribution\nvendors at once. This list is not intended for individuals to find out about\nsecurity issues.\n\n### Embargo Policy\n\nThe patch files and any derived patched binaries are included in the embargo, \nand must not be distributed or made available to external parties before the \npublic disclosure is made.\n\nHowever, a fully-hosted patched kube-apiserver can be deployed \nprior 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.\n\nOther fully-hosted patched components can also be deployed prior to the embargo \nlift date only if all users with access to the components and/or\nclusters are internal to the Kubernetes distributor.\n\nMembers of distributors-announce@kubernetes.io must share list information only\nwithin their teams, on a need-to-know basis to get the related issue fixed in\ntheir distribution. The information members and others receive from the list\nmust not be made public, shared, nor even hinted at otherwise, except with the\nlist's explicit approval. This holds true until the public disclosure date/time\nthat was agreed upon by the list.\n\nBefore any information from the list is shared with respective members of your\nteam required to fix an issue, they must agree to the same terms and only\nfind out information on a need-to-know basis.\n\nAs a clarifying example, this policy forbids SRC members (or others who don't\nwork on a distribution) from sharing list information with their non-distributor\nemployers.\n\nIn the unfortunate event you share the information beyond what is allowed by\nthis policy, you _must_ urgently inform the security@kubernetes.io mailing list\nof exactly what information leaked and to whom, as well as the steps that will\nbe taken to prevent future leaks.\n\nRepeated offenses may lead to the removal from the distributors list.\n\n### Contributing Back\n\nThis is a team effort. As a member of the list you must carry some water. This\ncould be in the form of the following:\n\n- Review and/or test the proposed patches and point out potential issues with\n them (such as incomplete fixes for the originally reported issues, additional\n issues you might notice, and newly introduced bugs), and inform the list of the\n work done even if no issues were encountered.\n\n### Membership\n\nGroup membership is managed through the Kubernetes domain group administration\nconfiguration: http://git.k8s.io/k8s.io/groups/committee-security-response/groups.yaml,\nunder the `distributors-announce` section.\n\n### Membership Criteria\n\nTo be eligible for the distributors-announce@kubernetes.io mailing list, your\ndistribution should:\n\n0. Have an actively monitored security email alias for our project.\n1. Be an actively maintained and [CNCF certified distribution of\n Kubernetes][conformance] components.\n2. Have a user base not limited to your own organization.\n3. Have a publicly verifiable track record up to present day of fixing security\n issues.\n4. Not be a downstream or rebuild of another distribution.\n5. Be a participant and active contributor in the community.\n6. Accept the [Embargo Policy](#embargo-policy) that is outlined above.\n7. Be willing to [contribute back](#contributing-back) as outlined above.\n8. Have someone already on the list vouch for the person requesting membership\n on behalf of your distribution.\n\n[conformance]: https://www.cncf.io/certification/software-conformance/\n\n**Removal**: If your distribution stops meeting one or more of these criteria\nafter joining the list then you will be unsubscribed.\n\n### Request to Join\n\nFile an issue\n[here](https://github.com/kubernetes/security/issues/new?template=distributors-application.md),\nfilling in the criteria template.\n" }, { "path": "security-release-process.md", "content": "# Security Release Process\n\nKubernetes 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.\n\n\n- [Security Response Committee (SRC)](#security-response-committee-src)\n - [Security Response Committee Membership](#security-response-committee-membership)\n - [Nomination](#nomination)\n - [Member selection](#member-selection)\n - [Stepping Down](#stepping-down)\n - [Responsibilities](#responsibilities)\n - [Incident Commander](#incident-commander)\n - [Triage](#triage)\n - [SIG Release Roles](#sig-release-roles)\n- [Disclosures](#disclosures)\n - [Private Disclosure Processes](#private-disclosure-processes)\n - [Public Disclosure Processes](#public-disclosure-processes)\n- [Patch, Release, and Public Communication](#patch-release-and-public-communication)\n - [Fix Team Organization](#fix-team-organization)\n - [Fix Development Process](#fix-development-process)\n - [Fix Disclosure Process](#fix-disclosure-process)\n- [Private Distributors List](#private-distributors-list)\n- [Retrospective](#retrospective)\n- [Severity](#severity)\n- [Severity Thresholds - How We Do Vulnerability Scoring](#severity-thresholds---how-we-do-vulnerability-scoring)\n\n\n## Security Response Committee (SRC)\n\nSecurity 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.\n\nThe [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.\n\n### Security Response Committee Membership\n\nNew SRC members are nominated by current SRC members, and selected by the\n[steering committee](https://github.com/kubernetes/community/tree/master/committee-steering).\n\nThe SRC is currently capped at 10 members.\n\n#### Nomination\n\nNew members are nominated to the SRC by current SRC members. If you are interested in joining the\nSRC, the best way to secure a nomination is through sustained participation and contributions in the\nKubernetes security community.\n\nTo 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.\n\nA nomination should include:\n1. Relevant credentials, including Kubernetes and security experience\n2. Statement of support from the nominating SRC member(s): ~1-3 sentences of why this person is a good candidate.\n3. Statement of intent from the nominee: ~1-3 sentences of why they want to join the committee and are a good fit.\n\nIn the event that an SRC member has concerns with a nomination, they should privately reach out to\nthe steering committee via steering-private@kubernetes.io.\n\nNominations will be collected into a private Google doc shared between the SRC and Steering.\n\nNominations may be reused for new openings, but in that case both the SRC member and nominee should\nreconfirm (or update) their statements.\n\n#### Member selection\n\nAfter the nomination deadline is passed, nominations will be shared with the Steering Committee.\nSteering is encouraged to discuss the nominations in the next private monthly meeting, and reach out\nto the SRC with any questions.\n\nThe final selection is made by discussion & lazy consensus, with a fallback to a vote.\n\nIn the event that an individual is on both the SRC and Steering Committee, they will be expected to\nexcuse themselves from the steering discussion & selection process (but may submit SRC nominations).\n\n#### Stepping Down\n\nMembers may step down at anytime, and may nominate a replacement when they do.\n\n#### Responsibilities\n\n- Members should remain active and responsive, and participate in the [oncall rotation](src-oncall.md).\n- 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.\n- Longer leaves of absense should be discussed on a case-by-case basis.\n- 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.\n\nNew members are *not* expected to join the oncall rotation immediately, but are expected to start\nlearning the processes and ramping up. During that time, they are expected to complete a shadow and\nreverse shadow rotation. The ramp-up time does not need to be formalized, but 2-3 months should be a\nreasonable expectation.\n\n##### Incident Commander\n\nOne of the primary responsibilities of the SRC is to coordinate incident response when a\nvulnerability is discovered. The incident commander is responsible for coordinating all the\ndifferent parts of the security release process (but not handling all those responsibilities\nthemselves), and seeing the incident through to the end (or handing off).\n\nThe incident commander defaults to the current oncall, but may be handed off to other SRC or Kubernetes maintainers.\n\n##### Triage\n\nThe current oncall is responsible for triaging incoming vulnerability reports (both through the bug\nbounty and email). For more details on the triage process, see [oncall\nworkflow](SRC-oncall.md).\n\n#### SIG Release Roles\n\nIncluded on the [private Release Managers list](https://groups.google.com/a/kubernetes.io/forum/#!forum/release-managers-private)\nare the following members:\n\n- [Release Managers](https://github.com/kubernetes/website/blob/main/content/en/releases/release-managers.md#release-managers)\n(manage build and release aspects when a security fix must be delivered)\n- [SIG Release Chairs](https://github.com/kubernetes/website/blob/main/content/en/releases/release-managers.md#chairs)\n\nIt is the responsibility of the [SIG Release Chairs](https://github.com/kubernetes/website/blob/main/content/en/releases/release-managers.md#chairs)\nto curate and maintain the various release role access controls across release cycles.\n\n## Disclosures\n\n### Private Disclosure Processes\n\nThe 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).\n\n### Public Disclosure Processes\n\nIf 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.\n\nIf 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.\n\n## Patch, Release, and Public Communication\n\nFor each vulnerability a member of the SRC will volunteer to lead coordination\nwith the Fix Team and Release Managers, and is responsible for sending disclosure\nemails to the rest of the community. This lead will be referred to as the Fix Lead.\n\nThe role of Fix Lead should rotate round-robin across the SRC.\n\nAll of the timelines below are suggestions and assume a Private Disclosure.\nThe Fix Lead drives the schedule using their best judgment based on severity,\ndevelopment time, and release manager feedback. If the Fix Lead is dealing with\na Public Disclosure all timelines become ASAP. If the fix relies on another\nupstream project's disclosure timeline, that will adjust the process as well.\nWe will work with the upstream project to fit their timeline and best protect\nour users.\n\n### Fix Team Organization\n\nThese steps should be completed within the first 24 hours of Disclosure.\n\n- 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.\n- 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.\n- 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.\n\nNote: 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).\n\n### Fix Development Process\n\nThese steps should be completed within the 1-7 days of Disclosure.\n\n- 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.\n- 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).\n- 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.\n\nIf the CVSS score is under ~4.0\n([a low severity score](https://www.first.org/cvss/specification-document#i5))\nor the assessed risk is low the Fix Team can decide to slow the release process\ndown in the face of holidays, developer bandwidth, etc. These decisions must be\ndiscussed on the security@kubernetes.io mailing list.\n\nIf the CVSS score is under ~7.0 (a medium severity score), the Fix Lead may\nchoose to carry out the fix semi-publicly. This means that PRs are made directly\nin the public kubernetes/kubernetes repo, while restricting discussion of the\nsecurity aspects to private channels. The fix lead will make the determination\nwhether there would be user harm in handling the fix publicly that outweighs the\nbenefits of open engagement with the community.\n\nCritical 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).\n\nNote: CVSS is convenient but imperfect. Ultimately, the Fix Lead has discretion\non classifying the severity of a vulnerability.\n\nNo matter the CVSS score, if the vulnerability requires\n[User Interaction](https://www.first.org/cvss/user-guide#5-4-User-Interaction),\nespecially in client components like kubectl, or otherwise has a\nstraightforward, non-disruptive mitigation, the Fix Lead may choose to disclose\nthe vulnerability before a fix is developed if they determine that users would\nbe better off being warned against a specific interaction.\n\n### Low CVEs that can Skip Private Disclosures\nSometimes a Low CVE may not require private disclosures, Fix lead should facilitate:\n- 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.\n- BEFORE the next patch releases are out, Fix lead to provide the CVE feed yaml to the release team.\n- 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.\n\n### Fix Disclosure Process\n\nWith 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.\n\n**Advance Vulnerability Disclosure to Private Distributors List** (Completed within 1-4 weeks prior to public disclosure):\n\n- 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.\n- **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.\n\n**Fix Release Day**\n\nRelease process:\n- The Fix Lead will cherry-pick the patches onto the master branch and all relevant release branches. The Fix Team will `/lgtm` and `/approve`.\n- 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.\n- The Release Managers will ensure all the binaries are built, publicly available, and functional.\n- The Fix Lead will remove the Fix Team from the private security repo once it is no longer needed.\n\nCommunications process:\n- The [Private Distributors List](#private-distributors-list) will be notified at least 24 hours in\n advance of a pending release containing security vulnerability fixes with the public messaging,\n date, and time of the announcement.\n- The Fix Lead will announce the new releases, the CVE number, severity, and impact, and the\n location of the binaries to get wide distribution and user action. As much as possible this\n announcement should be actionable, and include any mitigating steps users can take prior to\n upgrading to a fixed version. The recommended target time is 4pm UTC on a non-Friday weekday. This\n means the announcement will be seen morning Pacific, early evening Europe, and late evening Asia.\n The announcement will be sent via the following channels:\n - General announcement email ([template](comms-templates/vulnerability-announcement-email.md)) to\n multiple Kubernetes lists\n - OSS-Security announcement email\n ([template](comms-templates/vulnerability-announcement-email.md)) to\n `oss-security@lists.openwall.com`\n - `#announcements` slack channel ([template](comms-templates/vulnerability-announcement-slack.md))\n - [discuss.kubernetes.io](https://discuss.kubernetes.io/c/announcements) forum (this should be\n posted automatically using the general announcement email template)\n - Tracking issue opened in https://github.com/kubernetes/kubernetes/issues\n ([template](comms-templates/vulnerability-announcement-issue.md)) and prefixed with the \n 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. \n - Once all communications are sent, fixes are released, and the CVE data has been populated, close out the public tracking issue.\n - Medium and Low severity vulnerability fixes that will be released as part of the next Kubernetes\n [patch release](https://github.com/kubernetes/website/blob/main/content/en/releases/patch-releases.md)\n will have the fix details included in the patch release notes. Any public announcement sent for\n these fixes will link to the release notes.\n - 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\n - After public disclosure, [populate CVE details as soon as possible](/cna-handbook.md#populate-cve-details-after-public-disclosure)\n\n## Private Distributors List\n\nThis list is used to provide actionable information to multiple distribution\nvendors at once.\n\nSee the [private distributor list doc](private-distributors-list.md) for more information.\n\n## Retrospective\n\nThese 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).\n\n- 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.\n- 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.\n\n## Severity\n\nThe Security Response Committee evaluates vulnerability severity on a case-by-case basis, guided by\n[CVSS 3.1](https://www.first.org/cvss/v3.1/specification-document).\n\nTODO(#147): Document a guide to how the SRC interprets CVSS for Kubernetes.\n\n## Severity Thresholds - How We Do Vulnerability Scoring\n\nMoved to [Severity Ratings](severity-ratings.md).\n" }, { "path": "severity-ratings.md", "content": "# Severity Ratings\n\nThe Security Response Committee evaluates vulnerability severity on a case-by-case basis, guided by\n[CVSS 3.1](https://www.first.org/cvss/v3.1/specification-document). If you have questions about why\na vulnerability is rated the way it is, please feel free to comment on the associated GitHub\ntracking issue.\n\n## Severity Thresholds - Heuristics\n\nThe content presented below outlines basic heuristics for considering the effect\nof bugs disclosed to the Security Response Committee and their severity. These apply\nmostly to items in \"core\" Kubernetes but could be abstractly applied to those in other\ncomponents as well.\n\n### Server\n\nThe \"server\" pertains to any \"server-side components\" (see below) we distribute,\nbut you can specifically think of `kube-apiserver` and `kubelet` being the main ones.\n\n\"Server-side components\" pertains to:\n\n- Components built from source in the `kubernetes` github organization and\n [all current organizations in use](https://git.k8s.io/community/github-management/README.md#actively-used-github-organizations)\n- Container images under the `k8s.gcr.io` and `registry.k8s.io` repositories\n- Containers included in the [core addons directory](https://git.k8s.io/kubernetes/cluster/addons)\n\nThe server classification is usually not appropriate when user interaction\nis part of the exploitation process, those should fall under the\n[client](#client) classifications as \"client\" implies user interaction with a\nclient.\nIf a \"Critical\" vulnerability exists only on server\ncomponents, and is exploited in a way that requires user interaction and results\nin the compromise of the server, the severity may be reduced from \"Critical\" to\n\"High\" in accordance with the data definition of extensive user\ninteraction presented at the start of the client severity pivot.\n\n#### Critical\n\nNetwork worms or _unavoidable_ cases where the server is \"compromised.\"\n\n##### Elevation of privilege\n\nThe ability to either execute arbitrary code or obtain more privilege than\nauthorized.\n\n- [Remote Anonymous User](#remote-anonymous-user)\n - Unauthorized access. Examples:\n - read, write, or delete access to sensitive API objects\n - arbitrary writing/deletion to the file system or anywhere in the\n cluster that should not typically be modifiable\n - getting data from the server or server components\n - Execution of arbitrary code (remote code execution in the server)\n\nThis includes all write access violations.\n\n##### Information disclosure (targeted)\n\nCases where an unprivileged user can locate and read highly sensitive\ninformation from anywhere on the system, including system information that was\nnot intended or designed to be exposed.\n\n- [Remote Anonymous User](#remote-anonymous-user)\n - Unauthorized access. Examples:\n - Personally identifiable information (PII) disclosure\n (email addresses, cloud provider credentials)\n - Attacker can collect private data without user consent or in a covert fashion\n - Secrets data\n - System credentials\n\n#### High\n\n\"Critical\" attacks are downgraded to \"High\" when requiring\n[adjacent network access](#adjacent-network-access).\n\nNon-default (or non-typical) critical scenarios or cases where\nmitigations exist that can help prevent critical scenarios.\n\n##### Denial of service\n\nMust be \"easy to exploit\" by sending a small amount of data or be otherwise\nquickly induced.\n\n- [Remote Anonymous User](#remote-anonymous-user)\n - Persistent DoS. Examples:\n - Sending a single malicious request results in\n [service failure](#service-failure)\n - Sending a small number of requests that causes a\n [service failure](#service-failure)\n - Temporary DoS. Examples:\n - Sending a small number of requests that causes the system to be\n unusable for a period of time\n - Server being down for a minute or longer\n - A single remote client consuming all available resources\n (sessions, memory) on a server by establishing sessions and keeping them open\n\n- [Authenticated User](#authenticated-user)\n - Persistent DoS against a [high value asset](#high-value-asset). Example:\n - Sending a small number of requests that causes a\n [service failure](#service-failure) for a\n [high value asset](#high-value-asset)\n\n##### Elevation of privilege\n\nThe ability to either execute arbitrary code or obtain more privilege than\nauthorized. This includes all write access violations.\n\n- [Authenticated User](#authenticated-user)\n - Unauthorized access. Examples:\n - arbitrary writing to the file system or server components like etcd,\n where the user should not have the ability to write\n - reading or writing to API objects where the user should not be able\n to\n - getting data from the server or server components, where the user\n should not have the ability to read\n - execution of arbitrary code (like creating a pod or remote code execution\n attacks)\n\nBreaking or bypassing any security feature provided. A vulnerability in a\nsecurity feature is rated “High” by default, but the rating may be adjusted\nbased on other considerations as documented here.\n\nExamples:\n- Disabling or bypassing a `NetworkPolicy` or `PodSecurityPolicy` without\ninforming users or gaining consent\n- Reconfiguring a `NetworkPolicy` and allowing connections to other processes\nwithout consent\n\nAn entity (computer, server, user, process) is able to masquerade as a\nspecific entity (user or computer) of his/her choice.\n\nExamples:\n- Service masquerades as the API server for the cluster and effectively\n man-in-the-middle's the real API server.\n- API server uses client certificate authentication (SSL) improperly to allow\n an attacker to be identified as any user of his/her choice\n- RBAC bug that allows a malicious remote user to be seen as a different user\n of his or her choice\n\n\n##### Information disclosure (targeted)\n\nCases where an anonymous user can easily read sensitive information on the\nsystem from specific locations, including system information that was not\nintended/designed to be exposed.\n\nExamples:\n\n- Targeted disclosure of the existence of an arbitrary file\n- Arbitrary filesystem or application data that should not typically be accessed\n- Arbitrary API resources that should not typically be accessed\n- Workload & namespace names or identifying metadata\n- System & workload logs that are not typically exposed\n- Workload or user-created metrics\n\n#### Medium\n\n\"High\" attacks are downgraded to \"Medium\" when requiring [local\naccess](#local-access) or when there is a straight-forward mitigation.\n\n##### Information disclosure (targeted)\n\nCases where an anonymous user can easily read anonymous (non-sensitive)\ninformation on the system, including system metrics that were not intended to be\nexposed.\n\nExamples:\n\n- System metrics common to most Kubernetes installs that were not intended to be\n public\n- Non-identifying workload metadata (e.g. UIDs, creationTimestamps,\n resourceVersions)\n\n#### Low\n\n\"Medium\" attacks are downgraded to \"Low\" when there is a straight-forward\nmitigation and the attack requires quite a few non-default or very untypical\nscenarios to trigger.\n\n##### Tampering\n\nTemporary modification of data in a specific scenario that does not persist.\n\n### Client\n\n\"User interaction\" can only happen in client-driven scenario.\n\nUsing `kubectl` or a client library are considered user interaction.\n\nThe target is a user or user's computer in these scenarios.\n\nThe effect of user interaction is not one level reduction in severity,\nbut is a reduction in severity in certain circumstances where user interaction\nis required.\n\nThe distinction exists to help differentiate\nfast-spreading and wormable attacks from those where because\nthe user interacts, the attack is slowed down.\n\n#### Critical\n\nNetwork worms or _unavoidable_ cases where the client is \"compromised\" without\nwarnings or prompts.\n\n##### Elevation of privilege\n\nThe ability to either execute arbitrary code or obtain more privilege than\nauthorized. This includes all write access violations.\n\n- [Remote Anonymous User](#remote-anonymous-user)\n - Unauthorized access. Examples:\n - read, write, and delete access to sensitive API objects\n - arbitrary writing/reading/deletion to/from the file system\n - Execution of arbitrary code (remote code execution on the client's system)\n\n##### Information disclosure (targeted)\n\nCases where the attacker can locate and read information from anywhere on the\nsystem, including system information that was not intended or designed to be\nexposed.\n\n- [Remote Anonymous User](#remote-anonymous-user)\n - Unauthorized access. Examples:\n - Personally identifiable information (PII) disclosure (email addresses, local data)\n - Client \"phone-ing home\" without permission\n\n#### High\n\nNon-default critical scenarios or cases where mitigations exist that can help\nprevent critical scenarios.\n\n##### Denial of service\n\nSystem corruption DoS requires re-installation of system and/or components.\n\nExamples:\n\n- Calling a `kubectl` command makes the local machine unbootable.\n\n##### Elevation of privilege\n\nThe ability to either execute arbitrary code or obtain more privilege than\nauthorized. This includes all write access violations.\n\n- [Authenticated User](#authenticated-user)\n - Unauthorized access. Examples:\n - arbitrary writing/deletion on the file system,\n where the user should not have the ability to do so\n - reading or writing to API objects where the user should not be able\n to\n - local low privilege user can elevate themselves to another user,\n administrator, or local system.\n - Execution of arbitrary code (remote code execution via the client)\n\nBreaking or bypassing any security feature provided. A vulnerability in a\nsecurity feature is rated “High” by default, but the rating may be adjusted\nbased on other considerations as documented here.\n\nExamples:\n- Disabling or bypassing a RBAC without informing users or gaining consent\n- Reconfiguring RBAC without consent\n\n##### Tampering\n\nModification of any user data or data used to make trust decisions\nin a common or default scenario where the modification persists.\nThis includes permanent or persistent modification of any user or system data\nused in a common or default scenario.\n\nExamples:\n\n- Modification of application data files such as `~/.kube` in a specific\n scenario\n- Modification of cluster or objects without user consent in a specific scenario\n\n#### Medium\n\n##### Tampering\n\nModification of any user data or data used to make trust decisions\nin a specific scenario where the modification persists.\nThis includes permanent or persistent modification of any user or system data\nused in a specific scenario.\n\nExamples:\n\n- Modification of application data files such as `~/.kube` in a specific scenario\n- Modification of cluster or objects without user consent in a specific scenario\n\n#### Low\n\n##### Denial of service\n\nTemporary DoS requires restart of the client application.\n\nExample:\n\n- Running a `kubectl` command crashes itself or the API server in a way that is\n recoverable.\n\n##### Tampering\n\nTemporary modification of data in a specific scenario that does not persist.\n\n### Glossary\n\n#### Adjacent Network Access\n\nOn the private network. They can access internal IP addresses.\n\n#### Authenticated User\n\nAn authenticated user can be:\n\n- Unprivileged: authenticated, but with no privileges\n- Privileged: authenticated, with some privileges\n\n#### Local Access\n\nOn the same physical host (or VM).\n\n#### Remote Anonymous User\n\nRemote implies from an arbitrary network location. The attacker can only access\nexternally exposed, public facing IP addresses.\n\nAnonymous implies the attacker requires no credentials or Authentication.\n\n#### High Value Asset\n\nA mission critical component such that if/when it has failed the entire cluster\nis unusable. For example, if the master services/nodes are\nunreachable or in a failure mode, the entire cluster is basically unusable.\n\n#### Service Failure\n\nFailure in such a way that the system/service requires intervention from\na human operator to recover.\n" }, { "path": "src-onboarding-offboarding.md", "content": "# On-boarding / Off-boarding Procedure for Security Response Committee Members\n\nThis document outlines the process for individual(s) both joining or leaving\nthe Kubernetes SRC (Security Response Committee).\n\nFor the purpose of example, we will use a placeholder name of **Jane Doe** with\na github username **`jdoe`** and a company name of **ACME LTD**.\n\n\n- [Required file and access grant updates.](#required-file-and-access-grant-updates)\n - [kubernetes/committee-security-response repository](#kubernetessecurity-repository)\n - [kubernetes/k8s.io repository](#kubernetesk8sio-repository)\n - [kubernetes/community repository](#kubernetescommunity-repository)\n - [kubernetes/org repository](#kubernetesorg-repository)\n - [Add/remove from HackerOne](#addremove-from-hackerone)\n - [Add/remove from OpsGenie rotation](#addremove-from-opsgenie-rotation)\n - [Add/ Remove SRC Owner permission from Kubernetes Security Mailing Lists](#add-remove-src-owner-permission-from-kubernetes-security-mailing-lists)\n - [Discuss Account](#discuss-account)\n - [kubernetes-security github org](#kubernetes-security-github-org)\n - [Slack](#slack)\n - [Calendar](#calendar)\n - [Google Docs](#google-docs)\n- [Checklist](#checklist)\n\n\n### Required file and access grant updates.\n\nOnce the SRC has promoted an individual(s) to a full SRC member, various\nsystems require updating. Likewise, should a SRC member leave the SRC - the\nreverse is required, with the user being removed from each system.\n\n#### kubernetes/committee-security-response repository\n\nAll SRC member discussion & approval must happen on the `kubernetes/committee-security-response`\nrepository first and only once approved by means of the pull request being\nmerged, should pull requests be approved / merged in the `kubernetes/community`\nrepository, and the user added to the mailing lists and ACLs.\n\n##### file: https://github.com/kubernetes/committee-security-response/blob/master/README.md\n\nAdd / remove the SRC member(s) github name from `committee-security-response/README.md`\nto the appropriate list of committee members, according to the usernames\nalphabetical placing.\n\n```\nThe 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:\n\n- Jane Doe (**[@jdoe](https://github.com/jdoe)**) `` [GPG_KEY]\n```\n\nIf removing a SRC member, move them to the list of emeritus members.\n\n##### file: https://github.com/kubernetes/committee-security-response/blob/master/OWNERS_ALIASES\n\nAdd / remove the SRC member(s) github name from `committee-security-response/OWNERS_ALIASES` to the\nexisting `security-response-committee` field, according to the usernames\nalphabetical placing:\n\n```yaml\naliases:\n security-response-committee:\n - jdoe\n```\n\n#### kubernetes/k8s.io repository\n\n##### file: https://github.com/kubernetes/k8s.io/blob/main/groups/committee-security-response/groups.yaml\n\n`groups.yaml` is the source of truth for membership to the\nsecurity-response-committee mailing lists. Update the `owners` field for the\nfollowing lists:\n\n- `security@kubernetes.io`\n- `security-discuss-private@kubernetes.io`\n- `distributors-announce@kubernetes.io`\n\nEnsure the 3 lists match.\n\n##### file: https://github.com/kubernetes/k8s.io/blob/main/OWNERS_ALIASES\n\n```yaml\naliases:\n security-response-committee:\n - jdoe\n```\n\n#### kubernetes/community repository\n\n##### file: https://github.com/kubernetes/community/blob/master/sigs.yaml\n\nAdd / remove the SRC member(s) github name from `community/sigs.yaml` to the\nexisting `label`| `leadership` field, according to the usernames alphabetical\nplacing:\n\n```yaml\nlabel: security-response\n leadership:\n chairs:\n - github: jdoe\n name: Jane Doe\n company: Acme LTD\n```\n\nOnce the yaml is updated, run `make generate` to regenerate the markdown\nversions.\n\nThis will then automatically create the following files:\n\n* kubernetes/community/OWNERS_ALIASES\n* kubernetes/community/security-response-committee/README.md\n* kubernetes/community/sig-list.md\n\n##### file: https://github.com/kubernetes/community/blob/master/communication/slack-config/usergroups.yaml\n\nAdd / remove the SRC member(s) github name from the `security-response-committee` user group.\n\n#### kubernetes/org repository\n\n##### file: https://github.com/kubernetes/org/blob/master/config/kubernetes/org.yaml\n\nAdd / remove the SRC member(s) github username from `config/kubernetes/org.yaml`\nto the existing `security-response-committee` | `members` field. The usernames\nshould be alphabetized:\n\n```yaml\n security-response-committee:\n description: Please report security issues to https://kubernetes.io/security\n members:\n - alice\n - bob\n - jdoe\n```\n\nOnce merged, [peribolos](https://git.k8s.io/test-infra/prow/cmd/peribolos) will\nautomatically run and update the members of the GitHub group\nhttps://github.com/orgs/kubernetes/teams/security-response-committee\n\n#### Add/remove from HackerOne\n\nTo add or remove members from the Kubernetes HackerOne project, navigate to\nhttps://hackerone.com/organizations/linux_foundation/settings/users\n\nClick `Remove` next to a member to remove.\n\nClick `Invite user` to add a new SRC member. Add them to the `Kubernetes Team`,\n`Standard` and `Admin` groups.\n\nWe also request that new members enable 2-factor auth. Once they've accepted the\ninvitation, you can verify the status in the `2FA` column on the user management\npage.\n\nAfter verifying 2FA status, make the new member an \"Organization Administrator\"\nby selecting \"Edit user\" from the context menu, then enabling \"Organization\nAdministrator\".\n\n#### Add/remove from OpsGenie rotation\n\n##### url: https://app.opsgenie.com/teams/dashboard/633ac733-665f-4d62-871e-cbc011f37037\n\nOnce the user account has been created in OpsGenie, they must add a\n`github=GITHUB_USERNAME` tag to their OpsGenie profile for the tool to work.\n\nSee the below example.\n\n![User Configuration](/images/user-tag.png)\n\n##### url: https://kubernetes.app.opsgenie.com/settings/schedule/detail/f835cdef-8df9-4ddc-9a39-911cb9e521b5\n\nClick `Edit Rotation` next to \"PST Rotation\", and add/remove the new member from the participants list.\n\n![Edit Rotation](/images/opsgenie-edit-rotation.png)\n\n#### Add/ Remove SRC Owner permission from Kubernetes Security Mailing Lists\n\nNew SRC members are added to various security lists and upgraded to \"owner\" (or\ndowngraded to member if they are leaving the SRC)\n\nTo add members and assign the \"owner\" role:\n\n1. Visit the groups URL as a user authenticated as an existing \"owner\".\n2. Select the 'Manage group' or 'Manage Members' link.\n3. Within the left side panel, select 'Direct add member'.\n4. Enter the new SRC members email address\n5. Select the 'All members' link, or search for the new member in the search box.\n6. Select the new member and change the drop down role to \"Owner\" (or \"Manager\" in the case of kubernetes-announce)\n\n---\n\n**Existing Accounts**\n\nIt may be the case, that the user has already joined the group / mailing list.\nIf this is the case, steps 1 to 4 can be ignored and you can proceed to change\nthe role of their existing account.\n\n---\n\nTo downgrade existing owners to members:\n\n1. Visit the groups URL as a user authenticated as an existing \"owner\".\n2. Select the 'All members' link, or search for the existing owner in the search box.\n3. Select the owner and change the drop down role to \"Member\".\n\n| Mailing List | URL |\n| ------------- | ------------- |\n| Security Discuss | https://groups.google.com/forum/#!forum/kubernetes-security-discuss |\n| Security Announce | https://groups.google.com/forum/#!forum/kubernetes-security-announce |\n| Kubernetes Announce | https://groups.google.com/forum/#!forum/kubernetes-announce (Manager)|\n| Kubernetes Dev | https://groups.google.com/forum/#!forum/kubernetes-dev (Member) |\n\n_Note: the @kubernetes.io addresses are now managed through `groups.yaml`_\n\n#### Discuss Account\n\nA verified [discuss account](https://discuss.kubernetes.io/) is required.\n\n#### kubernetes-security github org\n\nUpdate the kubernetes-security github org team members for the additions or\nremovals.\n\nNavigate to https://github.com/orgs/kubernetes-security/people, and invite new\nmembers or remove existing members. Note that several non-SRC members have\naccess to this org (primarily release managers).\n\nOnce a new SRC member has accepted the invite, they should be granted `Owner`\npermissions.\n\nFor members stepping down, please ensure they are not assigned any issues in\nthe vulnerability trackers:\n\n- https://github.com/kubernetes-security/security-disclosures/issues\n- https://github.com/kubernetes-security/security-disclosures-low/issues\n\n#### Slack\n\nSRC members must enable slack 2-factor authentication: https://slack.com/help/articles/204509068-Set-up-two-factor-authentication\n\nNew members must be manually added to the private channels on slack by someone\nwho is already a member of those channels:\n\n1. `#SRC-private` for private SRC-only discussion\n2. `#security-release-team` for private discussions with the security-release-team\n\nMembers who are stepping down must leave the channels themselves. \n\nFinally, ask a `#slack-admins` member to add the new SRC member to the list of people who can post in `#announcements`. \n\nIf a member is stepping down, we must let the admins know to remove the `#announcements` permission. \n\n#### Calendar\n\nUpdate the Google calendar entries to add or remove the member:\n\n1. SRC Monthly (monthly, first Thursday)\n2. HackerOne sync (every 3 months, second Thursday)\n\n#### Google Docs\n\nUpdate the sharing settings for the following docs:\n\n- \"SRC Monthly Agenda & Notes\" (owner: timallclair@gmail.com)\n- \"Kubernetes CNA Tracker\" (owner: timallclair@gmail.com) - Only for [CNA trained members](https://github.com/kubernetes/committee-security-response/blob/master/cna-handbook.md)\n\n### Checklist\n\nThe following checklist can be pasted into an onboarding issue to track all the steps that need to be taken:\n\n```\n- [ ] kubernetes/committee-security-response PR:\n - [ ] README.md\n - [ ] OWNERS_ALIASES\n - [ ] SECURITY_CONTACTS\n- [ ] kubernetes/k8s.io PR:\n - [ ] groups/security-response-committee/groups.yaml\n - `security@kubernetes.io`\n - `security-discuss-private@kubernetes.io`\n - `distributors-announce@kubernetes.io`\n - [ ] OWNERS_ALIASES\n- [ ] kubernetes/community PR:\n - [ ] sigs.yaml\n - [ ] communication/slack-config/usergroups.yaml\n - [ ] Verify slack 2-factor auth\n - [ ] `make generate`\n- [ ] kubernetes/org PR:\n - [ ] config/kubernetes/org.yaml\n- [ ] HackerOne project membership\n - [ ] Verify 2-factor auth\n- [ ] OpsGenie rotation\n - [ ] Add new user\n - [ ] Update rotation\n- [ ] Mailing lists\n - [ ] [Security Discuss](https://groups.google.com/forum/#!forum/kubernetes-security-discuss) - owner\n - [ ] [Security Announce](https://groups.google.com/forum/#!forum/kubernetes-security-announce) - owner\n - [ ] [Kubernetes Announce](https://groups.google.com/forum/#!forum/kubernetes-announce) - manager\n - [ ] [Kubernetes Dev](https://groups.google.com/forum/#!forum/kubernetes-dev) - member\n- [ ] Verify Discuss account\n- [ ] github.com/kubernetes-security membership\n- [ ] Slack\n - [ ] Verify 2-factor auth\n - [ ] `#SRC-private` membership\n - [ ] `#security-release-team` membership\n- [ ] Calendar meetings\n- [ ] Google Docs access\n```\n" }, { "path": "src-oncall.md", "content": "# Security Response Committee Oncall\n\nSRC Oncall is a business-hours only oncall. That means you are not expected to\nrespond to issues outside of your normal daily working hours or on weekends or\nholidays. If you are taking vacation or will be unable to perform your oncall\nduties, please swap oncalls or find coverage for that week. See [managing oncall\nrotation](#appendix-managing-oncall-rotation).\n\n\n- [Responsibilities](#responsibilities)\n- [Triage Workflow](#triage-workflow)\n - [HackerOne triage details](#hackerone-triage-details)\n - [security@kubernetes.io Triage](#securitykubernetesio-triage)\n- [Incident Response Workflow](#incident-response-workflow)\n- [Handoff](#handoff)\n- [Appendix: Managing Oncall Rotation](#appendix-managing-oncall-rotation)\n - [Adding the rotation to your calendar](#adding-the-rotation-to-your-calendar)\n - [Swapping shifts or adding coverage](#swapping-shifts-or-adding-coverage)\n\n\n## Responsibilities\n\nDaily:\n\n- Triage vulnerability reports. We target 1 business day for initial response.\n - HackerOne reports ([query](https://hackerone.com/bugs?subject=kubernetes&view=k8s_triage)),see\n [HackerOne Workflow](#hackerone-triage-details) for details.\n - security@kubernetes.io emails, see [securit@kubernetes.io Triage](#securitykubernetesio-triage)\n for details.\n\n- Handle incident response for ongoing issues\n - Drive progress on assigned issues ([query](https://github.com/kubernetes-security/security-disclosures/issues/assigned/@me))\n - See [incident response](#incident-response-workflow) for details\n - Ping incident commander of critical issues\n ([query](https://github.com/kubernetes-security/security-disclosures/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+label%3Aseverity%2Fcritical))\n if last update > 2 days ago\n\nWeekly (ideally at the beginning of your shift):\n\n- Ping incident commander of high severity issues\n ([query](https://github.com/kubernetes-security/security-disclosures/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+label%3Aseverity%2Fhigh))\n if last update was > 7 days ago\n\n- Ping incident commander of medium severity issues\n ([query](https://github.com/kubernetes-security/security-disclosures/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+label%3Aseverity%2Fmedium))\n if last update was > 1 month ago\n\n- Check for new issues in this repository, especially distributor list join requests. Triage, assign or handle new issues, as appropriate.\n ([query](https://github.com/kubernetes/security/issues))\n\n- Check for new PRs in this repository and address open PRs where possible\n ([query](https://github.com/kubernetes/security/pulls))\n\n## Triage Workflow\n\n![Triage workflow flowchart](images/src-oncall-triage-flow.png)\n\n### HackerOne triage details\n\n**1. Assess assigned issues**\n\nThe recommended way of reviewing hackerone issues needing triage is to check\nover the assigned issues daily:\nhttps://hackerone.com/bugs?subject=kubernetes&view=k8s\\_triage\n\nThis view tracks issues that are assigned to the Kubernetes Team (SRC), but\ndon't yet have a bounty awarded, which is a heuristic for whether the report\nneeds attention.\n\n**1.a. Needs more information or Invalid**\n\nIf the report needs more information or is invalid, you can either respond\ndirectly to the reporter (Add comment > All participants), or respond in a\nprivate comment (Team only) and ask (reassign) the H1 Triage team to relay the\nmessage.\n\n![HackerOne comment](images/src-oncall-h1-triage-comment.png)\n\n![HackerOne reassign](images/src-oncall-h1-triage-reassign.png)\n\n**2. Set severity & tier**\n\nOnce you've determined that the report is valid and have an understanding of the\nimpact, set the [severity][] of the issue based on the CVSS score, and set the\ntier (custom field) based on the [Kubernetes definition of\ntiers](https://hackerone.com/kubernetes) (under \"Rewards\").\n\n_TODO: Refine the definition of reward tiers._\n\n![Set the severity & tier on HackerOne](images/src-oncall-h1-triage-severity.png)\n\n[severity]: security-release-process.md#severity-thresholds---how-we-do-vulnerability-scoring\n\n**3. File tracking issue**\n\nEvery non-public issue that we decide to take action on should get filed as a\nGitHub issue in the https://github.com/kubernetes-security/security-disclosures\nrepo.\n\nFrom the HackerOne report, you can use the GitHub integration to auto-file the tracking issue, and\nsync updates with the H1 report:\n\n1. Click \"References\" (in the right sidebar)\n2. Select \"Kubernetes HackerOne Robot\" to automatically create the issue.\n - If the issue was already created manually, or is being created in a different repo (e.g. for a\n public issue), select \"Manual Integration\" instead.\n3. Click \"Create\"\n4. Assign the created issue to the appropriate assignee (usually yourself), and apply any relevant\n labels.\n\n**4. Award bounty**\n\nOnce you're confident that we've sufficiently assessed the severity and tier\n(try to get an approval from someone else on the committee), it's time to award\nthe bounty. Note that you _do not_ need to wait until the issue is resolved\nbefore awarding the bounty.\n\nChoose the corresponding amount from the tiered bounty tables on\nhttps://hackerone.com/kubernetes (under \"rewards\"). Then, scroll down to the\ncomment box on the report and change the action to \"Set award\". Enter the\namount, leave a comment if you'd like, and click \"Set award\". Congratulations,\nyou've completed triage on this report (continue on to incident response).\n\n![Set HackerOne reward](images/src-oncall-h1-triage-reward.png)\n\n**5. Mark resolved & Disclose**\n\n**Pending Resolution tab:** Once the issue has been resolved or fully handed off to the public\nKubernetes community, it should be marked as resolved. Select \"Close report\" from the action\ndrop-down over the comment box, and set the status to \"Resolved\". Add a comment about the final\nresolution (often a link to the public announcement).\n\n**Needs Disclosure tab:** Most issues should be publicly disclosed, unless there is a specific\nreason not to. From the drop-down, choose \"Request disclosure\". \"Full Disclosure\" should be used in\nmost cases. It discloses all the details from the report, except for team-only comments (red comment\nboxes). Specific details can be redacted.\n\nUnfortunately there is no way to mark a report as \"do not disclose\". If the report shouldn't be\ndisclosed for any reason, leave a team-only comment with `DO NOT DISCLOSE` and a justification.\n\n**Pending Disclosure tab:** Once disclosure has been requested, we give the original reporter 1\nmonth to respond to the disclosure request. If there hasn't been a repsonse for over 1 month, you\ncan just disclose it. Select \"Disclose\" from the drop-down menu, and confirm the disclosure type.\n\n### security@kubernetes.io Triage\n\nWe leverage Google Groups [collaborative\ninbox](https://support.google.com/a/users/answer/167430?hl=en) features to triage incoming emails to\nthe list.\n\n1. Every actionable email should have an assignee who is accountable for ensuring the report is\n followed up and responded to in a timely manner.\n - Note: we have an auto-responder which encourages reporters to resubmit reports through the\n HackerOne bug bounty, so keep an eye out for duplicates.\n2. Unacctionable emails should be marked as such.\n3. Issues which have been resolved should be marked as completed.\n4. Legitimate vulnerability reports should be copied into a tracking issue\n - Include a link back to Google Groups thread (original report field in the template)\n - Add the `Tracked` label to the groups thread\n\nSpam: when a spam message is received, please use the \"Report abuse\" button. Reporting a message as\nabuse only hides it for the reporter, so after reporting it please delete the original.\n\n\n## Incident Response Workflow\n\n![Incident response flowchart](images/src-oncall-incident-flow.png)\n\n## Handoff\n\nWhen your shift ends, you may be the incident commander on one or more ongoing\nincidents. If you are already invested in the incident and have the bandwidth\nfor it, you can continue managing the incident (thanks!), but _you are not\nobligated to continue managing the incident!_\n\nIf you would like to handoff incident command:\n\n1. Start by **ensuring the tracking issue is up to date** - review the\n information in the issue description, and fill in or correct any missing\n details.\n2. **Leave a comment** to dump any additional context and state you have on the\n issue. Make sure to list any open questions or decisions and any pending\n action items.\n3. Reassign the issue to the next oncall.\n\nFinally, reach out to the next oncall (email, slack, VC, your choice) to make\nsure they're aware of the handoff and to answer any questions. _Until they've\nexplicitly acknowledged the handoff you are still the incident commander!_\n\n## Appendix: Managing Oncall Rotation\n\n### Adding the rotation to your calendar\n\n1. Navigate to the SRC oncall rotation:\n https://kubernetes.app.opsgenie.com/settings/schedule/detail/f835cdef-8df9-4ddc-9a39-911cb9e521b5\n\n2. Click \"Open calendar\" (appears on hover), add to your calendar.\n\n![Oncall calendar](images/src-oncall-calendar.png)\n\n### Swapping shifts or adding coverage\n\n0. Find someone to agree to swap shifts or cover for days you will be\n unavailable.\n\n1. Navigate to the SRC oncall rotation:\n https://kubernetes.app.opsgenie.com/settings/schedule/detail/f835cdef-8df9-4ddc-9a39-911cb9e521b5\n\n2. Click \"Add override\", fill in the appropriate details.\n - Select the user who will be taking the shift\n - Select the SRC rotation\n - Enter the dates for the override\n\n_Note: If you're swapping shifts, you'll need to do this twice, once for your\nshift and once for the shift you're swapping for._\n\n\n![Edit the oncall schedule](images/src-oncall-override.png)\n" }, { "path": "tools/patchformat.py", "content": "import argparse\nfrom ghapi.core import GhApi\nimport os\nimport time\n\nusername = os.environ['GH_USERNAME']\n# When creating github personal access token, be sure to check all permissions under the repo scope to access private repos\ngithub_token = os.environ['GH_TOKEN']\n\napi = GhApi(owner='kubernetes-security', repo='kubernetes',token=github_token)\n\nparser = argparse.ArgumentParser(description='Format patch files')\nrequired = parser.add_argument_group('required arguments')\nrequired.add_argument('--pr', help='Pull Request Number in kubernetes-security/kubernetes with the fix (e.g. 63)', required=True)\nrequired.add_argument('--cve', help='CVE for the vulnerability', required=True)\nrequired.add_argument('-r', '--release', help='Kubernetes release branch (e.g. 1.30)', required=True)\nparser.add_argument('-v', '--version', help='Patch version, if a correction is being sent')\nargs = parser.parse_args()\n\npull = api.pulls.get(args.pr)\npatch = api(pull.url, headers={'Accept': 'application/vnd.github.patch'})\n\npatch_split = patch.splitlines()\npatch_list = []\n\nlocal_time = time.localtime()\n\npatch_list.append('From: distributors-announce ')\npatch_list.append('Date: ' + time.strftime('%a, %d %b %Y %H:%M:%S %z', local_time))\npatch_list.append('Subject: Fix ' + args.cve)\npatch_list.append('')\n\nstarted = False\nfor line in patch_split:\n if line != '---' and not started:\n pass\n else:\n started = True\n patch_list.append(line)\n\nif args.version:\n filename = args.cve.split('-')[2] + '_v' + args.release + '_v' + args.version + '.patch'\nelse:\n filename = args.cve.split('-')[2] + '_v' + args.release + '.patch'\n\nf = open(filename, 'w')\nf.write('\\n'.join(patch_list))\nf.write('\\n')\nf.close()\n" } ]