|
| 1 | +# SIG Security Charter |
| 2 | + |
| 3 | +This charter adheres to the conventions described in the [Kubernetes Charter README] and uses the Roles and Organization Management outlined in [sig-governance]. |
| 4 | + |
| 5 | +## Scope |
| 6 | + |
| 7 | +SIG Security covers horizontal security initiatives for the Kubernetes project, including regular security audits, the vulnerability management process, cross-cutting security documentation, and security community management. As a process-oriented SIG, it does not directly own Kubernetes component code. This SIG replaces the Security Audit Working Group. Instead, SIG Security focuses on improving the security of the Kubernetes project across all components. |
| 8 | + |
| 9 | +This SIG grew out of the [Third-Party Security Audit Working Group](https://github.com/kubernetes/community/tree/master/wg-security-audit), which managed each recurrent Third-Party Security Audit over the course of the audit’s lifecycle. The Working Group worked closely with selected vendors, the Product Security Committee, and the CNCF. It created the RFP, selected the vendors, and managed the vendors’ engagement with other SIGs and subject matter experts. |
| 10 | + |
| 11 | +SIG Security continues to manage the third-party security audits, while serving a wider mission of advocating for security-related structural or systemic issues and default configuration settings, managing the non-embargoed (public) vulnerability process, defining the bug bounty, creating official Kubernetes Hardening Guides and security documents, and serving as a public relations contact point for Kubernetes security. |
| 12 | + |
| 13 | +### In scope |
| 14 | + |
| 15 | +#### Vulnerability Management Process |
| 16 | + |
| 17 | +Work with the Kubernetes [Product Security Committee (PSC)](https://github.com/kubernetes/security#product-security-committee-psc) to define the processes for fixing and disclosing vulnerabilities, as outlined in https://github.com/kubernetes/security. For example: |
| 18 | + |
| 19 | +- When the private fix & release process is invoked |
| 20 | +- How vulnerabilities are rated |
| 21 | +- The scope of the bug bounty |
| 22 | +- Post-announcement follow-ups, such as additional fixes, mitigations, preventions or documentation after a vulnerability is made public |
| 23 | +- Distributor announcement policies, such as timelines, criteria for joining the list, etc. |
| 24 | +- How, when and where vulnerabilities are announced |
| 25 | +- Defining the criteria and process for supporting Kubernetes subprojects, such as the [dashboard](https://github.com/kubernetes/dashboard), [ingress-nginx](https://github.com/kubernetes/ingress-nginx), or [kops](https://github.com/kubernetes/kops). |
| 26 | + |
| 27 | +#### Security Community Management and Outreach |
| 28 | + |
| 29 | +Provide an entry point to the Kubernetes community for new security-minded contributors, as well as a meeting point to discuss security themes and issues within Kubernetes, including: |
| 30 | + |
| 31 | +- Work with [SIG Contributor Experience](https://github.com/kubernetes/community/tree/master/sig-contributor-experience) to curate and staff security discussion channels (e.g. slack channel, mailing list, discourse, stack overflow, etc.). |
| 32 | +- Answer security questions from inexperienced users (that don't know what SIG to go to), and identify common questions or issues as areas for improvement. |
| 33 | +- Provide an "entry point" for new contributors interested in security. Route these new contributors to other SIGs when they have more specific goals (e.g. SIG Node for container isolation). |
| 34 | + |
| 35 | +#### Horizontal Security Documentation |
| 36 | + |
| 37 | +Author and maintain cross-cutting security documentation, such as hardening guides and security benchmarks. Seek out and coordinate with experts in other SIGs for input on the documentation (i.e. we go to them, they don't need to come to us). In-scope documentation includes: |
| 38 | + |
| 39 | +- Hardening guides and best practices |
| 40 | +- Security benchmarks |
| 41 | +- Improving documentation to address common misunderstandings or questions |
| 42 | +- Threat models |
| 43 | + |
| 44 | +#### Security Audit |
| 45 | + |
| 46 | +Manage recurring security audits and follow up on issues. Coordinate vendors to perform the audit and publish the findings. Follow up on issues with the affected SIG and help coordinate resolution, which can include: |
| 47 | + |
| 48 | +- Helping to prioritize the fixes, possibly by recruiting from SIG Security (while acknowledging that the ultimate authority in deciding whether and how to fix an issue lies with the responsible SIG). |
| 49 | +- Documenting mitigations, workarounds, or caveats, especially when the responsible SIG decides not to fix a reported issue. |
| 50 | + |
| 51 | +### Out of scope |
| 52 | + |
| 53 | +In contrast to SIG Auth, SIG Security does not own any Kubernetes cluster component code. |
| 54 | + |
| 55 | +Further, SIG Security’s scope does not include: |
| 56 | + |
| 57 | +- Kubernetes authentication, authorization, audit and security policy features. (SIG Auth) |
| 58 | +- Private vulnerability response (belongs to the PSC), including: |
| 59 | + - Embargoed vulnerability management |
| 60 | + - Bug bounty submission triage and management |
| 61 | + - Non-public vulnerability collection, triage, and disclosure |
| 62 | +- The mechanisms to protect confidentiality/integrity of API data (belongs to SIG API Machinery, SIG Auth or others) |
| 63 | +- Security audit for all other CNCF projects (e.g., etcd, CoreDNS, CRI-O, containerd) (Belongs to the CNCF’s SIG Security.) |
| 64 | +- Any projects outside of the Kubernetes project |
| 65 | +- Cloud provider-specific or distributor-specific hardening guides |
| 66 | +- Recommendations or endorsements of specific commercial product vendors or cloud providers. |
| 67 | + |
| 68 | + |
| 69 | +## Roles and Organization Management |
| 70 | + |
| 71 | +This SIG adheres to the Roles and Organization Management outlined in [sig-governance] and opts-in to updates and modifications to [sig-governance]. |
| 72 | + |
| 73 | +### Additional responsibilities of Chairs |
| 74 | + |
| 75 | +None defined at this time. |
| 76 | + |
| 77 | +### Additional responsibilities of Tech Leads |
| 78 | + |
| 79 | +- Security Documents and Documentation Tech Leads will be responsible for maintaining the official Kubernetes project Security Hardening Guide. |
| 80 | + |
| 81 | +### Subproject Creation |
| 82 | + |
| 83 | +SIG Security delegates subproject approval to SIG Technical Leads. See Subproject creation - Option 1. |
| 84 | + |
| 85 | +SIG Security’s initial subprojects will be: |
| 86 | + |
| 87 | +- Security Documents and Documentation |
| 88 | +- Third Party Security Audit |
| 89 | +- Community Discussion Groups |
0 commit comments