Argo CD 권한 구성

Argo CD 관리형 캐퍼빌리티가 AWS Identity Center와 통합되어 인증하고, 기본 제공 RBAC 역할로 권한을 부여하는 방식과 사용자 및 팀 권한 구성 방법을 설명합니다.

출처: 문서

본문

Argo CD 권한 작동 방식

Argo CD 캐퍼빌리티는 인증에 AWS Identity Center를 사용하고 권한 부여에 세 가지 기본 제공 RBAC 역할을 제공합니다.

사용자가 Argo CD에 접근하면:

AWS Identity Center로 인증합니다(기업 ID 프로바이더로 페더레이션할 수 있음).
AWS Identity Center가 사용자 및 그룹 정보를 Argo CD에 제공합니다.
Argo CD가 구성에 따라 사용자와 그룹을 RBAC 역할에 매핑합니다.
사용자에게 접근 권한이 있는 애플리케이션과 리소스만 표시됩니다.

기본 제공 RBAC 역할

Argo CD 캐퍼빌리티는 AWS Identity Center 사용자와 그룹에 매핑하는 세 가지 기본 제공 역할을 제공합니다. 이들은 프로젝트, 클러스터, 리포지토리 같은 Argo CD 리소스에 대한 접근을 제어하는 전역 범위 역할입니다.

중요

전역 역할은 Argo CD 자체에 대한 접근을 제어하며, Application 같은 프로젝트 범위 리소스에는 적용되지 않습니다. EDITOR와 VIEWER 사용자는 기본적으로 Application을 볼 수도 관리할 수도 없습니다. 프로젝트 범위 리소스에 접근하려면 프로젝트 역할이 필요합니다. Application과 기타 프로젝트 범위 리소스에 대한 접근 부여는 프로젝트 역할과 프로젝트 범위 접근을 참고하세요.

ADMIN

모든 Argo CD 리소스와 설정에 대한 전체 접근:

모든 프로젝트에서 Application과 ApplicationSet 생성, 업데이트, 삭제
Argo CD 구성 관리
배포 대상 클러스터 등록 및 관리
리포지토리 접근 구성
프로젝트 생성 및 관리
모든 애플리케이션 상태와 이력 보기
모든 클러스터와 리포지토리 나열 및 접근

EDITOR

프로젝트를 업데이트하고 프로젝트 역할을 구성할 수 있지만, 전역 Argo CD 설정은 변경할 수 없습니다.

기존 프로젝트 업데이트(프로젝트 생성이나 삭제는 불가)
프로젝트 역할과 권한 구성
GPG 키와 인증서 보기
전역 Argo CD 구성 변경 불가
클러스터나 리포지토리를 직접 관리할 수 없음
프로젝트 역할 없이는 Application을 보거나 관리할 수 없음

VIEWER

Argo CD 리소스에 대한 읽기 전용 접근:

프로젝트 구성 보기
모든 프로젝트 나열(할당되지 않은 프로젝트 포함)
GPG 키와 인증서 보기
클러스터나 리포지토리 나열 불가
어떤 변경도 할 수 없음
프로젝트 역할 없이는 Application을 보거나 관리할 수 없음

참고

EDITOR나 VIEWER 사용자에게 Application 접근을 부여하려면 ADMIN 또는 EDITOR가 Identity Center 그룹을 프로젝트 내 특정 권한에 매핑하는 프로젝트 역할을 만들어야 합니다.

프로젝트 역할과 프로젝트 범위 접근

전역 역할(ADMIN, EDITOR, VIEWER)은 Argo CD 자체에 대한 접근을 제어합니다. 프로젝트 역할은 특정 프로젝트 내의 리소스와 기능에 대한 접근을 제어하며, 여기에는 다음이 포함됩니다.

리소스 - Application, ApplicationSet, 리포지토리 자격 증명, 클러스터 자격 증명
기능 - 로그 접근, 애플리케이션 파드에 대한 exec 접근

2단계 권한 모델 이해하기:

전역 범위 - 기본 제공 역할이 사용자가 프로젝트, 클러스터, 리포지토리, Argo CD 설정으로 무엇을 할 수 있는지 결정
프로젝트 범위 - 프로젝트 역할이 사용자가 특정 프로젝트 내의 리소스와 기능으로 무엇을 할 수 있는지 결정

즉:

ADMIN 사용자는 추가 구성 없이 모든 프로젝트 리소스와 기능에 접근할 수 있습니다.
EDITOR와 VIEWER 사용자는 프로젝트 리소스와 기능에 접근하려면 프로젝트 역할이 부여되어야 합니다.
EDITOR 사용자는 업데이트할 수 있는 프로젝트 내에서 자신과 다른 사람에게 접근을 부여하는 프로젝트 역할을 만들 수 있습니다.

예시 워크플로:

ADMIN이 Identity Center 그룹을 전역 EDITOR 역할에 매핑합니다.
ADMIN이 팀을 위한 프로젝트를 만듭니다.
EDITOR가 해당 프로젝트 내에서 팀 구성원에게 프로젝트 범위 리소스 접근을 부여하는 프로젝트 역할을 구성합니다.
팀 구성원(VIEWER 전역 역할일 수 있음)은 이제 프로젝트 역할 권한에 따라 해당 프로젝트의 Application을 보고 관리할 수 있습니다.

프로젝트 역할 구성에 대한 자세한 내용은 프로젝트 기반 접근 제어를 참고하세요.

역할 매핑 구성

캐퍼빌리티를 생성하거나 업데이트할 때 AWS Identity Center 사용자와 그룹을 Argo CD 역할에 매핑합니다.

역할 매핑 예시:

{
  "rbacRoleMappings": {
    "ADMIN": ["AdminGroup", "[email protected]"],
    "EDITOR": ["DeveloperGroup", "DevOpsTeam"],
    "VIEWER": ["ReadOnlyGroup", "[email protected]"]
  }
}

참고

역할 이름은 대소문자를 구분하며 대문자여야 합니다(ADMIN, EDITOR, VIEWER).

중요

EKS 캐퍼빌리티의 AWS Identity Center 통합은 Argo CD 캐퍼빌리티당 최대 1,000개의 ID를 지원합니다. ID는 사용자 또는 그룹일 수 있습니다.

역할 매핑 업데이트:

aws eks update-capability \
  --region us-east-1 \
  --cluster-name cluster \
  --capability-name capname \
  --role-arn "arn:aws:iam::111122223333:role/EKSCapabilityRole" \
  --configuration '{
    "argoCd": {
      "rbacRoleMappings": {
        "addOrUpdateRoleMappings": [
          {
            "role": "ADMIN",
            "identities": [
              { "id": "686103e0-f051-7068-b225-e6392b959d9e", "type": "SSO_USER" }
            ]
          }
        ]
      }
    }
  }'

관리자 계정 사용

관리자 계정은 초기 설정과 클러스터 등록, 리포지토리 구성 같은 관리 작업용으로 설계되었습니다.

관리자 계정이 적절한 경우:

초기 캐퍼빌리티 설정과 구성
단독 개발 또는 빠른 데모
관리 작업(클러스터 등록, 리포지토리 구성, 프로젝트 생성)

관리자 계정 모범 사례:

계정 토큰을 버전 관리에 커밋하지 않기
토큰이 노출되면 즉시 교체
계정 토큰 사용을 설정 및 관리 작업으로 제한
짧은 만료 시간 설정(최대 12시간)
한 번에 5개의 계정 토큰만 생성 가능

프로젝트 기반 접근을 대신 사용할 때:

여러 사용자가 있는 공유 개발 환경
프로덕션과 유사한 모든 환경
누가 작업을 수행했는지 감사 추적이 필요할 때
리소스 제한이나 접근 경계를 강제해야 할 때

프로덕션 환경과 다중 사용자 시나리오에서는 AWS Identity Center 그룹에 매핑된 전용 RBAC 역할과 함께 프로젝트 기반 접근 제어를 사용하세요.

프로젝트 기반 접근 제어

Argo CD 프로젝트(AppProject)를 사용해 팀에 세분화된 접근 제어와 리소스 격리를 제공합니다.

중요

사용자나 그룹을 프로젝트별 역할에 할당하기 전에 먼저 캐퍼빌리티 구성에서 전역 Argo CD 역할(ADMIN, EDITOR, VIEWER)에 매핑해야 합니다. 프로젝트 역할에 할당되어 있어도 전역 역할 매핑이 없으면 사용자는 Argo CD에 접근할 수 없습니다.

사용자를 전역적으로 VIEWER 역할에 매핑한 다음 프로젝트별 역할로 추가 권한을 부여하는 것을 고려하세요. 이렇게 하면 기본 접근을 제공하면서 프로젝트 수준에서 세밀한 제어가 가능합니다.

프로젝트가 제공하는 것:

소스 제한 - 사용할 수 있는 Git 리포지토리 제한
대상 제한 - 대상으로 지정할 수 있는 클러스터와 네임스페이스 제한
리소스 제한 - 배포할 수 있는 Kubernetes 리소스 유형 제한
RBAC 통합 - 프로젝트를 AWS Identity Center 그룹 또는 Argo CD 역할에 매핑

팀 격리를 위한 프로젝트 예시:

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-a
  namespace: argocd
