Kubernetes 需要澄清CIS基准测试结果的警告消息吗

我指的是针对GKE集群版本1.15.9-GKE.12运行以下命令

#kube-bench -v 3 --logtostderr --benchmark cis-1.5 run --targets policies

`I0306 07:30:34.927822 44978 common.go:326] Kubernetes version: "" to Benchmark version: "cis-1.5"
I0306 07:30:34.927856 44978 run.go:40] Checking targets [policies] for cis-1.5
I0306 07:30:34.927997 44978 common.go:267] Using config file: cfg/cis-1.5/config.yaml
I0306 07:30:34.928031 44978 run.go:62] Running tests from files [cfg/cis-1.5/policies.yaml]
I0306 07:30:34.928132 44978 common.go:79] Using test file: cfg/cis-1.5/policies.yaml
I0306 07:30:34.928757 44978 controls.go:76] Check.ID 5.1.1
I0306 07:30:34.928781 44978 check.go:207] textToCommand: ""
I0306 07:30:34.928828 44978 controls.go:76] Check.ID 5.1.2
I0306 07:30:34.928834 44978 check.go:207] textToCommand: ""
I0306 07:30:34.928847 44978 controls.go:76] Check.ID 5.1.3
I0306 07:30:34.928850 44978 check.go:207] textToCommand: ""
I0306 07:30:34.928866 44978 controls.go:76] Check.ID 5.1.4
I0306 07:30:34.928869 44978 check.go:207] textToCommand: ""
I0306 07:30:34.928882 44978 controls.go:76] Check.ID 5.1.5
I0306 07:30:34.928885 44978 check.go:207] textToCommand: ""
I0306 07:30:34.928900 44978 controls.go:76] Check.ID 5.1.6
I0306 07:30:34.928903 44978 check.go:207] textToCommand: ""
I0306 07:30:34.928915 44978 controls.go:76] Check.ID 5.2.1
I0306 07:30:34.928920 44978 check.go:207] textToCommand: ""
I0306 07:30:34.928938 44978 controls.go:76] Check.ID 5.2.2
I0306 07:30:34.928942 44978 check.go:207] textToCommand: ""
I0306 07:30:34.928950 44978 controls.go:76] Check.ID 5.2.3
I0306 07:30:34.928953 44978 check.go:207] textToCommand: ""
I0306 07:30:34.928994 44978 controls.go:76] Check.ID 5.2.4
I0306 07:30:34.928997 44978 check.go:207] textToCommand: ""
I0306 07:30:34.929006 44978 controls.go:76] Check.ID 5.2.5
I0306 07:30:34.929008 44978 check.go:207] textToCommand: ""
I0306 07:30:34.929018 44978 controls.go:76] Check.ID 5.2.6
I0306 07:30:34.929021 44978 check.go:207] textToCommand: ""
I0306 07:30:34.929037 44978 controls.go:76] Check.ID 5.2.7
I0306 07:30:34.929040 44978 check.go:207] textToCommand: ""
I0306 07:30:34.929049 44978 controls.go:76] Check.ID 5.2.8
I0306 07:30:34.929051 44978 check.go:207] textToCommand: ""
I0306 07:30:34.929066 44978 controls.go:76] Check.ID 5.2.9
I0306 07:30:34.929070 44978 check.go:207] textToCommand: ""
I0306 07:30:34.929083 44978 controls.go:76] Check.ID 5.3.1
I0306 07:30:34.929086 44978 check.go:207] textToCommand: ""
I0306 07:30:34.929096 44978 controls.go:76] Check.ID 5.3.2
I0306 07:30:34.929099 44978 check.go:207] textToCommand: ""
I0306 07:30:34.929116 44978 controls.go:76] Check.ID 5.4.1
I0306 07:30:34.929121 44978 check.go:207] textToCommand: ""
I0306 07:30:34.929134 44978 controls.go:76] Check.ID 5.4.2
I0306 07:30:34.929137 44978 check.go:207] textToCommand: ""
I0306 07:30:34.929150 44978 controls.go:76] Check.ID 5.5.1
I0306 07:30:34.929153 44978 check.go:207] textToCommand: ""
I0306 07:30:34.929163 44978 controls.go:76] Check.ID 5.6.1
I0306 07:30:34.929169 44978 check.go:207] textToCommand: ""
I0306 07:30:34.929186 44978 controls.go:76] Check.ID 5.6.2
I0306 07:30:34.929189 44978 check.go:207] textToCommand: ""
I0306 07:30:34.929197 44978 controls.go:76] Check.ID 5.6.3
I0306 07:30:34.929200 44978 check.go:207] textToCommand: ""
I0306 07:30:34.929213 44978 controls.go:76] Check.ID 5.6.4
I0306 07:30:34.929216 44978 check.go:207] textToCommand: ""
[INFO] 5 Kubernetes Policies
[INFO] 5.1 RBAC and Service Accounts
[WARN] 5.1.1 Ensure that the cluster-admin role is only used where required (Not Scored)
[WARN] 5.1.2 Minimize access to secrets (Not Scored)
[WARN] 5.1.3 Minimize wildcard use in Roles and ClusterRoles (Not Scored)
[WARN] 5.1.4 Minimize access to create pods (Not Scored)
[WARN] 5.1.5 Ensure that default service accounts are not actively used. (Scored)
[WARN] 5.1.6 Ensure that Service Account Tokens are only mounted where necessary (Not Scored)
[INFO] 5.2 Pod Security Policies
[WARN] 5.2.1 Minimize the admission of privileged containers (Not Scored)
[WARN] 5.2.2 Minimize the admission of containers wishing to share the host process ID namespace (Scored)
[WARN] 5.2.3 Minimize the admission of containers wishing to share the host IPC namespace (Scored)
[WARN] 5.2.4 Minimize the admission of containers wishing to share the host network namespace (Scored)
[WARN] 5.2.5 Minimize the admission of containers with allowPrivilegeEscalation (Scored)
[WARN] 5.2.6 Minimize the admission of root containers (Not Scored)
[WARN] 5.2.7 Minimize the admission of containers with the NET_RAW capability (Not Scored)
[WARN] 5.2.8 Minimize the admission of containers with added capabilities (Not Scored)
[WARN] 5.2.9 Minimize the admission of containers with capabilities assigned (Not Scored)
[INFO] 5.3 Network Policies and CNI
[WARN] 5.3.1 Ensure that the CNI in use supports Network Policies (Not Scored)
[WARN] 5.3.2 Ensure that all Namespaces have Network Policies defined (Scored)
[INFO] 5.4 Secrets Management
[WARN] 5.4.1 Prefer using secrets as files over secrets as environment variables (Not Scored)
[WARN] 5.4.2 Consider external secret storage (Not Scored)
[INFO] 5.5 Extensible Admission Control
[WARN] 5.5.1 Configure Image Provenance using ImagePolicyWebhook admission controller (Not Scored)
[INFO] 5.6 General Policies
[WARN] 5.6.1 Create administrative boundaries between resources using namespaces (Not Scored)
[WARN] 5.6.2 Ensure that the seccomp profile is set to docker/default in your pod definitions (Not Scored)
[WARN] 5.6.3 Apply Security Context to Your Pods and Containers (Not Scored)
[WARN] 5.6.4 The default namespace should not be used (Scored)

== Remediations ==
5.1.1 Identify all clusterrolebindings to the cluster-admin role. Check if they are used and
if they need this role or if they could use a role with fewer privileges.
Where possible, first bind users to a lower privileged role and then remove the
clusterrolebinding to the cluster-admin role :
kubectl delete clusterrolebinding [name]

5.1.2 Where possible, remove get, list and watch access to secret objects in the cluster.

5.1.3 Where possible replace any use of wildcards in clusterroles and roles with specific
objects or actions.

5.1.4
5.1.5 Create explicit service accounts wherever a Kubernetes workload requires specific access
to the Kubernetes API server.
Modify the configuration of each default service account to include this value
automountServiceAccountToken: false

5.1.6 Modify the definition of pods and service accounts which do not need to mount service
account tokens to disable it.

5.2.1 Create a PSP as described in the Kubernetes documentation, ensuring that
the .spec.privileged field is omitted or set to false.

5.2.2 Create a PSP as described in the Kubernetes documentation, ensuring that the
.spec.hostPID field is omitted or set to false.

5.2.3 Create a PSP as described in the Kubernetes documentation, ensuring that the
.spec.hostIPC field is omitted or set to false.

5.2.4 Create a PSP as described in the Kubernetes documentation, ensuring that the
.spec.hostNetwork field is omitted or set to false.

5.2.5 Create a PSP as described in the Kubernetes documentation, ensuring that the
.spec.allowPrivilegeEscalation field is omitted or set to false.

5.2.6 Create a PSP as described in the Kubernetes documentation, ensuring that the
.spec.runAsUser.rule is set to either MustRunAsNonRoot or MustRunAs with the range of
UIDs not including 0.

5.2.7 Create a PSP as described in the Kubernetes documentation, ensuring that the
.spec.requiredDropCapabilities is set to include either NET_RAW or ALL.

5.2.8 Ensure that allowedCapabilities is not present in PSPs for the cluster unless
it is set to an empty array.

5.2.9 Review the use of capabilites in applications runnning on your cluster. Where a namespace
contains applicaions which do not require any Linux capabities to operate consider adding
a PSP which forbids the admission of containers which do not drop all capabilities.

5.3.1 If the CNI plugin in use does not support network policies, consideration should be given to
making use of a different plugin, or finding an alternate mechanism for restricting traffic
in the Kubernetes cluster.

5.3.2 Follow the documentation and create NetworkPolicy objects as you need them.

5.4.1 if possible, rewrite application code to read secrets from mounted secret files, rather than
from environment variables.

5.4.2 Refer to the secrets management options offered by your cloud provider or a third-party
secrets management solution.

5.5.1 Follow the Kubernetes documentation and setup image provenance.

5.6.1 Follow the documentation and create namespaces for objects in your deployment as you need
them.

5.6.2 Seccomp is an alpha feature currently. By default, all alpha features are disabled. So, you
would need to enable alpha features in the apiserver by passing "--feature-
gates=AllAlpha=true" argument.
Edit the /etc/kubernetes/apiserver file on the master node and set the KUBE_API_ARGS
parameter to "--feature-gates=AllAlpha=true"
KUBE_API_ARGS="--feature-gates=AllAlpha=true"
Based on your system, restart the kube-apiserver service. For example:
systemctl restart kube-apiserver.service
Use annotations to enable the docker/default seccomp profile in your pod definitions. An
example is as below:
apiVersion: v1
kind: Pod
metadata:
name: trustworthy-pod
annotations:
seccomp.security.alpha.kubernetes.io/pod: docker/default
spec:
containers:
- name: trustworthy-container
image: sotrustworthy:latest

5.6.3 Follow the Kubernetes documentation and apply security contexts to your pods. For a
suggested list of security contexts, you may refer to the CIS Security Benchmark for Docker
Containers.

5.6.4 Ensure that namespaces are created to allow for appropriate segregation of Kubernetes
resources and that all new resources are created in a specific namespace.

== Summary ==
0 checks PASS
0 checks FAIL
24 checks WARN
0 checks INFO`

