**帮助改进此页面** 

要帮助改进本用户指南，请选择位于每个页面右侧窗格中的**在 GitHub 上编辑此页面**链接。

# EKS 功能的安全注意事项
<a name="capabilities-security"></a>

本主题涵盖了 EKS 功能的重要安全注意事项，包括 IAM 角色配置、Kubernetes 权限、多集群部署的架构模式和跨账户 AWS 资源管理。

EKS 功能使用 IAM 角色、EKS 访问条目和 Kubernetes RBAC 的组合来提供对 AWS 服务、集群内 Kubernetes 资源以及与 AWS CodeConnections、AWS Secrets Manager 和其他 AWS 服务的集成的安全访问。

## 功能 IAM 角色
<a name="_capability_iam_role"></a>

创建功能时，您将提供一个 IAM 功能角色，EKS 使用该角色代表您执行操作。此角色必须满足以下要求：
+ 与集群和功能资源位于同一 AWS 账户中
+ 拥有信任策略，允许 `capabilities.eks.amazonaws.com` 服务主体代入该角色
+ 拥有适合功能类型和使用案例的 IAM 权限，具体取决于您的需求。有关所需 IAM 权限的详细信息，请参阅[使用 AWS CodeConnections 连接到 Git 存储库](integration-codeconnections.md)、[使用 AWS Secrets Manager 管理应用程序密钥](integration-secrets-manager.md)和[配置 ACK 权限](ack-permissions.md) 

最佳做法是考虑您的特定使用案例所需的权限范围，并仅授予满足您的要求所必需的权限。例如，在使用 Kube Resource Orchestrator 的 EKS 功能时，可能不需要 IAM 权限，而在使用 AWS Controllers for Kubernetes 的 EKS 功能时，您可以授予对一项或多项 AWS 服务的完全访问权限。

**重要**  
虽然某些使用案例可能需要使用广泛的管理权限，但要遵循最低权限原则，即仅授予特定使用案例所需的最低 IAM 权限，使用 ARN 和条件键而不是使用通配符权限来限制对特定资源的访问。

有关创建和配置功能 IAM 角色的详细信息，请参阅 [Amazon EKS 功能 IAM 角色](capability-role.md)。

## EKS 访问条目
<a name="_eks_access_entries"></a>

当您使用 IAM 角色创建功能时，Amazon EKS 会在您的集群上自动为该角色创建访问条目。此访问条目授予功能基准 Kubernetes 权限，使其能够运行。

**注意**  
将为创建该功能所在的集群创建访问条目。要将 Argo CD 部署到远程集群，您必须在这些集群上创建访问条目，使其具有部署和管理应用程序的 Argo CD 功能的相应权限。

访问条目包括：
+ 作为主体的 IAM 角色 ARN
+ 授予基准 Kubernetes 权限的功能特定访问条目策略
+ 基于功能类型的适当范围（集群范围或命名空间范围）

**注意**  
对于 Argo CD，将向功能配置中指定的命名空间授予命名空间范围的权限（默认为 `argocd`）。

 **按功能划分的默认访问条目策略** 

每种功能类型都向功能角色授予所需的权限，设置如下所示的不同默认访问条目策略：

 **kro**   
+  `arn:aws:eks::aws:cluster-access-policy/AmazonEKSKROPolicy`（集群范围）

  授予监视和管理 ResourceGraphDefinitions 以及创建由 RGD 定义的自定义资源实例的权限。

 **ACK**   
+  `arn:aws:eks::aws:cluster-access-policy/AmazonEKSACKPolicy`（集群范围）

  授予在所有命名空间中创建、读取、更新和删除 ACK 自定义资源的权限。

 **Argo CD**   
+  `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy`（集群范围）

  授予 Argo CD 的集群级别权限，以便发现资源，并管理集群范围内的对象。
+  `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy`（命名空间范围）

  授予 Argo CD 部署和管理应用程序的命名空间级权限。范围限定为功能配置中指定的命名空间（默认为 `argocd`）。

有关更多详细信息，请参阅[检查访问策略权限](access-policy-permissions.md)。

## 其他 Kubernetes 权限
<a name="additional-kubernetes-permissions"></a>

