配置 kro 权限 - Amazon EKS
kro 权限的工作原理平台团队权限应用团队权限只读访问权限多命名空间访问权限最佳实践后续步骤
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

帮助改进此页面

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

配置 kro 权限

与 ACK 和 Argo CD 不同，kro 无需额外的 IAM 权限。kro 完全在 Kubernetes 集群中运行，不会发起 Amazon API 调用。可通过标准的 Kubernetes RBAC 机制管控对 kro 资源的访问权限。

kro 权限的工作原理

kro 涉及两种作用域不同的 Kubernetes 资源：

ResourceGraphDefinition：属于集群级资源，用于定义自定义 API。这类资源通常由平台团队负责管理，平台团队会基于组织内的标准规范完成资源的设计与维护工作。

实例：属于命名空间级资源，基于 ResourceGraphDefinition 创建而来。拥有对应 RBAC 权限的应用团队，即可创建这类实例。

默认情况下，kro 功能会通过 AmazonEKSKROPolicy 访问条目策略，获得管理 ResourceGraphDefinition 及其实例的权限。但如果需要让 kro 创建和管理 ResourceGraphDefinition 中定义的底层 Kubernetes 资源（例如 Deployment、Service 或 ACK 资源），则需要为其配置额外权限。您可通过访问条目策略或 Kubernetes RBAC 两种方式授予这些权限。有关授予这些权限的详细信息，请参阅 kro 自定义资源权限。

平台团队权限

平台团队需要具备创建和管理 ResourceGraphDefinition 的权限。

平台团队的 ClusterRole 示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kro-platform-admin
rules:
- apiGroups: ["kro.run"]
  resources: ["resourcegraphdefinitions"]
  verbs: ["*"]

绑定到平台团队成员：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: platform-team-kro-admin
subjects:
- kind: Group
  name: platform-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: kro-platform-admin
  apiGroup: rbac.authorization.k8s.io

应用团队权限

应用团队需要具备在其所属命名空间内创建自定义资源实例的权限。

应用团队的角色示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kro-app-developer
  namespace: my-app
rules:
- apiGroups: ["kro.run"]
  resources: ["webapps", "databases"]
  verbs: ["create", "get", "list", "update", "delete", "patch"]

绑定到应用团队成员：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-team-kro-developer
  namespace: my-app
subjects:
- kind: Group
  name: app-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: kro-app-developer
  apiGroup: rbac.authorization.k8s.io
注意

Role 配置中的 API 组（本例中为 kro.run）必须与 ResourceGraphDefinition 模式文件里定义的 apiVersion 保持一致。

只读访问权限

授予只读访问权限，允许相关人员查看 ResourceGraphDefinition 及实例，且不赋予修改权限。

只读 ClusterRole：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kro-viewer
rules:
- apiGroups: ["kro.run"]
  resources: ["resourcegraphdefinitions"]
  verbs: ["get", "list", "watch"]

实例的只读 Role：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kro-instance-viewer
  namespace: my-app
rules:
- apiGroups: ["kro.run"]
  resources: ["webapps", "databases"]
  verbs: ["get", "list", "watch"]

多命名空间访问权限

借助 ClusterRole 搭配 RoleBinding，为应用团队授予多命名空间的访问权限。

多命名空间访问的 ClusterRole：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kro-multi-namespace-developer
rules:
- apiGroups: ["kro.run"]
  resources: ["webapps"]
  verbs: ["create", "get", "list", "update", "delete"]

绑定到指定命名空间：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-team-dev-access
  namespace: development
subjects:
- kind: Group
  name: app-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: kro-multi-namespace-developer
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-team-staging-access
  namespace: staging
subjects:
- kind: Group
  name: app-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: kro-multi-namespace-developer
  apiGroup: rbac.authorization.k8s.io

最佳实践

最低权限原则：仅为每个团队授予完成其职责所需的最小权限。

优先使用用户组而非独立用户：将角色绑定到用户组而非单个用户，便于权限的统一管理。

分离平台团队与应用团队的职责边界：平台团队负责管理 ResourceGraphDefinition，应用团队负责管理实例。

命名空间隔离机制：利用命名空间实现不同团队或环境的隔离，并通过 RBAC 管控各命名空间的访问权限。

审计场景的只读访问权限：为安全与合规团队配置只读访问权限，满足审计工作的需求。

后续步骤