spec:
  description: Team A applications

  # Required: Specify which namespaces this project watches for Applications
  sourceNamespaces:
  - argocd

  # Source restrictions
  sourceRepos:
  - https://github.com/myorg/team-a-apps

  # Destination restrictions
  destinations:
  - namespace: team-a-*
    server: arn:aws:eks:us-west-2:111122223333:cluster/production

  # Resource restrictions
  clusterResourceWhitelist:
  - group: ''
    kind: Namespace
  namespaceResourceWhitelist:
  - group: 'apps'
    kind: Deployment
  - group: ''
    kind: Service
  - group: ''
    kind: ConfigMap

소스 네임스페이스

EKS Argo CD 캐퍼빌리티를 사용할 때 AppProject 정의에서 spec.sourceNamespaces 필드가 필요합니다. 이 필드는 이 프로젝트를 참조하는 Application이나 ApplicationSet을 포함할 수 있는 네임스페이스를 지정합니다.

중요

EKS Argo CD 캐퍼빌리티는 Application과 ApplicationSet에 대해 단일 네임스페이스만 지원합니다. 즉, 캐퍼빌리티를 만들 때 지정한 네임스페이스(보통 argocd)입니다. 이는 여러 네임스페이스를 지원하는 오픈 소스 Argo CD와 다릅니다.

AppProject 구성

모든 AppProject는 sourceNamespaces에 캐퍼빌리티의 구성된 네임스페이스를 포함해야 합니다.

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-a-project
  namespace: argocd
spec:
  description: Applications for Team A

  # Required: Specify the capability's configured namespace (configuration.argoCd.namespace)
  sourceNamespaces:
    - argocd  # Must match your capability's namespace configuration

  # Source repositories this project can deploy from
  sourceRepos:
    - 'https://github.com/my-org/team-a-*'

  # Destination restrictions
  destinations:
    - namespace: 'team-a-*'
      server: arn:aws:eks:us-west-2:111122223333:cluster/my-cluster

참고

sourceNamespaces에서 캐퍼빌리티의 네임스페이스를 생략하면 해당 네임스페이스의 Application이나 ApplicationSet이 이 프로젝트를 참조할 수 없어 배포가 실패합니다.

사용자를 프로젝트에 할당:

프로젝트 역할은 EDITOR와 VIEWER 사용자에게 프로젝트 리소스(Application, ApplicationSet, 리포지토리 및 클러스터 자격 증명)와 기능(로그, exec)에 대한 접근을 부여합니다. 프로젝트 역할이 없으면 이들 사용자는 전역 역할 접근이 있어도 이러한 리소스에 접근할 수 없습니다. ADMIN 사용자는 프로젝트 역할 없이 모든 Application에 접근할 수 있습니다.

예시: 팀 구성원에게 Application 접근 부여

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-a
  namespace: argocd