某些功能可能需要除默认访问条目策略之外的其他 Kubernetes 权限。您可以使用以下任一方法授予这些权限：
+  **访问条目策略**：将其他托管策略与访问条目相关联
+  **Kubernetes RBAC**：为该功能的 Kubernetes 用户创建 `Role` 或 `ClusterRole` 绑定

 **ACK 密钥读取器权限** 

某些 ACK 控制器需要读取 Kubernetes 密钥才能检索数据库密码等敏感数据。以下 ACK 控制器需要密钥读取权限：
+  `acm`, `acmpca`, `documentdb`, `memorydb`, `mq`, `rds`, `secretsmanager` 

要授予密钥读取权限，请执行以下操作：

1. 将 `arn:aws:eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy` 访问条目策略与功能的访问条目相关联

1. 将策略范围限定到特定的命名空间，ACK 资源将在其中引用密钥，或者授予整个集群的访问权限

**重要**  
密钥读取权限的范围限定为您在关联访问条目策略时指定的命名空间。这允许您限制该功能可以访问的密钥。

<a name="kro-resource-permissions"></a> **kro 任意资源权限** 

kro 需要权限才能创建和管理 ResourceGraphDefinitions 中定义的资源。默认情况下，kro 只能自行监视和管理 RGD。

要授予 kro 创建资源的权限，请执行以下操作：

 **选项 1：访问条目策略** 

将预定义的访问条目策略（如 `AmazonEKSAdminPolicy` 或 `AmazonEKSEditPolicy`）与功能的访问条目相关联。

 **选项 2：Kubernetes RBAC** 

创建一个向该功能的 Kubernetes 用户授予必要权限的 `ClusterRoleBinding`：

```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kro-cluster-admin
subjects:
- kind: User
  name: arn:aws:sts::111122223333:assumed-role/my-kro-role/KRO
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
```

**注意**  
kro 的 Kubernetes 用户名遵循以下模式：`arn:aws:sts::ACCOUNT_ID:assumed-role/ROLE_NAME/KRO`  
会话名称 `/KRO`（大写字母）由 EKS kro 功能自动设置。

## 功能所需的 IAM 权限
<a name="_iam_permissions_required_by_capability"></a>

 **kro（Kube Resource Orchestrator）**   
不需要 IAM 权限。您可以创建没有附加策略的功能角色。kro 只需要 Kubernetes RBAC 权限。

 **ACK（AWS Controllers for Kubernetes）**   
需要权限才能管理 ACK 将创建和管理的 AWS 资源。您应根据自己的要求将权限范围限定为特定服务、操作和资源。有关配置 ACK 权限的详细信息，包括使用 IAM 角色选择器的生产最佳实践，请参阅[配置 ACK 权限](ack-permissions.md)。

 **Argo CD**   
默认情况下，不需要 IAM 权限。以下功能可能需要可选权限：  
+  AWS Secrets Manager：如果在 Secrets Manager 中存储 Git 存储库凭证
+  AWS CodeConnections：如果使用 CodeConnections 进行 Git 存储库身份验证
+ Amazon ECR：如果使用在 Amazon ECR 中以 OCI 格式存储的 Helm 图表

## 安全最佳实践
<a name="_security_best_practices"></a>

### IAM 最低权限
<a name="_iam_least_privilege"></a>

仅授予您的功能资源您的使用案例所需的权限。这并不意味着在需要时您无法向自己的功能授予广泛的管理权限。在这种情况下，您应适当地管理对这些资源的访问权限。

 **功能角色**：
+  **ACK**：在可能的情况下，根据使用案例和要求，将 IAM 权限限制为仅能访问团队所需的特定 AWS 服务和资源
+  **Argo CD**：限制对特定的 Git 存储库和 Kubernetes 命名空间的访问权限
+  **kro**：需要信任策略的功能角色，但不需要 IAM 权限（仅使用集群 RBAC）

 **示例**：为特定资源或资源组指定模式，而非 `"Resource": "*"`。

```
"Resource": [
  "arn:aws:s3:::my-app-*",
  "arn:aws:rds:us-west-2:111122223333:db:prod-*"
]
```

