Merge pull request #3311 from joelsmith/master

Create Product Security Committee, update references from PST to PSC

OWNERS_ALIASES

@@ -173,4 +173,10 @@ aliases:
     - eparis
     - carolynvs
     - bradamant3
+  product-security-committee:
+    - philips
+    - jessfraz
+    - cjcullen
+    - tallclair
+    - liggitt
 ## END CUSTOM CONTENT

committee-product-security/OWNERS

@@ -0,0 +1,8 @@
+# See the OWNERS docs at https://go.k8s.io/owners
+
+reviewers:
+  - product-security-committee
+approvers:
+  - product-security-committee
+labels:
+  - committee/product-security

committee-product-security/README.md

@@ -0,0 +1,8 @@
+# Kubernetes Product Security Committee
+
+The Kubernetes Product Security Committee is the body that is responsible for receiving and responding to reports of security issues in Kubernetes products.
+
+Current committee members are listed on the [Product Security Committee section](https://git.k8s.io/security/security-release-process.md#product-security-committee-psc) of the committee's documentation.
+Information on how members are selected is in the [Product Security Committee Membership section](https://git.k8s.io/security/security-release-process.md#product-security-committee-membership) of the same document.
+
+_To report a security issue, please email the private security@kubernetes.io list with the security details and the details expected for all Kubernetes bug reports._

committee-steering/governance/sig-governance.md

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

contributors/guide/bug-bounty.md

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

sig-auth/archive/meeting-notes-2018.md

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

sig-auth/charter.md

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

sig-service-catalog/charter.md

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

wg-k8s-infra/charter.md

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

wg-lts/charter.md

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