2022年11月完成认证

考试环境检测

Suite	Test	Result
streaming	streamingThroughput	Success
Streaming	networkQuality	Success
microphone	audioCapture	Success
microphone	audioLevel	Success
system	operatingSystem	Success

命令补全

搜索 cheatsheet（kubectl 备忘单）
https://kubernetes.io/zh/docs/reference/kubectl/cheatsheet/

source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >> ~/.bashrc

1、AppArmor 访问控制

Context
AppArmor 已在 cluster 的工作节点上被启用。一个 AppArmor 配置文件已存在，但尚未被实施。
Task
在 cluster 的工作节点上，实施位于 /etc/apparmor.d/nginx_apparmor 的现有 AppArmor 配置文件。编辑位于 /home/candidate/KSSH00401/nginx-deploy.yaml 的现有清单文件以应用 AppArmor 配置文件。最后，应用清单文件并创建其中指定的 Pod 。

搜索 apparmor（使用 AppArmor 限制容器对资源的访问），接着再搜索字符串 “parser”
https://kubernetes.io/zh/docs/tutorials/security/apparmor/

### 远程登录到指定工作节点
ssh cka-node01

### 加载 apparmor 配置文件
apparmor_parser -q /etc/apparmor.d/nginx_apparmor

### 查看策略名称，结果是 nginx-profile
apparmor_status | grep nginx

### 回到控制节点，并更新 Pod 的注解
exit

vim /home/candidate/KSSH00401/nginx-deploy.yaml
    annotations:
      ### hello 是 Pod 里容器名称，nginx-profile 则是 apparmor_status 解析出来的结果
      container.apparmor.security.beta.kubernetes.io/hello: localhost/nginx-profile

### 如果 apply 后报错，则先删除保存并删除旧 Pod，改完后再创建新的
kubectl apply -f /home/candidate/KSSH00401/nginx-deploy.yaml

---

2、Kube-Bench 基准测试

Context
针对 kubeadm 创建的 cluster 运行 CIS 基准测试工具时， 发现了多个必须立即解决的问题。
Task
通过配置修复所有问题并重新启动受影响的组件以确保新的设置生效。
修复针对 API 服务器发现的所有以下违规行为：
Ensure that the 1.2.7 --authorization-mode FAIL argument is not set to AlwaysAllow
Ensure that the 1.2.8 --authorization-mode FAIL argument includes Node
Ensure that the 1.2.9 --authorization-mode FAIL argument includes RBAC
Ensure that the 1.2.18 --insecure-bind-address FAIL argument is not set
Ensure that the 1.2.19 --insecure-port FAIL argument is set to 0
修复针对 kubelet 发现的所有以下违规行为：
Ensure that the 4.2.1 --anonymous-auth FAIL argument is set to false
Ensure that the 4.2.2 --authorization-mode FAIL argument is not set to AlwaysAllow
注意：尽可能使用 Webhook authn/authz。
修复针对 etcd 发现的所有以下违规行为：
Ensure that the 4.2.1 --client-cert-auth FAIL argument is set to true

### 修复针对 APIserver 发现的以下所有问题：
### 确保 1.2.7 --authorization-mode 参数不能设置为 AlwaysAllow
### 确保 1.2.8 --authorization-mode 参数包含 Node
### 确保 1.2.9 --authorization-mode 参数包含 RBAC
### 确保 1.2.18 --insecure-bind-address 参数不能设置
### 确保 1.2.19 --insecure-port 参数设置为 0
### 注意：修改 master 节点！
vim /etc/kubernetes/manifests/kube-apiserver.yaml
    #- --authorization-mode=AlwaysAllow
    - --authorization-mode=Node,RBAC
    #- --insecure-bind-address=0.0.0.0
    - --insecure-port=0

### 修复针对 kubelet 发现的以下所有问题：
### 确保 4.2.1 anonymous-auth 参数设置为 false
### 确保 4.2.2 --authorization-mode 参数不能设置为 AlwaysAllow，尽可能使用 webhook authn/authz
### 注意：master 和 node 节点都要修改！
vim /var/lib/kubelet/config.yaml
    authentication:
      anonymous:
        enabled: false
    authorization:
      mode: Webhook

