CKS认证工程师的16个Kubernetes安全加固实战技巧

1. 从CKS考试到生产环境的实战跨越

通过CKS认证只是Kubernetes安全之旅的起点。在实际生产环境中，安全配置远比考试场景复杂多变。许多工程师在通过考试后，面对真实集群的安全加固需求时仍会感到无从下手。本文将分享16个经过实战验证的安全配置技巧，帮助你将考试知识转化为生产力。

为什么这些经验值得关注？

• 基于最新Kubernetes 1.28版本的安全实践
• 每个技巧都经过生产环境验证
• 不仅告诉你"怎么做"，更解释"为什么这么做"
• 覆盖从基础配置到高级防御的完整链条

2. 基础安全配置：构建第一道防线

2.1 API Server安全加固

API Server是Kubernetes集群的"大脑"，也是攻击者的首要目标。以下是必须实施的加固措施：

# /etc/kubernetes/manifests/kube-apiserver.yaml关键配置
spec:
  containers:
  - command:
    - kube-apiserver
    - --authorization-mode=Node,RBAC
    - --anonymous-auth=false
    - --enable-admission-plugins=NodeRestriction
    - --tls-min-version=VersionTLS13
    - --tls-cipher-suites=TLS_AES_128_GCM_SHA256

关键参数解析：

参数	安全意义	推荐值
anonymous-auth	禁止匿名访问	false
authorization-mode	授权模式	Node,RBAC
admission-plugins	准入控制	NodeRestriction
tls-min-version	最低TLS版本	VersionTLS13

提示：修改API Server配置后，需要执行systemctl daemon-reload && systemctl restart kubelet使变更生效

2.2 kubelet安全配置

kubelet是工作节点上的关键组件，不当配置可能导致容器逃逸：

# 检查当前kubelet配置
cat /var/lib/kubelet/config.yaml | grep -E 'anonymous|authorization'

应确保以下配置：

authentication:
  anonymous:
    enabled: false
authorization:
  mode: Webhook

2.3 etcd加密配置

etcd存储着集群的所有敏感数据，必须启用加密：

# /etc/kubernetes/manifests/etcd.yaml关键配置
- --client-cert-auth=true
- --cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

3. 身份认证与访问控制

3.1 ServiceAccount安全实践

ServiceAccount是Pod访问API Server的凭证，需要严格管理：

# 安全ServiceAccount示例
apiVersion: v1
kind: ServiceAccount
metadata:
  name: backend-sa
  namespace: qa
automountServiceAccountToken: false  # 禁止自动挂载token

最佳实践：

• 命名以"-sa"结尾便于识别
• 按最小权限原则分配角色
• 定期清理未使用的ServiceAccount

3.2 RBAC精细化控制

避免使用过于宽松的ClusterRole，按需创建定制化角色：

# 创建仅能get services的Role
kubectl create role service-reader --verb=get --resource=services -n db

# 创建仅能delete namespaces的Role
kubectl create role namespace-deleter --verb=delete --resource=namespaces -n db

3.3 清理高风险绑定

定期检查并清理不必要的ClusterRoleBinding：

# 查找并删除匿名用户的cluster-admin绑定
kubectl get clusterrolebinding system:anonymous
kubectl delete clusterrolebinding system:anonymous

4. 网络隔离策略

4.1 默认拒绝策略

在关键namespace实施默认拒绝策略：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: testing
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

4.2 精细化网络控制

按需开放特定Pod间的通信：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: pod-restriction
  namespace: dev-team
spec:
  podSelector:
    matchLabels:
      app: products-service
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: qaqa
    - podSelector:
        matchLabels:
          environment: testing

5. 运行时安全

5.1 容器安全上下文

通过securityContext限制容器权限：

securityContext:
  runAsUser: 30000  # 非root用户
  allowPrivilegeEscalation: false  # 禁止提权
  readOnlyRootFilesystem: true  # 只读根文件系统

5.2 沙箱运行时gVisor

对不可信工作负载使用gVisor隔离：

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: untrusted
handler: runsc  # gVisor运行时

