summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRobert A Ficcaglia <rficcaglia@gmail.com>2021-05-08 17:00:41 -0700
committerGitHub <noreply@github.com>2021-05-08 17:00:41 -0700
commitbbd9feb7c8fc0b5c909f1d196fd0d7b63f012d0f (patch)
treeb755893fd8405a04f00848cd90602a383a01893c
parentbb99ed28bcd449acaa6e55cc890d188999955824 (diff)
adding question
and answer after slack discussion 5/7
-rw-r--r--sig-security/security-audit-2021/RFP.md6
1 files changed, 6 insertions, 0 deletions
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).