### 修复针对 etcd 发现的以下所有问题：
### 确保 4.2.--client-cert-auth 参数设置为 true
### 注意：修改 master 节点！
vim /etc/kubernetes/manifests/etcd.yaml
    - --client-cert-auth=true

### 加载并重启 kubelet 服务
### 注意：master 和 node 节点都要重启！
systemctl daemon-reload
systemctl restart kubelet

---

3、Trivy 镜像扫描

Task
使用 Trivy 开源容器扫描器检测 namespace kamino 中 Pod 使用的具有严重漏洞的镜像。 查找具有 High 或 Critical 严重性漏洞的镜像，并删除使用这些镜像的 Pod。
注意：Trivy 仅安装在 cluster 的 master 节点上，在工作节点上不可使用。你必须切换到 cluster 的 master 节点才能使用 Trivy 。

搜索 kubectl images（列出集群中所有运行容器的镜像）
https://kubernetes.io/zh-cn/docs/tasks/access-application-cluster/list-all-running-container-images/

### 需登录到控制节点操作
ssh cka-master01

### 查询命名空间 kamino 中 pod 使用的镜像
kubectl get pods -n kamino -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' | sort

### 假设镜像是 registry.aliyuncs.com/google_containers/coredns:1.7.0
### 使用 trivy 工具查询具有 HIGH 或 CRITICAL 漏洞的镜像
trivy --help
trivy image --severity HIGH,CRITICAL 'registry.aliyuncs.com/google_containers/coredns:1.7.0'

### 删除检测到的漏洞镜像对应的 pod（如果有控制器，得删除控制器）
kubectl delete pod -n kamino pod名称

---

4、Sysdig & Falco

Task
使用运行时检测工具来检测 Pod tomcat 单个容器中频发生成和执行的异常进程。有两种工具可供使用：
⚫ sysdig
⚫ falco
注：这些工具只预装在 cluster 的工作节点，不在 master 节点。 使用工具至少分析 30 秒，使用过滤器检查生成和执行的进程，将事件写到 /opt/KSR00101/incidents/summary 文件中，其中包含检测的事件，格式如下：[timestamp],[uid],[processName] 保持工具的原始时间戳格式不变。
注：确保事件文件存储在集群的工作节点上。

### 需登录到工作节点操作
ssh cka-node01

### 查看 sysdig 帮助
sysdig -h

### 查看 sysdig 支持的元数据
sysdig -l

### 查看指定容器ID
crictl ps | grep tomcat

### -M 分析容器30秒，-p 指定事件保存格式，--cri 指定容器运行时，并且保存到指定文件路径中
sysdig -M 30 -p "*%evt.time,%user.uid,%proc.name" --cri /run/containerd/containerd.sock container.id=xxxxx > /opt/KSR00101/incidents/summary

---

5、ServiceAccount

Task

1. 在现有 namespace qa 中创建一个名为 backend-sa 的新 ServiceAccount， 确保此 ServiceAccount 不自动挂载 API 凭据。
2. 使用 /cks/sa/pod1.yaml 中的清单文件来创建一个 Pod。
3. 最后，清理 namespace qa 中任何未使用的 ServiceAccount。

搜索 serviceaccount（为Pod配置服务账号），接着再搜索字符串 “automount”
https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-service-account/

### 创建 ServiceAccount
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: backend-sa
  namespace: qa
automountServiceAccountToken: false
EOF

### 编辑 Pod 使用新创建的 serviceaccount
vim /cks/sa/pod1.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: backend
  name: backend
  namespace: qa
spec:
  serviceAccountName: backend-sa
  containers:
  - image: nginx:1.9
    name: backend
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always

### 应用清单文件
kubectl apply -f /cks/9/pod9.yaml

### 把除了 backend-sa 的 serviceaccount 都删除
kubectl delete -n qa serviceaccount sa名称

---

6、Pod 安全策略-PodSecurityPolicy

Context
PodSecurityPolicy 应防止在特定 namespace 中特权 Pod 的创建。
Task
创建一个名为 restrict-policy 的新的 PodSecurityPolicy，以防止特权 Pod 的创建。 创建一个名为 restrict-access-role 并使用新创建的 PodSecurityPolicy restrict-policy 的 ClusterRole。 在现有的 namespace staging 中创建一个名为 psp-denial-sa 的新 ServiceAccount 。最后，创建一个名为 dany-access-bind 的 ClusterRoleBinding，将新创建的 ClusterRole restrict-access-role 绑定到新创建的 ServiceAccount psp-denial-sa。
你可以在一下位置找到模版清单文件： /cks/psp/psp.yaml

