关于云计算:CKS-认证备考指南

作者：scwang18，次要负责技术架构，在容器云方向颇有钻研。

前言

CKA 和 CKS 是 Linux 基金会联结 CNCF 社区组织的云原生技术畛域权威的技术水平认证考试，考试采纳实操形式进行。CKS 全称是 Certified Kubernetes Security Specialist，它在一个模仿实在的环境中测试考生对 Kubernetes 和云平安的常识。在加入 CKS 考试之前，必须曾经通过 CKA(Kubernetes 管理员认证)，在取得 CKA 证书之后才能够预约 CKS 考试。CKS 的考试难度绝对于 CKA 进步了很多，2 个小时的考试工夫很缓和，因为考试是在外网上进行，这两个考试又是实操考试，网络条件不好，很影响效率，如果不放松的话，很可能做不完所有实操题。揭示备考的同学善用考试软件提供的 notepad 性能，先把 yaml 文件或命令写到 notepad 里，再粘贴到 Terminal 里。

我因为上次 CKA 考试还是比较顺利，所以这次的 CKS 考试有点忽略了，搞忘带身份证和护照，CKA/CKS 考试须要身份证 + 护照 / 信用卡，因而跟监考老师沟通了很久工夫，最初批改了考试人姓名为中文，是用驾驶证实现的考试。意外之喜是 CKS 给我的证书是中文名的。

我这次考试的 Kubernetes 版本是 1.22，特意记录了一下考试会考到的知识点，分享给须要的同学。

补充：Kubernetes 1.25 开始，正式废止了 PSP，这个局部能够参考本文的记录。

NetworkPolicy

通常应用标签选择器来抉择 Pod，管制流量。所以要对 kubectl label 的应用办法熟悉起来。

$ kubectl label [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version] [options]

网络策略的应用办法见正文：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  # podSelector: {} 示意抉择所有 pod 利用 NetworkPolicy
  podSelector: # 示意抉择蕴含标签 role=db 的 pod 利用上面的 NetworkPolicy
    matchLabels:
      role: db
  policyTypes: # 示意 NetworkPolicy 蕴含 ingress 和 egress 流量规定
  - Ingress
  - Egress
  ingress: 
  # ingress 规定白名单列表，每条规定包含 from 和 ports 两个属性。# 如果不设置 ingress 或者 ingress 为空值，将禁止该类型流量。# from 和 ports 属性如果没有设置或者为空 {}，示意匹配所有，这一点同 podSelector 一样。# inress 规定是数组，多条规定之间是 or 关系。# 以下示例中，第 1 条白名单，蕴含 from + ports 的组合规定，容许来自 172.17 网段 (172.17.1 除外)、或标签 project=myproject 的命名空间的所 有 pod、或 default 命名空间下标签 role=frontend 的 pod 拜访（限 tcp 6379 端口）- from: 
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  # 第二条白名单，只蕴含 from 规定，容许来自所有命名空间蕴含 environment=testing 标签的 pod 拜访（不限端口）- from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          environment: testing
  egress: 
  # egress 规定白名单列表，同 ingress 规定一样，蕴含 to 和 ports 两个属性。# 如果不设置 egress 或者 egress 为空值，将禁止该类型流量。# to 和 ports 属性如果没有设置或者为空 {}，示意匹配所有，这一点同 podSelector 一样。# egress 规定是数组，多条规定之间是 or 关系。# {} 代表全副放行

  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

Apparmor

查看以后节点加载的 apparmor profile，如果没有加载，要手工加载。

$ apparmor_status|grep nginx

$ apparmor_parser /etc/apparmor.d/nginx_apparmor

CKS 考试的 apparmor profile 文件内容：

