Meta Description: 阿里云国际版ACK Kubernetes安全加固完整指南：RAM RBAC权限模型、Pod安全标准(PSS)、NetworkPolicy网络隔离、镜像漏洞扫描与签名、KMS密钥加密、审计日志与合规检查，从0构建零信任容器安全体系。

关键词：阿里云国际版、ACK安全、Kubernetes RBAC、Pod Security Standards、NetworkPolicy、镜像安全扫描、KMS密钥管理、容器安全最佳实践、零信任安全

前言

2026年，Kubernetes已经成为云原生应用的事实标准，但伴随容器化普及而来的安全事件也在急剧上升。根据CNCF最新报告，超过67%的Kubernetes安全事件由配置错误引起——过度宽松的RBAC权限、未配置的Pod安全策略、任何Pod可访问的元数据服务、以及硬编码在ConfigMap中的数据库密码，都是攻击者最常利用的突破口。

阿里云国际版ACK（Alibaba Cloud Container Service for Kubernetes）在Kubernetes原生安全机制之上，深度集成了阿里云RAM（Resource Access Management）、KMS（Key Management Service）、安全中心等云原生安全能力，为出海企业提供了一套从身份认证 → 权限控制 → 网络隔离 → 镜像安全 → 密钥加密 → 审计合规的完整安全防护链。

本文将基于ACK生产环境实战经验，逐层拆解容器安全落地的关键步骤和常见踩坑点。

ACK安全体系总览：纵深防御的六层模型

容器安全不是单一控制点的问题，而是需要在多个层面建立纵深防御。ACK的安全体系可以归纳为以下六层模型：

┌──────────────────────────────────────────────┐
│  ⑥ 审计与合规层：日志审计、配置巡检、合规报告    │
├──────────────────────────────────────────────┤
│  ⑤ 密钥管理层：KMS加密、Sealed Secrets、CSI    │
├──────────────────────────────────────────────┤
│  ④ 镜像安全层：扫描、签名、准入控制              │
├──────────────────────────────────────────────┤
│  ③ 网络安全层：NetworkPolicy、Terway、安全组     │
├──────────────────────────────────────────────┤
│  ② Pod安全层：Pod Security Standards、AppArmor │
├──────────────────────────────────────────────┤
│  ① 认证授权层：RAM RBAC、集群角色、命名空间隔离    │
└──────────────────────────────────────────────┘

每一层都是攻击者必须突破的防线。接下来我们逐层展开，每一节都配有可执行的命令和配置示例。

第一层：RAM RBAC 权限体系——让最小权限原则落地

ACK的认证授权体系分为两层：RAM层（阿里云账号/子账号/角色）和Kubernetes RBAC层（ClusterRole/Role + ClusterRoleBinding/RoleBinding）。两层之间通过ram-user或ram-role进行映射。

RAM层：通过RAM角色实现身份联合

不建议直接给开发者分配RAM子账号的AK/SK，更好的方式是使用RAM角色（AssumeRole），通过STS临时凭证访问集群。阿里云国际版支持多种身份联合方式：

# 创建RAM角色，并配置信任策略允许子账号扮演
aliyun ram CreateRole \
  --RoleName ack-developer-role \
  --AssumeRolePolicyDocument '{
    "Statement": [{
      "Action": "sts:AssumeRole",
      "Effect": "Allow",
      "Principal": {"RAM": ["acs:ram::123456789:user/dev-zhangsan"]}
    }],
    "Version": "1"
  }' \
  --Description "ACK Developer Role - Read/Write in dev namespace"

# 授予集群访问权限
aliyun cs GrantPermissions \
  --uid <sub-account-uid> \
  --permissions '[{
    "cluster": "c-xxx",
    "role_name": "dev-role",
    "role_type": "cluster",
    "namespace": "dev",
    "is_custom": true
  }]'

Kubernetes RBAC层：命名空间级别的细粒度控制

RAM层只控制"能不能访问集群"，进入集群后具体能做什么由Kubernetes RBAC控制：

# 开发者在 dev 命名空间的角色
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: dev-role
rules:
  - apiGroups: ["", "apps", "batch", "networking.k8s.io"]
    resources: ["pods", "pods/log", "pods/exec", "deployments", "services", "configmaps", "secrets"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  # 注意：不包含 secrets/data，避免读取Secret内容
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get", "list"]
    resourceNames: ["dev-app-config"]  # 仅允许读取指定Secret
---
# 绑定到RAM用户组
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-binding
  namespace: dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: dev-role
subjects:
  - kind: Group
    name: "dev-team"
    apiGroup: rbac.authorization.k8s.io

RBAC权限安全对照表

以下表格总结了不同角色在ACK集群中应该拥有的最小权限范围：

常见RBAC配置错误与修复

错误1：将cluster-admin直接绑定到RAM用户

# ❌ 错误：给普通开发者绑定 cluster-admin
kubectl create clusterrolebinding dev-admin \
  --clusterrole=cluster-admin \
  --user=ram-user-12345

# ✅ 正确：先确认用户权限范围
kubectl auth can-i --list --as=ram-user-12345
kubectl create rolebinding dev-binding \
  --role=dev-role --user=ram-user-12345 -n dev

错误2：用通配符授予所有资源的操作

# ❌ 危险：星号通配所有资源和动词
rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]