搜索 runasany（Pod Security Policy）
https://kubernetes.io/id/docs/concepts/policy/pod-security-policy/
搜索 clusterrole（使用RBAC鉴权）
https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/

### (1)创建 psp
vim /cks/psp/psp.yaml
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restrict-policy
spec:
  privileged: false
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'

kubectl apply -f /cks/psp/psp.yaml

### (2)创建 clusterrole，使用 psp
kubectl create clusterrole restrict-access-role --verb=use --resource=psp --resource-name=restrict-policy

### (3)创建 serviceaccount
kubectl create serviceaccount psp-denial-sa -n staging 

### (4)创建 clusterrolebinding
kubectl create clusterrolebinding dany-access-bind --clusterrole=restrict-access-role --serviceaccount=staging:psp-denial-sa

### (5)启用 PodSecurityPolicy（在控制节点上修改 apiserver 配置）
vim /etc/kubernetes/manifests/kube-apiserver.yaml
    - --enable-admission-plugins=NodeRestriction,PodSecurityPolicy

systemctl restart kubelet

---

7、NetworkPolicy 拒绝所有出入站流量

Context
一个默认拒绝（default-deny）的 NetworkPolicy 可避免在未定义任何其他 NetworkPolicy 的 namespace 中意外公开 Pod。
Task
为所有类型为 Ingress+Egress 的流量在 namespace testing 中创建一个名为 denypolicy 的新默认拒绝 NetworkPolicy。 此新的 NetworkPolicy 必须拒绝 namespace testing 中的所有的 Ingress + Egress 流量。 将新创建的默认拒绝 NetworkPolicy 应用与在 namespace testing 中运行的所有 Pod。
你可以在 /cks/net/p1.yaml 找到一个模板清单文件。

搜索 networkpolicy（网络策略）
https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/

### 修改模板清单文件
vim /cks/net/p1.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: denypolicy
  namespace: testing
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

### 应用清单文件
kubectl apply -f /cks/net/p1.yaml

---

8、NetworkPolicy

Task
创建一个名为 pod-restriction 的 NetworkPolicy 来限制对在 namespace dev-team 中运行的 Pod products-service 的访问。只允许以下 Pod 连接到 Pod products-service：
⚫namespace qa 中的 Pod
⚫位于任何 namespace，带有标签 environment: testing 的 Pod
注意：确保应用 NetworkPolicy。
你可以在/cks/net/po.yaml 找到一个模板清单文件。

搜索 networkpolicy（网络策略）
https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/

### (1)查看命名空间 qa 具有的标签
kubectl get namespace qa --show-labels

### (2)查看 pod 具有的标签
kubectl get pod products-service -n dev-team --show-labels

### 修改模板清单文件
vim /cks/net/po.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: pod-restriction
  namespace: dev-team
spec:
  podSelector:
    matchLabels:
      run: products-service    ## (2)
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: qa    ## (1)
        - podSelector:
            matchLabels:
              environment: testing
          namespaceSelector: {}    ## 任何命名空间

### 应用清单文件
kubectl apply -f /cks/net/po.yaml

---

9、RBAC/clusterrole

Context
绑定到 Pod 的 ServiceAccount 的 Role 授予过度宽松的权限。完成以下项目以减少权限集。
Task
一个名为 web-pod 的现有 Pod 已在 namespace db 中运行。编辑绑定到 Pod 的 ServiceAccount service-account-web 的现有 Role， 仅允许只对 services 类型的资源执行 get 操作。在 namespace db 中创建一个名为 role-2 ，并仅允许只对 namespaces 类型的资源执行 delete 操作的新 Role。创建一个名为 role-2-binding 的新 RoleBinding，将新创建的 Role 绑定到 Pod 的 ServiceAccount。
注意：请勿删除现有的 RoleBinding。

搜索 clusterrole（使用RBAC鉴权）
https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/