#include <tunables/global>
#nginx-profile-3  
profile nginx-profile-3 flags=(attach_disconnected) {
  #include <abstractions/base>
  file,
  # Deny all file writes.
  deny /** w,
}

留神：nginx-profile-3 这一行要确保正文掉，考试环境提供的可能没有正文，加载配置文件按时会报错。

$ apparmor_parser  /etc/apparmor.d/nginx_apparmor
AppArmor parser error for /etc/apparmor.d/nginx_apparmor in /etc/apparmor.d/ninx_apparmor at line 2: Found unexpected character: '-'

批改 Pod yaml 文件，在正文里设置为 Pod 加载 apparmor profile。

annotations:
  container.apparmor.security.beta.kubernetes.io/podx: localhost/nginx-profile-3

yaml 文件内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: podx
  annotations:
    container.apparmor.security.beta.kubernetes.io/podx: localhost/nginx-profile-3
spec:
  containers:
  - image: busybox
    imagePullPolicy: IfNotPresent
    name: podx
    command: ["sh", "-c", "echo'Hello AppArmor!'&& sleep 1h"]
    resources: {}
  nodeName: node01
  dnsPolicy: ClusterFirst
  restartPolicy: Always

修复 kube-bench 发现的平安问题

kube-bench 是一个 CIS 评估工具，扫描 Kubernetes 集群存在的平安问题，基本上依照扫描后果的修复倡议进行修复就能够了，零碎会给出很具体的修复措施。

# 修复 kube-apiserver 平安问题
$ vi /etc/kubernetes/manifests/kube-apiserver
#批改：--authorization-mode=Node,RBAC
#增加
--insecure-port=0
#删除
# --insecure-bind-address=0.0.0.0

#修复 kubelet 平安问题
$ vi /var/lib/kubelet/config.yaml
# 将 authentication.anonymous.enabled 设置为 false
authentication:
  anonymous:
    enabled: false
# authorization.mode 设置为 Webhook
authorization:
  mode: Webhook
  
# 修复 etcd 平安问题
$ vi /etc/kubernetes/manifests/etcd.yaml
# 批改为 true：- --client-cert-auth=true

# 以上修复实现后，从新加载配置文件并重启 kubelet

$ systemctl daemon-reload
$ systemctl restart kubelet

解决 Pod 的 serviceaccount 设置谬误问题

这个题要留神 serviceaccount 有个选项 automountServiceAccountToken, 这个选项决定是否主动挂载 Secret 到 Pod。
有这个选项，咱们能够管制 Pod 创立并绑定 serviceaccount 时，不主动挂载对应的 Secret，这样 Pod 就没有权限拜访 apiserver，进步了业务 Pod 的安全性。

能够在 serviceaccount 和 Pod 的 spec 里设置，Pod 的设置优先于 serviceaccount 里的设置。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: backend-sa 
  namespace: qa 
automountServiceAccountToken: false

apiVersion: v1
kind: Pod
metadata:
  name: backend
  namespace: qa
spec:
  serviceAccountName: backend-sa
  containers:
  - image: nginx:1.9
    imagePullPolicy: IfNotPresent
    name: backend

删除未应用的 serviceaccount

设置默认网络策略

这道题是送分题，设置默认回绝所有出站和入站的 Pod 流量，基本上能够参考官网的案例间接改一下名字就能够了。

默认网络策略

RBAC

这道题也根本是送分题，参考官网文档，依据题目要求，设置 role 的 资源拜访权限，绑定到 serviceaccount 就能够了。

RBAC

日志审计

这道题稍简单，须要依照要求启动日志审计，包含两个步骤：

(1) 编写日志审计策略文件。

日志审计策略。

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - "RequestReceived"
rules:
  - level: RequestResponse   
    resources:
    - group: ""resources: ["namespaces"]
  
  - level: Request
    resources:
    - group: ""resources: ["persistentvolumes"] 
    namespaces: ["front-apps"]

  - level: Metadata
    resources:
    - group: ""resources: ["secrets","configmaps"]

  - level: Metadata
    omitStages:
      - "RequestReceived"

(2) 批改 kube-apiserver.yaml 配置文件，启用日志审计策略，日志策略配置文件地位、日志文件存储地位、循环周期。

启动日志配置

# /etc/kubernetes/manifests/kube-apiserver.yaml

...
# 设置日志审计策略文件在 pod 里的 mount 地位
- --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

# mount 日志策略和日志文件的
volumeMounts:
  - mountPath: /etc/kubernetes/logpolicy/sample-policy.yaml
    name: audit
    readOnly: true
  - mountPath: /var/log/kubernetes/audit-logs.txt
    name: audit-log
    readOnly: false
volumes:
  - name: audit
    hostPath:
      path: /etc/kubernetes/logpolicy/sample-policy.yaml
      type: File
  - name: audit-log
    hostPath:
      path: /var/log/kubernetes/audit-logs.txt
      type: FileOrCreate

重启 kubelet。

$ systemctl daemon-reload
$ systemctl restart kubelet

创立 Secret

这道题考解码 Secret 的 base64 编码信息，创立新的 Secret 并 mount 到 Pod 的特定地位。

[解码 Secret](https://kubernetes.io/zh/docs…
)。

$ kubectl get secrets -n istio-system db1-test -o jsonpath={.data.username} | base64 -d >  /cks/sec/user.txt
$ kubectl get secrets -n istio-system db1-test -o jsonpath={.data.password} | base64 -d >  /cks/sec/pass.txt

[创立 Secret](https://kubernetes.io/zh/docs…
)。

$ kubectl create secret generic db2-test -n istio-system --from-literal=username=production-instance --from-literal=password=KvLftKgs4aVH

应用 Secret。

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
  volumes:
  - name:
    secret:
      secretName: db2-test

检测 Dockerfile 的不平安指令

这道题也是送分题，次要是把 Dockerfile 里应用 root 用户的指令删除，把增加特定能力的 securityContext 平安上下文正文掉。

# 删除两处
USER root

# 正文 securityContext
# securityContext:
#   {"Capabilities": {'add':{NET_BIND_SERVICE}, 'drop: []'}, 'privileged': TRUE}

运行沙箱容器

反对平安沙箱容器运行时 handler runsc，咱们须要创立一个 RuntimeClass 并在 Pod spec 里指定是用该 RuntimeClass。

参考资料

• 创立 RuntimeClass

  apiVersion: node.k8s.io/v1beta1
  kind: RuntimeClass
  metadata:
  name: untrusted 
  handler: runsc

• 批改 server 命名空间里所有 Pod，设置 runtimeClassName

留神：运行中的 pod 只能批改无限的几个属性，不反对批改 RuntimeClass，须要将所有 pod 的 yaml 解析进去，批改 yaml 后，再从新创立 pod

还须要批改 deployment：

    spec:。runtimeClassName: untrusted 
      containers:
      - image: vicuu/nginx:host
        imagePullPolicy: IfNotPresent
        name: nginx-host

删除不合乎最佳实际的 Pod

参考链接

1. 删除启用了特权的 Pod

次要是查看 Pod 是否含 privileged: true

$ kubectl get po xxx -n production -o yaml| grep -i "privileged: true"

2. 删除有状态 Pod

$ kubectl get pods XXXX -n production -o jsonpath={.spec.volumes} | jq

扫描镜像安全漏洞并删除应用有安全漏洞镜像的 Pod

这道题考查对于镜像扫描工具 trivy 的应用

# 获取镜像名
$ kubect get pod XXXX -n kamino -o yaml | grep image
# 扫描镜像
$ trivy image -s HIGH,CRITICAL imagename
# kubectl delete po xxx

应用 sysdig 查看容器里里的异样过程

本体考查是否把握 sysdig 的根本用法，记住两个帮忙命令：

• sysdig -h 查看 sysdig 帮忙
• sysdig -l 查看 sysdig 反对的元数据

另外 sysdig 反对指定 Containerid 剖析特定容器。

# 查看容器 id
$ docker ps |grep tomcat
$ sysdig -M 30 -p "*%evt.time,%user.uid,%proc.name" container.id=xxxx>opt/DFA/incidents/summary

PodSecurityPolicy

这道题考查是否把握 PSP 的用法。包含 5 步骤。

(1) 创立 PSP。

参考链接

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:
  - '*'

(2) 创立 clusterrole，应用 PSP

$ kubectl create clusterrole restrict-access-role --verb=use --resource=psp --resource-name=restrict-policy

(3) 创立 serviceaccount

$ kubectl create sa psp-denial-sa -n staging

(4) 绑定 clusterrole 到 serviceaccount

$ kubectl create clusterrolebinding dany-access-bind --clusterrole=restrict-access-role --serviceaccount=staging:psp-denial-sa

(5) 启用 PodSecurityPolicy

$ vi /etc/kubernetes/manifests/kube-apiserver.yaml 
#确保有以下内容：- --enable-admission-plugins=NodeRestriction,PodSecurityPolicy

启用 API server 认证

这道题同后面 kube-bench 的考核内容有点重合，题目中是用 kubeadm 创立的 Kubernetes 服务器权限设置有问题，容许未经受权的拜访。

参考链接

须要进行以下批改：

• 应用 Node,RBAC 受权模式和 NodeRestriction 准入控制器。

$ vi /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

• 删除 system:anonymous 的 ClusterRolebinding 角色绑定，勾销匿名用户的集群管理员权限。

$ kubectl delete clusterrolebinding system:anonymous

ImagePolicyWebhook

这道题考查 ImagePolicyWebhook 准入控制器的应用，分 4 个步骤。

• 批改控制器配置文件，将未找到无效后端时的默认回绝改为默认不回绝。

参考链接

# /etc/kubernetes/epconfig/admission_configuration.json

{

  "imagePolicy": {
     "kubeConfigFile": "/etc/kubernetes/epconfig/kubeconfig.yaml",
     "allowTTL": 50,
     "denyTTL": 50,
     "retryBackoff": 500,
     "defaultAllow": false
  }
}

• 批改 控制器拜访 webhook server 的 kubeconfig。

# /etc/kubernetes/epconfig/kubeconfig.yaml

apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority: /etc/kubernetes/epconfig/webhook.pem
    server: https://acme.local:8082/image_policy  # web hook server 的地址
  name: bouncer_webhook
# 以下省略 

• 启用 ImagePolicyWebhook。

# /etc/kubernetes/manifests/kube-apiserver.yaml

# 启用 ImagePolicyWebhook
- --enable-admission-plugins=NodeRestriction,ImagePolicyWebhook
# 指定准入控制器配置文件
- --admission-control-config-file=/etc/kubernetes/epconfig/admission_configuration.json
# mount
    volumeMounts:
    - mountPath: /etc/kubernetes/epconfig
      name: epconfig
# 映射 volumes      
  volumes:
    - name: epconfig
    hostPath:
      path: /etc/kubernetes/epconfig

• 测试是否失效。

$ systemctl daemon-reload
$ systemctl restart kubelet
$ kubectl apply -f /cks/img/web1.yaml

本文由博客一文多发平台 OpenWrite 公布！