# ✅ 安全：明确列出需要的资源和动词
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "update"]

第二层：Pod安全标准——防止容器逃逸和权限提升

从Kubernetes 1.25开始，Pod Security Policy（PSP）被正式移除，取而代之的是Pod Security Admission（PSA）和Pod Security Standards（PSS）。ACK提供了三种安全级别：

三级安全标准对比

在ACK集群中启用Pod安全标准

ACK支持通过命名空间标签启用PSA：

# 将生产命名空间设置为 restricted 级别
kubectl label ns production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

# 将开发命名空间设置为 baseline 级别（允许更宽松的调试）
kubectl label ns dev \
  pod-security.kubernetes.io/enforce=baseline

# 将系统命名空间设置为 privileged（CNI、CSI驱动等需要）
kubectl label ns kube-system \
  pod-security.kubernetes.io/enforce=privileged

生产级Pod安全配置示例

apiVersion: v1
kind: Pod
metadata:
  name: secure-web-app
  namespace: production
spec:
  # ✅ 安全上下文：非root运行 + 只读根文件系统
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
  
  containers:
    - name: app
      image: registry.ap-southeast-1.aliyuncs.com/my-repo/app:v1.0
      
      # ✅ 容器级安全上下文
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL
          # 仅在必要时添加
          # add: ["NET_BIND_SERVICE"]
      
      # ✅ 资源限制（防止DoS）
      resources:
        limits:
          cpu: "1000m"
          memory: "512Mi"
        requests:
          cpu: "500m"
          memory: "256Mi"
      
      # ✅ 只读挂载点 + 临时目录
      volumeMounts:
        - name: tmp
          mountPath: /tmp
        - name: cache
          mountPath: /var/cache
  
  volumes:
    - name: tmp
      emptyDir: {}
    - name: cache
      emptyDir: {}

关键点总结：

• runAsNonRoot: true 强制以非root用户运行，防止容器内提权后获得宿主机root
• allowPrivilegeEscalation: false 禁止容器内的进程获得比父进程更多的权限
• readOnlyRootFilesystem: true 防止攻击者在容器文件系统上写入恶意文件
• seccompProfile: RuntimeDefault 限制容器可以执行的系统调用
• drop: [ALL] 移除所有Linux capabilities，仅添加必要的最小集合

第三层：NetworkPolicy 网络策略——微分段隔离

默认情况下，Kubernetes集群内所有Pod可以互相通信，这在安全上是不可接受的。NetworkPolicy通过标签选择器实现Pod间的白名单通信控制。

ACK网络插件选择

ACK支持两种CNI网络插件：Flannel和Terway。只有Terway完整支持Kubernetes原生NetworkPolicy。如果你的集群使用Flannel模式，需要通过Calico或Cilium来实现网络策略。

# 查看当前集群CNI插件
kubectl get pods -n kube-system | grep -E "flannel|terway|calico|cilium"

# Terway模式下直接创建NetworkPolicy
# Flannel模式下需要先部署Calico（阿里云ACK应用市场一键部署）

三层网络隔离策略设计

---
# 策略1：默认拒绝所有入站流量（零信任基线）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}          # 选中命名空间内所有Pod
  policyTypes:
    - Ingress

---
# 策略2：仅允许前端Pod访问API Pod的8080端口
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-server
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

---
# 策略3：仅允许API Pod访问数据库Pod的5432端口
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-database
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api-server
        - podSelector:      # 允许监控工具访问
            matchLabels:
              app: prometheus-exporter
      ports:
        - protocol: TCP
          port: 5432

---
# 策略4：限制出口流量，禁止访问外部未知地址
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-egress
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-server
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              app: postgres
      ports:
        - protocol: TCP
          port: 5432
    # 允许DNS查询
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53

NetworkPolicy 调试命令

# 验证某个Pod是否能访问另一个Pod
kubectl run test --rm -it --image=busybox --restart=Never -- wget -qO- --timeout=2 http://api-server:8080/health

# 查看命名空间内所有NetworkPolicy
kubectl get networkpolicies -n production

