Rename Product Security Team to Committee

This commit is contained in:
Joel Smith 2019-02-26 16:06:19 -07:00
parent a4474adb2d
commit 2f922a12b1
7 changed files with 9 additions and 9 deletions

View File

@ -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

View File

@ -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

View File

@ -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)

View File

@ -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)

View File

@ -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

View File

@ -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

View File

@ -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