我只收到所有项目的警告。如何验证结果是否与Kubernetes群集相关？我期待着您的来信，并提前表示感谢

致以最良好的祝愿

考沙尔目前（2020年3月）已经 -GKE v.1.0.0的CIS基准 -Kubernetes v.1.5.0的CIS基准

kube-bench -v 3 --logtostderr --benchmark cis-1.5

让我觉得你已经在GKE上运行了Kubernetes基准测试

他说：

下面是一组建议，用于配置Kubernetes以支持强大的安全态势。基准测试与特定的Kubernetes版本相关联。CIS Kubernetes基准是为开源Kubernetes发行版编写的，旨在尽可能普遍适用于所有发行版

如果您正在运行GKE，最好运行专门为GKE设计的基准测试

对于像GKE这样的托管服务，并不是基准上的所有项目都是您的责任，并且有一些建议您不能自己直接审核或修正如果您在GKE上运行，请使用，这是CIS Kubernetes基准的子基准，专门用于GKE发行版。这将从现有CIS基准中提取，但删除用户无法配置或管理的项目，并添加特定于Google云的附加控件

希望这能说明问题。

>“我如何验证结果是否与我的Kubernetes群集相关？”您能更详细地描述这个问题吗？您是否运行过CIS基准测试或CIS GKE基准测试？