用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt;运行前请先检查来源。
npx skills add https://github.com/CyberStrikeus/CyberStrike --skill cis-ocp-v160-2-7命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地?可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | cis-ocp-v160-2.7 |
| description | Ensure that a unique Certificate Authority is used for etcd (Manual) |
| category | cis-openshift |
| version | 1.6.0 |
| author | cyberstrike-official |
| tags | ["cis","openshift","kubernetes","redhat","etcd","certificate-authority","ca","tls"] |
| cis_id | 2.7 |
| cis_benchmark | CIS Red Hat OpenShift Container Platform Benchmark v1.6.0 |
| tech_stack | ["kubernetes","openshift","redhat"] |
| cwe_ids | [] |
| chains_with | [] |
| prerequisites | [] |
| severity_boost | {} |
Use a different certificate authority for etcd from the one used for Kubernetes.
etcd is a highly available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. Its access should be restricted to specifically designated clients and peers only.
Authentication to etcd is based on whether the certificate presented was issued by a trusted certificate authority. There is no checking of certificate attributes such as common name or subject alternative name. As such, if any attackers were able to gain access to any certificate issued by the trusted certificate authority, they would be able to gain full access to the etcd database.
Additional management of the certificates and keys for the dedicated certificate authority will be required.
OpenShift 4 includes multiple CAs providing independent chains of trust, which ensure that a platform CA will never accidentally sign a certificate that can be used for the wrong purpose, increasing the security posture of the cluster. OpenShift uses a separate CA for etcd.
These internal self-signing CAs enable automation because the key is known to the cluster. The certificates generated by each CA are used to identify a particular OpenShift platform component to another OpenShift platform component. The OpenShift CAs are managed by the cluster and are only used within the cluster. This means that:
Cluster CAs cannot be influenced by an external CA that the cluster does not control.
Run the following command to check the value of --trusted-ca-file:
for i in $(oc get pods -oname -n openshift-etcd)
do
oc exec -n openshift-etcd -c etcd $i -- \
ps -o command= -C etcd | sed 's/.*\(--trusted-ca-file=[^ ]*\).*/\1/'
done
Run the following command to check the value of --peer-trusted-ca-file:
for i $(oc get pods -oname -n openshift-etcd)
oc -n openshift-etcd -c etcd -- \
ps -o = -C etcd | sed
Verify that --trusted-ca-file=/etc/kubernetes/static-pod-certs/configmaps/etcd-serving-ca/ca-bundle.crt and --peer-trusted-ca-file=/etc/kubernetes/static-pod-certs/configmaps/etcd-peer-client-ca/ca-bundle.crt are returned for each member.
None required. Certificates for etcd are managed by the OpenShift cluster etcd operator.
By default, in OpenShift 4, communication with etcd is secured by the etcd serving CA.
| Controls Version | Control | IG 1 | IG 2 | IG 3 |
|---|---|---|---|---|
| v8 | 3.11 Encrypt Sensitive Data at Rest | X | X | |
| v7 | 14.8 Encrypt Sensitive Information at Rest | X |
| Techniques / Sub-techniques | Tactics | Mitigations |
|---|---|---|
| T1552 | TA0006 | M1022 |
Level 2 (Manual)