### 查询 sa 对应的 role 名称（假设是 role-1）
kubectl get rolebinding -n db -oyaml | grep 'service-account-web' -B 10

### 修改 role 清单文件（仅允许对 services 类型的资源执行 get 操作）
kubectl edit role -n db role-1
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: role-1
  namespace: db
  resourceVersion: "9528"
rules:
- apiGroups:
    - ""
  resources:
    - services
  verbs:
    - get

### 创建新角色 role-2（仅允许只对 namespaces 类型的资源执行 delete 操作）
kubectl create role role-2 -n db --verb=delete --resource=namespaces

### 创建 rolebinding，并绑定到 sa 上
kubectl create rolebinding role-2-binding --role=role-2 --serviceaccount=db:service-account-web

---

10、kube-apiserver 审计日志记录和采集

Task
在 cluster 中启用审计日志。为此，请启用日志后端，并确保：
⚫ 日志存储在 /var/log/kubernetes/audit-logs.txt
⚫ 日志文件能保留 10 天
⚫ 最多保留 2 个旧审计日志文件
/etc/kubernetes/logpolicy/sample-policy.yaml 提供了基本策略。它仅指定不记录的内容。
注意：基本策略位于 cluster 的 master 节点上。 编辑和扩展基本策略以记录：
⚫ RequestResponse 级别的 cronjobs 更改
⚫ namespace front-apps 中 deployment 更改的请求体
⚫ Metadata 级别的所有 namespace 中的 ConfigMap 和 Secret 的更改
此外，添加一个全方位的规则以在 Metadata 级别记录所有其他请求。
注意：不要忘记应用修改后的策略

搜索 audit（审计）
https://kubernetes.io/zh-cn/docs/tasks/debug/debug-cluster/audit/

### 修改 audit 模板文件
vim /etc/kubernetes/logpolicy/sample-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - "RequestReceived"
rules:
  - level: RequestResponse
    resources:
    - group: ""
      resources: ["cronjobs"]
  - level: Request
    resources:
    - group: ""
      resources: ["deployments"]
    namespaces: ["front-apps"]
  - level: Metadata
    resources:
    - group: ""
      resources: ["secrets", "configmaps"]
  - level: Metadata
    omitStages:
      - "RequestReceived"

### 修改 apiserver 配置文件，启用审计日志
vim /etc/kubernetes/manifests/kube-apiserver.yaml
--audit-policy-file=/etc/kubernetes/logpolicy/sample-policy.yaml
--audit-log-path=/var/log/kubernetes/audit-logs.txt
--audit-log-maxage=10
--audit-log-maxbackup=2

### 在 apiserver 的 Pod 上挂载策略文件和日志文件所在的目录（考试时可能已经挂载好）
vim /etc/kubernetes/manifests/kube-apiserver.yaml
volumeMounts:
  - mountPath: /var/log/kubernetes
    name: kubernetes-logs
  - mountPath: /etc/kubernetes/logpolicy
    name: kubernetes-policy
volumes:
- name: kubernetes-logs
  hostPath:
    path: /var/log/kubernetes
- name: kubernetes-policy
  hostPath:
    path: /etc/kubernetes/logpolicy

### 重载生效配置
systemctl daemon-reload
systemctl restart kubelet

---

11、Secret

Task
在 namespace istio-system 中获取名为 db1-test 的现有 secret 的内容将 username 字段存储在名为 /cks/sec/user.txt 的文件中，并将 password 字段存储在名为 /cks/sec/pass.txt 的文件中。
注意：你必须创建以上两个文件，他们还不存在。
注意：不要在以下步骤中使用/修改先前创建的文件，如果需要，可以创建新的临时文件。
在 istio-system namespace 中创建一个名为 db2-test 的新 secret，内容如下：
username : production-instance
password : KvLftKgs4aVH
最后，创建一个新的 Pod，它可以通过卷访问 secret db2-test ：
Pod 名称 secret-pod
Namespace istio-system
容器名 dev-container
镜像 nginx
卷名 secret-volume
挂载路径 /etc/secret

搜索 secret（使用 kubectl 管理 Secret）
https://kubernetes.io/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kubectl/
搜索 secret（Secret）
https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/