spec:
  # ... project configuration ...

  sourceNamespaces:
  - argocd

  # Project roles grant Application-level access
  roles:
  - name: developer
    description: Team A developers - can manage Applications
    policies:
    - p, proj:team-a:developer, applications, *, team-a/*, allow
    - p, proj:team-a:developer, clusters, get, *, allow  # See cluster names in UI
    groups:
    - 686103e0-f051-7068-b225-e6392b959d9e  # Identity Center group ID

  - name: viewer
    description: Team A viewers - read-only Application access
    policies:
    - p, proj:team-a:viewer, applications, get, team-a/*, allow
    - p, proj:team-a:viewer, clusters, get, *, allow  # See cluster names in UI
    groups:
    - 786203e0-f051-7068-b225-e6392b959d9f  # Identity Center group ID

참고

사용자가 UI에서 클러스터 이름을 볼 수 있도록 프로젝트 역할에 clusters, get, *, allow를 포함하세요. 이 권한이 없으면 대상 클러스터가 "unknown"으로 표시됩니다.

프로젝트 역할 정책 이해하기:

정책 형식은 p, proj:<프로젝트>:<역할>, <리소스>, <액션>, <범위>, <효과>입니다.

리소스 정책:

applications, *, team-a/*, allow - team-a 프로젝트의 모든 Application에 대한 전체 접근
applications, get, team-a/*, allow - Application에 대한 읽기 전용 접근
applications, sync, team-a/*, allow - Application 동기화는 가능하지만 생성/삭제는 불가
applications, delete, team-a/*, allow - Application 삭제 가능(주의해서 사용)
applicationsets, *, team-a/*, allow - ApplicationSet에 대한 전체 접근
repositories, *, *, allow - 리포지토리 자격 증명에 대한 접근
clusters, *, *, allow - 클러스터 자격 증명에 대한 접근

기능 정책:

logs, *, team-a/*, allow - 애플리케이션 로그에 대한 접근
exec, *, team-a/*, allow - 애플리케이션 파드에 대한 exec 접근

참고

EDITOR 사용자는 업데이트할 수 있는 프로젝트 내에서 자신과 다른 사람에게 권한을 부여하는 프로젝트 역할을 만들 수 있습니다. 이렇게 하면 팀 리더가 ADMIN 개입 없이 팀의 프로젝트 범위 리소스 접근을 제어할 수 있습니다.

참고

groups 필드에 Identity Center 그룹 이름이 아니라 그룹 ID를 사용하세요. 개별 사용자 접근에는 Identity Center 사용자 ID도 사용할 수 있습니다. 이 ID는 AWS Identity Center 콘솔이나 AWS CLI에서 찾을 수 있습니다.

일반적인 권한 패턴

패턴 1: 전체 접근 권한이 있는 관리 팀

{
  "rbacRoleMappings": {
    "ADMIN": ["PlatformTeam", "SRETeam"]
  }
}

ADMIN 사용자는 추가 구성 없이 모든 프로젝트 범위 리소스를 보고 관리할 수 있습니다.

패턴 2: 팀 리더는 프로젝트 관리, 개발자는 프로젝트 역할로 접근

{
  "rbacRoleMappings": {
    "ADMIN": ["PlatformTeam"],
    "EDITOR": ["TeamLeads"],
    "VIEWER": ["AllDevelopers"]
  }
}

ADMIN이 각 팀의 프로젝트를 생성합니다.
팀 리더(EDITOR)가 프로젝트 역할을 구성해 개발자에게 프로젝트 리소스(Application, ApplicationSet, 자격 증명)와 기능(로그, exec) 접근을 부여합니다.
개발자(VIEWER)는 프로젝트 역할이 허용하는 리소스와 기능에만 접근할 수 있습니다.

패턴 3: 프로젝트 역할을 사용한 팀 기반 접근

ADMIN이 프로젝트를 만들고 팀 리더를 전역 EDITOR 역할에 매핑합니다.
팀 리더(EDITOR)가 자신의 프로젝트 내에서 팀 구성원을 프로젝트 역할에 할당합니다.
팀 구성원은 VIEWER 전역 역할만 있으면 됩니다. 프로젝트 역할이 프로젝트 리소스와 기능에 대한 접근을 제공합니다.

{
  "rbacRoleMappings": {
    "ADMIN": ["PlatformTeam"],
    "EDITOR": ["TeamLeads"],
    "VIEWER": ["AllDevelopers"]
  }
}

모범 사례

개별 사용자 대신 그룹 사용 - 더 쉬운 관리를 위해 개별 사용자보다 AWS Identity Center 그룹을 Argo CD 역할에 매핑하세요.
최소 권한으로 시작 - VIEWER 접근으로 시작하고 필요에 따라 EDITOR나 ADMIN을 부여하세요.
팀 격리에 프로젝트 사용 - 서로 다른 팀이나 환경에 별도의 AppProject를 만들어 경계를 강제하세요.
Identity Center 페더레이션 활용 - 중앙 집중식 사용자 관리를 위해 AWS Identity Center가 기업 ID 프로바이더와 페더레이션하도록 구성하세요.
정기적인 접근 검토 - 적절한 접근 수준을 보장하기 위해 역할 매핑과 프로젝트 할당을 주기적으로 검토하세요.
클러스터 접근 제한 - Argo CD RBAC는 Argo CD 리소스와 작업에 대한 접근을 제어하지만 Kubernetes RBAC와 대응하지는 않습니다. Argo CD 접근이 있는 사용자는 Argo CD가 접근할 수 있는 클러스터에 애플리케이션을 배포할 수 있습니다. Argo CD가 접근할 수 있는 클러스터를 제한하고, 프로젝트 대상 제한을 사용해 애플리케이션을 배포할 수 있는 위치를 제어하세요.

AWS 서비스 권한

Application 리소스에서 AWS 서비스를 직접 사용하려면(Repository 리소스를 만들지 않고) 캐퍼빌리티 역할에 필요한 IAM 권한을 연결하세요.

Helm 차트용 ECR:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecr:GetAuthorizationToken",
        "ecr:BatchCheckLayerAvailability",
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage"
      ],
      "Resource": "*"
    }
  ]
}

CodeCommit 리포지토리:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "codecommit:GitPull"
      ],
      "Resource": "arn:aws:codecommit:region:account-id:repository-name"
    }
  ]
}

CodeConnections(GitHub, GitLab, Bitbucket):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "codeconnections:UseConnection"
      ],
      "Resource": "arn:aws:codeconnections:region:account-id:connection/connection-id"
    }
  ]
}

이러한 통합 사용에 대한 자세한 내용은 리포지토리 접근 구성을 참고하세요.

다음 단계

Argo CD 사용하기 - 애플리케이션 생성과 배포 관리 방법 알아보기
Argo CD 개념 - Projects를 포함한 Argo CD 개념 이해하기
EKS 캐퍼빌리티 보안 고려 사항 - 캐퍼빌리티 보안 모범 사례 검토

더 알아보기 (Learn more)

공식 문서