Rename Product Security Team to Committee
This commit is contained in:
Joel Smith
parent
a4474adb2d
commit
2f922a12b1
|
|
@ -74,7 +74,7 @@ Subproject Owner Role. (this different from a SIG or Organization Member).
|
|||
### Security Contact
|
||||
|
||||
- Security Contact
|
||||
- *MUST* be a contact point for the Product Security Team to reach out to for
|
||||
- *MUST* be a contact point for the Product Security Committee to reach out to for
|
||||
triaging and handling of incoming issues
|
||||
- *MUST* accept the [Embargo Policy]
|
||||
- Defined in `SECURITY_CONTACTS` files, this is only relevant to the root file in
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ vulnerability reports in these areas, they are not (currently) eligible to recei
|
|||
- Linux privilege escalations<br>
|
||||
_Please report these through security@kernel.org_
|
||||
- Attacks against containers from the host they are running on
|
||||
- Attacks relying on insecure configurations (subject to the [Product Security Team][]'s opinion),
|
||||
- Attacks relying on insecure configurations (subject to the [Product Security Committee][]'s opinion),
|
||||
such as clusters not utilizing mutual authentication or encryption between Kubernetes components.
|
||||
- Attacks relying on or against deprecated components (e.g. gitrepo volumes)
|
||||
- Vulnerabilities in etcd<br>
|
||||
|
|
@ -74,6 +74,6 @@ vulnerability reports in these areas, they are not (currently) eligible to recei
|
|||
- Vulnerabilities specific to a hosted Kubernetes setup<br>
|
||||
_Please report these through the associated provider_
|
||||
|
||||
[Product Security Team]: https://github.com/kubernetes/sig-release/blob/master/security-release-process-documentation/security-release-process.md#product-security-team-pst
|
||||
[Product Security Committee]: https://git.k8s.io/security/security-release-process.md#product-security-committee-psc
|
||||
[CoreOS's disclosure process]: https://coreos.com/security/disclosure/
|
||||
[CoreDNS's disclosure process]: https://github.com/coredns/coredns#security
|
||||
|
|
|
|||
|
|
@ -582,7 +582,7 @@ q2Xz68mF3_LggEY/edit?ts=5a68cdbc
|
|||
* Tim Allclair (@tallclair, Google) nominated as replacement
|
||||
* Long-term contributor to k8s auth/security
|
||||
* Helped drive pod security policy and audit features
|
||||
* Member of kubernetes product security team
|
||||
* Member of kubernetes product security committee
|
||||
* Brings container/node security expertise
|
||||
* Unanimous support from other leads (Jordan Liggitt, Red Hat; Eric Chiang, CoreOS)
|
||||
* Feedback on the change welcome (either public or private)
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ Link to SIG section in [sigs.yaml]
|
|||
- Protection of volume data, container ephemeral data, and other non-API data (prefer: sig-storage
|
||||
and sig-node)
|
||||
- Container isolation (prefer: sig-node and sig-networking)
|
||||
- Bug bounty (prefer: product security team)
|
||||
- Bug bounty (prefer: product security committee)
|
||||
- Resource quota (prefer: sig-scheduling)
|
||||
- Resource availability / DOS protection (prefer: sig-apimachinery, sig-network, sig-node)
|
||||
|
||||
|
|
|
|||
|
|
@ -109,7 +109,7 @@ roles. We do not have the Tech Lead role, and have a honorary Emeritus Chair rol
|
|||
related events, such as KubeCon.
|
||||
|
||||
- Security Contacts
|
||||
- Are a contact point for the Product Security Team to reach out to for
|
||||
- Are a contact point for the Product Security Committee to reach out to for
|
||||
triaging and handling of incoming issues.
|
||||
- Must be a maintainer.
|
||||
- Must accept and adhere to the Kubernetes [Embargo
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ time.
|
|||
must be staffed / owned by at least 3 volunteers
|
||||
|
||||
- We aspire to follow the same 1/3 maximal representation rules used by the
|
||||
Steering Committee, Product Security Team, and other groups that have
|
||||
Steering Committee, Product Security Committee, and other groups that have
|
||||
project-wide impact
|
||||
- However, while we are bootstrapping, we consider it acceptable for maximal
|
||||
representation concerns to be violated, since this will often be necessary
|
||||
|
|
@ -106,7 +106,7 @@ time.
|
|||
- Our plan would be to rectify this when choosing new members or rotating
|
||||
old members such that we eventually meet maximal representation criteria
|
||||
|
||||
- We plan to follow the model set forth by the Product Security Team for
|
||||
- We plan to follow the model set forth by the Product Security Committee for
|
||||
suitable vetting new subproject owners
|
||||
|
||||
- Subproject owners must provide additional contact details within the WG, and
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ There is yet another set of developers of Kubernetes internals who are
|
|||
those involved in meta-topics:
|
||||
* SIG Release: production of supported release artifacts
|
||||
* SIG Testing: how we can most effectively test Kubernetes
|
||||
* Product Security Team (PST): security vulnerability handling
|
||||
* Product Security Committee (PSC): security vulnerability handling
|
||||
* SIG Architecture: maintains and evolves the design principles of Kubernetes, and provides a consistent body of expertise necessary to ensure architectural consistency over time. Also defines conformance testing.
|
||||
* Steering Committee: scope includes deciding how and when official releases of Kubernetes artifacts are made and what they include
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue