From bbd9feb7c8fc0b5c909f1d196fd0d7b63f012d0f Mon Sep 17 00:00:00 2001 From: Robert A Ficcaglia Date: Sat, 8 May 2021 17:00:41 -0700 Subject: adding question and answer after slack discussion 5/7 --- sig-security/security-audit-2021/RFP.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sig-security/security-audit-2021/RFP.md b/sig-security/security-audit-2021/RFP.md index bc5346f7..14ee309c 100644 --- a/sig-security/security-audit-2021/RFP.md +++ b/sig-security/security-audit-2021/RFP.md @@ -121,3 +121,9 @@ The audit should result in the following deliverables, which will be made public * Audited reference architecture specification. Should take the form of a summary and associated configuration YAML files. * Findings report including an executive summary. * Where possible and, in the vendor’s opinion makes the most judicious use of time, proof of concept exploits that the Kubernetes project can use to investigate and fix defects. + +## Questions Asked during RFP Response Process + +### Do we need to use our own hardware and infrastructure or should we use a cloud? + +Strong preference would be for the vendor to provide their own infrastructure or use a public cloud provider, just NOT a managed offering like GKE or EKS. The reasoning is to prevent accidentally auditing a cloud provider's kubernetes service instead of kubernetes/kubernetes. Depending on the scope and approach, it may make sense to use a local cluster (e.g. kind) for API fuzzing and anything that doesn't impact the underlying OS, and is an easy to use repeatable setup (see Methodology above). -- cgit v1.2.3