### 检索已存在的 secret，将获取到的用户名和密码字段存储到指定文件
kubectl get secret db1-test -n istio-system -o jsonpath='{.data.username}' | base64 --decode > /cks/sec/user.txt
kubectl get secret db1-test -n istio-system -o jsonpath='{.data.password}' | base64 --decode > /cks/sec/pass.txt

### 创建 secret
kubectl create secret generic db2-test -n istio-system \
  --from-literal=username=production-instance \
  --from-literal=password=KvLftKgs4aVH

### 在 Pod 中以文件形式使用 Secret
vim k8s-secret.yaml
apiVersion: v1
kind: Pod
metadata:
  name: secret-pod
  namespace: istio-system
spec:
  containers:
  - name: dev-container
    image: nginx
    volumeMounts:
    - name: secret-volume
      mountPath: "/etc/secret"
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: db2-test
      optional: false

### 应用清单文件
kubectl apply -f k8s-secret.yaml

### 验证 pod
kubectl get pods -n istio-system dev-pod

---

12、dockerfile 和 deployment 优化部分

Task
分析和编辑给定的 Dockerfile /cks/docker/Dockerfile（基于 ubuntu:16.04 镜像），并修复在文件中拥有的突出的安全/最佳实践问题的两个指令。
分析和编辑给定的清单文件 /cks/docker/deployment.yaml，并修复在文件中拥有突出的安全/最佳实践问题的两个字段。
注意：请勿添加或删除配置设置；只需修改现有的配置设置让以上两个配置设置都不再有安全/最佳实践问题。
注意：如果您需要非特权用户来执行任何项目，请使用用户 ID 65535 的用户 nobody 。
答题： 注意，本次的 Dockerfile 和 deployment.yaml 仅修改即可，无需部署。

### 修复 dockerfile 文件中存在的两个安全/最佳实践指令
### (1)将 root 注释掉；(2)增加 nobody
vim /cks/docker/Dockerfile
FROM ubuntu:16.04
#USER root 
USER nobody

### 修复 deployment 文件中存在的两个安全/最佳实践问题字段
### (1)将 privileged 变为 False；(2)将 readOnlyRootFilesystem 变为 True
vim /cks/docker/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: dev
  name: dev
spec:
  replicas: 1
  selector:
    matchLabels:
			app: dev
	template:
		metadata:
 			labels:
 				app: dev
	spec:
 		containers:
 		- image: mysql
 			name: mysql
 			securityContext: {'capabilities':{'add':['NET_ADMIN'],'drop':['all']},'privileged': False,'readOnlyRootFilesystem': True, 'runAsUser': 65535}

---

13、镜像安全 ImagePolicyWebhook

Context
cluster 上设置了容器镜像扫描器，但尚未完全集成到 cluster 的配置中。完成后，容器镜像扫描器应扫描并拒绝易受攻击的镜像的使用。
Task
注意：你必须在 cluster 的 master 节点上完成整个考题，所有服务和文件都已被准备好并放置在该节点上。 给定一个目录 /etc/kubernetes/epconfig 中不完整的配置以及具有 HTTPS 端点 https://acme.local:8082/image_policy 的功能性容器镜像扫描器：

1. 启用必要的插件来创建镜像策略
2. 校验控制配置并将其更改为隐式拒绝（implicit deny）
3. 编辑配置以正确指向提供的 HTTPS 端点
   最后，通过尝试部署易受攻击的资源 /cks/img/web1.yaml 来测试配置是否有效。你可以在 /var/log/imagepolicy/roadrunner.log 找到容器镜像扫描仪的日志文件。

搜索 imagepolicywebhook（使用准入控制器），接着再搜索字符串"imagepolicywebhook"
https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/admission-controllers/

### (1)修改不完整的配置
cd /etc/kubernetes/epconfig

### (2)验证控制平面的配置并将其更改为拒绝
vim admission_configuration.json
    defaultAllow: false

### (3)编辑配置以正确指向提供的 HTTPS 端点
vim kubeconfig.yaml
    apiVersion: v1
    kind: Config
    clusters:
    - cluster:
        certificate-authority: /etc/kubernetes/epconfig/webhook.pem
        server: https://acme.local:8082/image_policy   # 配置此步
  		name: bouncer_webhook

### (4)启用必要的插件以创建镜像策略
vim /etc/kubernetes/manifests/kube-apiserver.yaml
    - --enable-admission-plugins=NodeRestriction,ImagePolicyWebhook
    - --admission-control-config-file=/etc/kubernetes/epconfig/admission_configuration.json
    ......
    volumeMounts:
    - mountPath: /etc/kubernetes/epconfig
      name: config
    volumes:
    - hostPath:
        path: /etc/kubernetes/epconfig
      name: config

### (5)加载生效配置
systemctl daemon-reload
systemctl restart kubelet

### (6)通过部署易受攻击的资源来测试配置是否有效
kubectl apply -f /cks/img/web1.yaml

---

14、删除非无状态或非不可变的 pod

Task
检查在 namespace production 中运行的 Pod，并删除任何非无状态或非不可变的 Pod。
使用以下对无状态和不可变的严格解释：
⚫ 能够在容器内存储数据的 Pod 的容器必须被视为非无状态的。
⚫ 被配置为任何形式的特权 Pod 必须被视为可能是非无状态和非不可变的。
注意：你不必担心数据是否实际上已经存储在容器中。

### 在命名空间 dev 中检查 running 状态的 pod
kubectl get pods -n production | grep running

### 查看具有特权的 pod
kubectl get pods -n production -oyaml | egrep -i "privileged: true"

### 查看具有 volume 的 pod
kubectl get pods -n production -o jsonpath={.spec.volumes} | jq

### 将查询到的具有特权和 volume 的 pod 都删除
kubectl delete pods -n production pod名称

---

15、gVisor/runtimeclass

Context
该 cluster 使用 containerd 作为 CRI 运行时。containerd 的默认运行时处理程序是 runc。 containerd 已准备好支持额外的运行时处理程序 runsc (gVisor)。
Task
使用名为 runsc 的现有运行时处理程序，创建一个名为 untrusted 的 RuntimeClass。 更新 namespace server 中的所有 Pod 以在 gVisor 上运行。 您可以在 /cks/gVisor/rc.yaml 中找到一个模版清单

搜索 runtimeclass（容器运行时类）
https://kubernetes.io/zh-cn/docs/concepts/containers/runtime-class/

### 修改模板清单文件
vim /cks/gVisor/rc.yaml
    apiVersion: node.k8s.io/v1
    kind: RuntimeClass
    metadata:
      name: untrusted
    handler: runsc

### 应用清单文件
kubectl apply -f /cks/gVisor/rc.yaml

### 修改 server 命名空间下的所有 pod（还需要修改deployment）
kubectl get pods -n server -oyaml > myrc.yaml
vim myrc.yaml
spec:
  ......
  runtimeClassName: untrusted

### 更新清单文件
kubectl delete -f myrc.yaml
kubectl apply -f myrc.yaml

---

16、启用 API Server 认证

Context
由 kubeadm 创建的 cluster 的 Kubernetes API 服务器，出于测试目的，临时配置允许未经身份验证和未经授权的访问，授予匿名用户 cluster-admin 的访问权限。
Task
重新配置 cluster 的 Kubernetes APl 服务器，以确保只允许经过身份验证和授权的 REST 请求。使用授权模式 Node,RBAC 和准入控制器 NodeRestriction。删除用户 system:anonymous 的 ClusterRoleBinding 来进行清理。
注意：所有 kubectl 配置环境/文件也被配置使用未经身份验证和未经授权的访问。 你不必更改它，但请注意，一旦完成 cluster 的安全加固， kubectl 的配置将无法工作。 您可以使用位于 cluster 的 master 节点上，cluster 原本的 kubectl 配置文件 /etc/kubernetes/admin.conf ，以确保经过身份验证的授权的请求仍然被允许。

### (1)使用授权模式 Node,RBAC 和准入控制器 NodeRestriction
### 注意：修改 master 节点！
vim /etc/kubernetes/manifests/kube-apiserver.yaml
    - --authorization-mode=Node,RBAC
    - --enable-admission-plugins=NodeRestriction
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
		- --enable-bootstrap-token-auth=true

### (2)删除 system:anonymous 的 ClusterRolebinding 角色绑定（取消匿名用户的集群管理员权限）
kubectl delete clusterrolebinding system:anonymous

最后，预祝大家顺利通过CKS认证！！！