MK博客

large picture of the cover

AWS EKS 集群身份验证模式的选择

在 AWS EKS 集群中，身份验证模式的选择直接影响集群的安全性、可管理性和扩展性。本文将深入分析两种核心模式：EKS API 身份验证（基于 IAM）和 EKS API + ConfigMap 身份验证（基于 IAM 与 Kubernetes 配置映射），并结合实际场景给出选型建议。

一、EKS API 身份验证模式（基于 IAM）

1. 核心原理

EKS API 身份验证通过 AWS Identity and Access Management (IAM) 实现，依赖以下关键组件：

  • aws-iam-authenticator：运行在 EKS 控制平面的 Webhook 服务，负责验证 IAM 用户 / 角色的请求。

  • Webhook Token 认证：客户端通过 aws eks get-token 生成预签名 URL，API 服务器通过该 URL 调用 AWS STS 验证身份。

2. 配置步骤

  • 创建 IAM 用户 / 角色：在 AWS 控制台或通过 CLI 创建用户 / 角色，并附加必要的权限（如 AmazonEKSClusterAdminPolicy）。

  • 更新 kubeconfig：使用 aws eks update-kubeconfig 生成包含 IAM 凭证的配置文件，确保客户端能通过 AWS CLI 获取临时 Token。

  • 映射权限：通过 aws-auth ConfigMap（默认存在）将 IAM 身份映射到 Kubernetes RBAC 角色。例如，将用户添加到 mapUsers 字段，并关联 system:masters 组以授予管理员权限。

3. 优缺点分析

  • 优点：

    • 与 AWS 生态深度集成：直接复用 IAM 的用户管理、权限策略和审计功能，无需额外维护身份系统。

    • 高安全性：通过 AWS STS 生成临时 Token，避免长期凭证暴露，支持 MFA 和条件访问策略。

    • 动态权限管理：通过 IAM 策略实时调整权限，无需重启集群或修改配置。

  • 缺点：

    • 依赖 AWS 基础设施：若 AWS 服务中断，可能影响集群访问。

    • 配置复杂度：需同时管理 IAM 和 Kubernetes RBAC，对新手不够友好。

二、EKS API + ConfigMap 身份验证模式

1. 核心原理

该模式在 EKS API 基础上，通过 aws-auth ConfigMap 实现更灵活的权限映射：

  • ConfigMap 存储映射规则：将 IAM 用户 / 角色与 Kubernetes 组、角色绑定，例如将特定 IAM 角色映射到 system:bootstrappers 组。

  • RBAC 授权：结合 Kubernetes 原生的 Role-Based Access Control (RBAC)，实现细粒度权限控制。

2. 配置步骤

  • 编辑 aws-auth ConfigMap：

    apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapUsers: |
    - userarn: arn:aws:iam::123456789012:user/eks-user
      username: eks-user
      groups: ["system:masters"]

    此配置将 IAM 用户 eks-user 映射到 Kubernetes system:masters 组，赋予管理员权限。

  • 验证权限：使用 kubectl auth can-i 检查用户权限，例如：

    kubectl auth can-i create pods --as eks-user

3. 优缺点分析

  • 优点：

    • 灵活的权限控制：通过 ConfigMap 自定义映射规则，满足复杂的多租户或跨团队权限需求。

    • 兼容传统 Kubernetes 工具：可与 kubectl、helm 等工具无缝集成，无需额外插件。

  • 缺点：

    • 静态配置管理：权限修改需手动编辑 ConfigMap 并重新应用，缺乏动态性。

    • 维护成本：需同时管理 IAM 和 ConfigMap，容易出错。

三、两种模式的对比与选型建议

维度

EKS API 模式

EKS API + ConfigMap 模式

身份验证

完全依赖 IAM，通过 AWS STS 生成临时 Token

依赖 IAM 验证身份，通过 ConfigMap 映射权限

权限管理

动态（通过 IAM 策略）

静态（通过 ConfigMap 配置）

扩展性

适合大规模集群和多租户环境，支持跨账户权限继承

适合中小型集群或需要细粒度控制的场景，灵活性高但扩展性有限

维护成本

低（集中在 IAM 控制台）

中（需维护 IAM 和 ConfigMap）

安全性

高（AWS 托管，支持 MFA、条件访问）

中（需手动管理 ConfigMap 安全性）

推荐场景：

  • 选择 EKS API 模式：

    • 新集群或需要与 AWS 服务深度集成的场景。

    • 大规模环境，需动态调整权限（如 CI/CD 流水线）。

    • 优先使用 AWS 原生工具（如 CloudFormation、Terraform）进行自动化管理。

  • 选择 EKS API + ConfigMap 模式：

    • 需兼容传统 Kubernetes 工具链（如 Rancher、OpenShift）。

    • 对权限映射有精细控制需求（如按命名空间隔离）。

    • 临时或测试环境，需快速配置权限。

四、最佳实践与注意事项

  1. 最小权限原则：

    • 避免为用户 / 角色赋予 AdministratorAccess 等广泛权限，而是通过 IAM 策略和 Kubernetes RBAC 实现最小权限。

    • 示例：为只读用户创建 IAM 角色并附加 AmazonEKSReadOnlyAccess 策略，同时通过 ConfigMap 映射到 view 角色。

  2. 安全存储敏感信息：

    • 使用 Secrets 而非 ConfigMap 存储证书、Token 等敏感数据。

    • 结合 AWS Secrets Manager 或 Parameter Store 管理密钥，避免硬编码到配置中。

  3. 动态权限管理：

    • 对于生产环境，优先使用 EKS API 模式的 Access Entries 功能（需 EKS 1.23+），通过 AWS API 动态管理权限，替代静态 ConfigMap。

    • 示例：

      aws eks create-access-entry \
  --cluster-name my-eks-cluster \
  --principal-arn arn:aws:iam::123456789012:user/eks-user \
  --access-policy-name AmazonEKSClusterAdminPolicy

  4. 监控与审计：

    • 启用 AWS CloudTrail 记录 IAM 操作，结合 Kubernetes Audit Log 追踪 API 请求。

    • 使用 AWS Config 定期检查权限配置合规性。

五、总结

EKS API 身份验证模式（基于 IAM）是 AWS 推荐的主流方案，尤其适合与 AWS 生态深度集成的场景，其动态权限管理和高安全性是核心优势。而 EKS API + ConfigMap 模式在灵活性和兼容性上表现突出，适合需要细粒度控制或传统工具链的环境。

site logo

Hi,Friend

© 2025 MK博客