在Deployment中引用：

spec:
  runtimeClassName: untrusted

5.3 AppArmor配置

启用AppArmor配置文件增强容器安全：

# 加载AppArmor配置
apparmor_parser /etc/apparmor.d/nginx_apparmor

在Pod中应用：

metadata:
  annotations:
    container.apparmor.security.beta.kubernetes.io/<container-name>: localhost/nginx-profile-3

6. 镜像安全

6.1 漏洞扫描与Trivy实践

使用Trivy扫描镜像漏洞：

# 扫描指定namespace所有镜像
kubectl get pods -n kamino -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | sort -u | xargs -I{} trivy image --severity HIGH,CRITICAL {}

高危镜像处理流程：

1. 识别使用高危镜像的Pod
2. 通知相关团队更新镜像
3. 强制删除仍在使用高危镜像的Pod

6.2 ImagePolicyWebhook配置

通过准入控制阻止高危镜像部署：

// /etc/kubernetes/epconfig/admission_configuration.json
{
  "imagePolicy": {
    "kubeConfigFile": "/etc/kubernetes/epconfig/kubeconfig.yml",
    "allowTTL": 50,
    "denyTTL": 50,
    "retryBackoff": 500,
    "defaultAllow": false  # 隐式拒绝
  }
}

API Server启用插件：

- --enable-admission-plugins=NodeRestriction,ImagePolicyWebhook
- --admission-control-config-file=/etc/kubernetes/epconfig/admission_configuration.json

7. 安全监控与审计

7.1 日志审计配置

启用API Server审计日志：

# /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  # 保留10天
- --audit-log-maxbackup=2  # 保留2个备份

审计策略示例：

rules:
- level: RequestResponse
  resources:
  - group: ""
    resources: ["persistentvolumes"]
- level: Request
  resources:
  - group: ""
    resources: ["configmaps"]
    namespaces: ["front-apps"]
- level: Metadata
  resources:
  - group: ""
    resources: ["secrets", "configmaps"]

7.2 运行时监控与Falco

使用Falco检测异常活动：

# 自定义规则监控特定容器
cat > /etc/falco/falco_rules.local.yaml <<EOF
- rule: Redis异常进程
  desc: 检测Redis容器中的异常进程
  condition: container.name = "redis123" and proc.name != "redis-server"
  output: "%evt.time,%user.uid,%proc.name"
  priority: WARNING
EOF

# 运行监控
falco -M 30 -r /etc/falco/falco_rules.local.yaml > /opt/KSR00101/incidents/summary

8. 敏感数据保护

8.1 Secret管理实践

安全创建和使用Secret：

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

在Pod中安全使用：

volumes:
- name: secret-volume
  secret:
    secretName: db2-test
containers:
- volumeMounts:
  - name: secret-volume
    mountPath: /etc/secret
    readOnly: true

8.2 Dockerfile安全

安全Dockerfile编写要点：

FROM ubuntu:16.04
USER nobody  # 非root用户
# 不要使用ADD，优先使用COPY
COPY --chown=nobody:nobody app /app
# 明确声明暴露端口
EXPOSE 8080
# 使用数组格式的CMD
CMD ["nginx", "-g", "daemon off;"]

9. 持续安全实践

安全配置不是一次性的工作，而需要持续维护：

1. 定期扫描：每周运行kube-bench和Trivy扫描
2. 配置检查：使用kubectl和audit2rbac检查RBAC配置
3. 版本更新：及时升级Kubernetes和容器运行时
4. 备份验证：定期备份etcd并验证恢复流程
5. 人员培训：定期进行安全意识和技能培训

生产环境检查清单：

• [ ] 所有节点已安装最新安全补丁
• [ ] API Server认证和授权配置正确
• [ ] 网络策略覆盖所有关键namespace
• [ ] 容器运行时使用适当隔离技术
• [ ] 敏感数据全部通过Secret管理
• [ ] 审计日志已启用并定期分析
• [ ] 存在应急响应和恢复计划