使用 IAM 条件键进一步限制访问权限：

```
"Condition": {
  "StringEquals": {
    "aws:ResourceTag/Environment": "production"
  }
}
```

有关其他 IAM 配置信息，请参阅每项功能的注意事项部分。

### Argo CD 密钥的命名空间隔离
<a name="_namespace_isolation_for_argo_cd_secrets"></a>

托管 Argo CD 功能可以访问其配置的命名空间中的所有 Kubernetes 密钥（默认：`argocd`）。要保持最佳安全状况，请遵循以下命名空间隔离实践：
+ 在 Argo CD 命名空间中只保留 Argo CD 相关的密钥
+ 避免将不相关的应用程序密钥存储在与 Argo CD 相同的命名空间中
+ 使用单独的命名空间来存放 Argo CD 操作不需要的应用程序密钥

这种隔离可确保 Argo CD 的密钥访问权限仅限于 Git 存储库身份验证和其他 Argo CD 特定操作所需的凭证。

### Kubernetes RBAC
<a name="_kubernetes_rbac"></a>

控制哪些用户和服务账户可以创建和管理功能资源。使用适当的 RBAC 策略在专用命名空间中部署功能资源是最佳实践。

示例：与 ACK 配合使用 RBAC 角色，允许在 `app-team` 命名空间中管理 S3 存储桶资源：

```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ack-s3-manager
  namespace: app-team
rules:
- apiGroups: ["s3.services.k8s.aws"]
  resources: ["buckets"]
  verbs: ["get", "list", "create", "update", "delete"]
```

### 审计日志记录
<a name="_audit_logging"></a>

 **CloudTrail**：所有 EKS 功能 API 操作（创建、更新、删除）都将记录到 AWS CloudTrail 中。

启用 CloudTrail 日志记录来跟踪：
+ 哪些用户创建或修改了功能
+ 功能配置发生更改时
+ 哪些功能角色在使用中

### 网络访问和 VPC 端点
<a name="_network_access_and_vpc_endpoints"></a>

#### 私有 Argo CD API 访问权限
<a name="_private_argo_cd_api_access"></a>

您可以通过将一个或多个 VPC 端点与托管的 Argo CD 端点关联，来限制对 Argo CD API 服务器的访问。这样就可以在您的 VPC 内进行私有连接，而无需通过公共互联网。VPC 端点提供对 Argo CD Web UI 和 Argo CD API 的访问（包括 CLI 访问）。

**注意**  
连接到托管的 Argo CD API 端点的 VPC 端点（使用 eks-capabilities.*region*.amazonaws.com）不支持 VPC 端点策略。

#### 部署到私有集群
<a name="_deploying_to_private_clusters"></a>

Argo CD 功能可以将应用程序部署到完全私有的 EKS 集群，无需进行 VPC 对等互连或复杂的网络配置，从而提供显著的运营优势。但是，在设计此架构时，请考虑 Argo CD 将从 Git 存储库（可能是公有存储库）中拉取配置并将其应用于您的私有集群。

请确保：
+ 使用私有 Git 存储库处理敏感工作负载
+ 实施适当的 Git 仓库访问控制和身份验证
+ 先通过拉取请求查看和批准更改，再进行合并
+ 考虑使用 Argo CD 的同步窗口来控制部署的时间
+ 监控 Argo CD 审计日志中是否有未经授权的配置更改

### 合规
<a name="_compliance"></a>

EKS 功能是完全托管的，并已获得 Amazon EKS 的合规性认证。

有关更多信息，请参阅[按合规性计划划分的范围内的 AWS 服务](https://aws.amazon.com/compliance/services-in-scope/)。

## 后续步骤
<a name="_next_steps"></a>
+  [配置 ACK 权限](ack-permissions.md)：为 ACK 配置 IAM 权限
+  [配置 kro 权限](kro-permissions.md)：为 kro 配置 Kubernetes RBAC
+  [配置 Argo CD 权限](argocd-permissions.md)：为 Argo CD 配置 Identity Center 集成
+  [EKS 功能问题排查](capabilities-troubleshooting.md)：对安全和权限问题进行问题排查