kro 권한 구성

kro 리소스에 대한 접근을 표준 Kubernetes RBAC로 제어하는 방법을 설명합니다.

출처: 문서

본문

ACK와 Argo CD와 달리 kro는 IAM 권한이 필요하지 않습니다. kro는 Kubernetes 클러스터 내에서 완전히 작동하며 AWS API 호출을 수행하지 않습니다. 표준 Kubernetes RBAC로 kro 리소스에 대한 접근을 제어합니다.

kro에서 권한이 작동하는 방식

kro는 다른 범위의 두 가지 유형의 Kubernetes 리소스를 사용합니다.

ResourceGraphDefinition - 커스텀 API를 정의하는 클러스터 범위 리소스. 일반적으로 조직 표준을 설계하고 유지 관리하는 플랫폼 팀이 관리합니다.
인스턴스(Instances) - ResourceGraphDefinition에서 만든 네임스페이스 범위 커스텀 리소스. 적절한 RBAC 권한이 있는 애플리케이션 팀이 만들 수 있습니다.

기본적으로 kro 캐퍼빌리티는 AmazonEKSKROPolicy 접근 항목 정책을 통해 ResourceGraphDefinition과 그 인스턴스를 관리할 권한이 있습니다. 그러나 kro는 ResourceGraphDefinition에 정의된 기본 Kubernetes 리소스(Deployments, Services 또는 ACK 리소스 같은)를 만들고 관리하려면 추가 권한이 필요합니다. 접근 항목 정책이나 Kubernetes RBAC를 통해 이러한 권한을 부여해야 합니다. 이러한 권한 부여에 대한 자세한 내용은 eksctl로 kro 캐퍼빌리티 생성, AWS CLI로 kro 캐퍼빌리티 생성 또는 콘솔로 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

애플리케이션 팀 권한

애플리케이션 팀은 자신의 네임스페이스에서 커스텀 리소스의 인스턴스를 만들 권한이 필요합니다.

애플리케이션 팀용 Role 예시:

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"]

멀티 네임스페이스 접근

RoleBinding과 함께 ClusterRole을 사용해 애플리케이션 팀에 여러 네임스페이스 접근을 부여합니다.

멀티 네임스페이스 접근용 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로 각 네임스페이스에 대한 접근을 제어하며 서로 다른 팀이나 환경을 격리하려면 네임스페이스를 사용하세요.
감사용 읽기 전용 접근 - 감사 목적으로 보안 및 규정 준수 팀에 읽기 전용 접근을 제공하세요.

다음 단계

kro 개념 - kro 개념과 리소스 구성 이해하기
EKS 캐퍼빌리티 보안 고려 사항 - 캐퍼빌리티 보안 모범 사례 검토

더 알아보기 (Learn more)

공식 문서