Rename Product Security Team to Committee
This commit is contained in:
parent
a4474adb2d
commit
2f922a12b1
|
@ -74,7 +74,7 @@ Subproject Owner Role. (this different from a SIG or Organization Member).
|
||||||
### Security Contact
|
### Security Contact
|
||||||
|
|
||||||
- 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
|
triaging and handling of incoming issues
|
||||||
- *MUST* accept the [Embargo Policy]
|
- *MUST* accept the [Embargo Policy]
|
||||||
- Defined in `SECURITY_CONTACTS` files, this is only relevant to the root file in
|
- 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>
|
- Linux privilege escalations<br>
|
||||||
_Please report these through security@kernel.org_
|
_Please report these through security@kernel.org_
|
||||||
- Attacks against containers from the host they are running on
|
- 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.
|
such as clusters not utilizing mutual authentication or encryption between Kubernetes components.
|
||||||
- Attacks relying on or against deprecated components (e.g. gitrepo volumes)
|
- Attacks relying on or against deprecated components (e.g. gitrepo volumes)
|
||||||
- Vulnerabilities in etcd<br>
|
- 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>
|
- Vulnerabilities specific to a hosted Kubernetes setup<br>
|
||||||
_Please report these through the associated provider_
|
_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/
|
[CoreOS's disclosure process]: https://coreos.com/security/disclosure/
|
||||||
[CoreDNS's disclosure process]: https://github.com/coredns/coredns#security
|
[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
|
* Tim Allclair (@tallclair, Google) nominated as replacement
|
||||||
* Long-term contributor to k8s auth/security
|
* Long-term contributor to k8s auth/security
|
||||||
* Helped drive pod security policy and audit features
|
* 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
|
* Brings container/node security expertise
|
||||||
* Unanimous support from other leads (Jordan Liggitt, Red Hat; Eric Chiang, CoreOS)
|
* Unanimous support from other leads (Jordan Liggitt, Red Hat; Eric Chiang, CoreOS)
|
||||||
* Feedback on the change welcome (either public or private)
|
* 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
|
- Protection of volume data, container ephemeral data, and other non-API data (prefer: sig-storage
|
||||||
and sig-node)
|
and sig-node)
|
||||||
- Container isolation (prefer: sig-node and sig-networking)
|
- 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 quota (prefer: sig-scheduling)
|
||||||
- Resource availability / DOS protection (prefer: sig-apimachinery, sig-network, sig-node)
|
- 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.
|
related events, such as KubeCon.
|
||||||
|
|
||||||
- Security Contacts
|
- 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.
|
triaging and handling of incoming issues.
|
||||||
- Must be a maintainer.
|
- Must be a maintainer.
|
||||||
- Must accept and adhere to the Kubernetes [Embargo
|
- Must accept and adhere to the Kubernetes [Embargo
|
||||||
|
|
|
@ -98,7 +98,7 @@ time.
|
||||||
must be staffed / owned by at least 3 volunteers
|
must be staffed / owned by at least 3 volunteers
|
||||||
|
|
||||||
- We aspire to follow the same 1/3 maximal representation rules used by the
|
- 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
|
project-wide impact
|
||||||
- However, while we are bootstrapping, we consider it acceptable for maximal
|
- However, while we are bootstrapping, we consider it acceptable for maximal
|
||||||
representation concerns to be violated, since this will often be necessary
|
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
|
- Our plan would be to rectify this when choosing new members or rotating
|
||||||
old members such that we eventually meet maximal representation criteria
|
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
|
suitable vetting new subproject owners
|
||||||
|
|
||||||
- Subproject owners must provide additional contact details within the WG, and
|
- 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:
|
those involved in meta-topics:
|
||||||
* SIG Release: production of supported release artifacts
|
* SIG Release: production of supported release artifacts
|
||||||
* SIG Testing: how we can most effectively test Kubernetes
|
* 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.
|
* 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
|
* Steering Committee: scope includes deciding how and when official releases of Kubernetes artifacts are made and what they include
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue