共计 9290 个字符,预计需要花费 24 分钟才能阅读完成。
作者: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
参考链接
- 删除启用了特权的 Pod
次要是查看 Pod 是否含 privileged: true
$ kubectl get po xxx -n production -o yaml| grep -i "privileged: true"
- 删除有状态 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 公布!