# 诊断：查看某个Pod上实际生效的网络策略
kubectl describe pod -l app=api-server -n production | grep -A5 "NetworkPolicy"

第四层：镜像安全——扫描、签名与准入控制

镜像安全被很多团队忽视，但实际上它是最常见的供应链攻击面之一。阿里云国际版容器镜像服务ACR（Alibaba Cloud Container Registry）提供了完整的镜像安全能力。

镜像安全扫描

# 手动触发镜像扫描（ACR企业版）
aliyun cr StartImageScan \
  --RegionId ap-southeast-1 \
  --InstanceId cri-xxx \
  --RepoName my-repo/app \
  --Tag v1.0

# 查询扫描结果
aliyun cr DescribeImageScanResults \
  --InstanceId cri-xxx \
  --RepoName my-repo/app \
  --Tag v1.0

# 查看严重级别的漏洞
aliyun cr DescribeImageVulnerabilities \
  --InstanceId cri-xxx \
  --RepoName my-repo/app \
  --Tag v1.0 \
  --Severity High

镜像安全标准对比

通过Kyverno实施镜像来源策略

Kyverno是阿里云ACK推荐的策略引擎，可以与ACR深度集成。以下策略确保仅部署来自自家ACR仓库且通过扫描的镜像：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-image-registries
spec:
  validationFailureAction: Enforce
  rules:
    - name: validate-registries
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "镜像必须来源于允许的ACR仓库"
        pattern:
          spec:
            containers:
              - image: "registry.ap-southeast-1.aliyuncs.com/my-org/*"
---
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
spec:
  validationFailureAction: Enforce
  rules:
    - name: require-image-tag
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "禁止使用 latest 标签，必须指定明确的版本号"
        pattern:
          spec:
            containers:
              - image: "!*:latest"

Dockerfile安全最佳实践

# ✅ 安全Dockerfile示例
FROM registry.ap-southeast-1.aliyuncs.com/my-org/alpine:3.19

# 1. 创建非root用户
RUN addgroup -g 1000 appgroup && \
    adduser -u 1000 -G appgroup -s /bin/sh -D appuser

# 2. 安装依赖并清理缓存（减少攻击面）
RUN apk add --no-cache ca-certificates tzdata && \
    rm -rf /var/cache/apk/*

# 3. 复制应用（而非使用root构建）
COPY --chown=appuser:appgroup ./app /app

# 4. 切换用户
USER appuser

# 5. 不暴露不必要的端口
EXPOSE 8080

# 6. 不使用CMD中的shell模式（避免信号转发问题）
ENTRYPOINT ["/app/server"]

第五层：密钥管理——告别硬编码密码

密钥管理是容器安全最薄弱的环节之一。在ACK中，推荐使用阿里云KMS进行密钥的加密存储和自动轮换。

Secret管理方案对比

使用KMS CSI Driver加密Secret

# 1. 在ACK集群中安装 csi-secrets-store-provider-alibabacloud
# 通过ACK应用市场一键部署

# 2. 创建SecretProviderClass
cat << 'EOF' | kubectl apply -f -
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: db-credentials
  namespace: production
spec:
  provider: alibabacloud
  parameters:
    objects: |
      - objectName: "prod-db-password"
        objectType: "secret"
        objectVersion: "latest"
    regionId: "ap-southeast-1"
    keyId: "your-kms-key-id"
EOF

# 3. 在Pod中挂载CSI卷
# 挂载后Secret以文件形式存在于 /mnt/secrets-store/

生产环境密钥管理清单

• [ ] 所有数据库密码、API密钥、证书使用KMS加密存储
• [ ] 禁止在ConfigMap中存储敏感信息（ConfigMap不加密）
• [ ] Git仓库中不包含任何Secret的明文YAML文件
• [ ] 为CI/CD系统创建专用的最小权限Secret访问角色
• [ ] 启用Secret的定期轮换（建议周期：90天）
• [ ] 配置告警：当Secret在非预期的命名空间中被读取时触发

第六层：审计与合规——可观测的安全

安全不是"一次性配置好就完了"的事情。ACK提供了集群审计日志、配置巡检和安全评分功能，帮助持续监控安全状态。

启用API Server审计日志

# 启用集群审计日志（ACK控制台 → 集群详情 → 日志中心 → 审计日志）
# 也可以CLI启用
aliyun cs UpdateClusterAuditLogConfig \
  --ClusterId c-xxx \
  --AuditLogEnabled true \
  --SlsProjectName k8s-log-c-xxx

审计日志关键查询场景

# SLS查询语句示例

# 1. 检测可疑的exec操作（可能是攻击者尝试在Pod中执行命令）
* | SELECT "user.username", "objectRef.namespace", "objectRef.name"
    WHERE "verb" = 'create'
      AND "objectRef.subresource" = 'exec'
      AND "responseStatus.code" < 400

# 2. 检测Secret的异常读取
* | SELECT "user.username", "objectRef.namespace", "objectRef.name", count(*) as cnt
    WHERE "verb" = 'get'
      AND "objectRef.resource" = 'secrets'
    GROUP BY "user.username", "objectRef.namespace", "objectRef.name"
    HAVING cnt > 10

# 3. 检测RBAC权限变更
* | SELECT "user.username", "requestObject"
    WHERE "objectRef.resource" IN ('clusterrolebindings', 'rolebindings')
      AND "verb" = 'create'

使用ACK配置巡检

ACK集成了配置巡检功能，可以自动检测不符合最佳实践的配置项：

# 在ACK控制台手动触发配置巡检
# 路径：集群详情 → 安全管理 → 配置巡检 → 立即检查

# 也可以通过OpenAPI调用
aliyun cs DescribeClusterCheckResults \
  --ClusterId c-xxx

# 处理高风险项：自动修复脚本示例
# 查找并列出所有privileged模式的Pod
kubectl get pods --all-namespaces -o json | \
  jq -r '.items[] | 
    select(.spec.containers[].securityContext.privileged == true) | 
    "\(.metadata.namespace)/\(.metadata.name)"'

实战：构建一套零信任ACK安全基线的完整步骤

以下是从零开始加固一个ACK集群的完整操作清单：

# === 第一步：命名空间隔离 ===
kubectl create ns production
kubectl create ns staging
kubectl create ns dev

# === 第二步：注册RABC最小权限 ===
# （参考第一节配置）

# === 第三步：启用Pod安全标准 ===
kubectl label ns production pod-security.kubernetes.io/enforce=restricted
kubectl label ns staging pod-security.kubernetes.io/enforce=baseline

# === 第四步：部署默认拒绝NetworkPolicy ===
kubectl apply -f - << 'EOF'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
EOF

# === 第五步：安装Kyverno并部署镜像来源策略 ===
helm repo add kyverno https://kyverno.github.io/kyverno/
helm install kyverno kyverno/kyverno -n kyverno --create-namespace

# === 第六步：安装KMS CSI Driver ===
# 通过ACK应用市场一键部署 csi-secrets-store-provider-alibabacloud

# === 第七步：启用审计日志 ===
# 通过ACK控制台 → 日志中心 → 审计日志 → 开启

# === 第八步：运行配置巡检 ===
# 确认无 HIGH 级别风险项

echo "✅ 零信任安全基线已建立"

在Pod中通过iptables阻断元数据服务访问

spec: initContainers:

• name: block-metadata

image: busybox command: ['sh', '-c', 'iptables -A OUTPUT -d 169.254.169.254 -j DROP'] securityContext: capabilities: add: ["NET_ADMIN"]

更安全的做法是在ACK集群中使用**Terway Exclusive ENI模式**，Pod拥有独立的安全组，可以直接通过安全组规则阻断。

**Q：已运行的Pod如何不中断地更新安全策略？**

A：安全策略的变更**不会自动重启Pod**。NetworkPolicy是动态生效的（立即生效），但Pod安全上下文修改需要重建Pod。建议的流程：
1. 先将新的Pod安全配置部署到Staging环境验证
2. 在生产环境执行滚动更新（Rolling Update）
3. 使用`kubectl rollout status`监控更新进度

## 总结

ACK容器安全不是一套"开箱即用"的功能，而是一套需要逐层构建的纵深防御体系。本文覆盖的六层模型——**RAM RBAC权限最小化 → Pod Security Standards运行时限制 → NetworkPolicy微分段 → 镜像安全扫描与准入控制 → KMS密钥加密 → 审计日志持续监控**——是阿里云国际版ACK生产环境安全加固的基本框架。

关键原则：
- **默认拒绝**：网络、权限、出口流量都从"全部拒绝"开始，逐步放行
- **最小权限**：每个用户、每个ServiceAccount只拥有完成工作所需的最小权限
- **持续审计**：安全不是一次性配置，通过审计日志和配置巡检持续发现问题
- **自动化检查**：将安全策略嵌入CI/CD流水线，防止不合规配置进入生产环境

容器安全没有"银弹"，但遵循本文的最佳实践，你已经在防御攻击者的道路上走在了前90%。

---

> 本文由 [chengzicloud.cloud](https://chengzicloud.cloud) 提供，点击访问首页了解更多阿里云国际版云服务器ECS、ACK容器服务与云原生安全解决方案。