[argocd] argocd-rbac-cm ConfigMap

ArgoCD 공식 문서를 참고하였습니다. (https://argo-cd.readthedocs.io/en/stable/)

RBAC Configuration

RBAC 기능은 Argo CD 리소스에 대한 접근 제한을 가능하게 합니다. Argo CD는 자체 사용자 관리 시스템이 없으며, 내장된 단일 사용자 admin만 존재합니다. admin 사용자는 슈퍼유저로 시스템에 무제한 접근 권한을 가집니다. RBAC를 사용하려면 SSO 구성 또는 하나 이상의 로컬 사용자 설정이 필요합니다. SSO나 로컬 사용자가 설정되면, 추가 RBAC 역할을 정의할 수 있고, SSO 그룹 또는 로컬 사용자를 역할에 매핑할 수 있습니다. RBAC 구성을 정의할 수 있는 주요 컴포넌트는 두 가지입니다.

• 글로벌 RBAC ConfigMap (argo-rbac-cm.yaml 참조)
  • https://argo-cd.readthedocs.io/en/stable/operator-manual/argocd-rbac-cm-yaml/
• AppProject의 역할

기본 내장 역할

Argo CD는 두 가지 미리 정의된 역할이 있으며, RBAC 구성을 통해 추가 역할과 그룹을 정의할 수 있습니다.

• role:readonly: 모든 리소스에 대해 읽기 전용 접근 권한
• role:admin: 모든 리소스에 무제한 접근 권한

이 기본 내장 역할 정의는 builtin-policy.csv에서 확인할 수 있습니다.

인증된 사용자에 대한 기본 정책

사용자가 Argo CD에 인증되면, policy.default에 지정된 역할이 부여됩니다.

기본 권한 제한
모든 인증된 사용자는 최소한 기본 정책이 부여하는 권한을 받으며, 이 권한은 deny 규칙으로 차단할 수 없습니다. 가능한 최소 권한을 가진 role:authenticated 역할을 새로 만들고, 필요한 개별 역할에 권한을 부여하는 것이 권장됩니다.

익명 접근

Argo CD 인스턴스에 익명 접근을 허용하면, 사용자는 인증 없이 policy.default에 명시된 기본 역할 권한을 가집니다. 익명 접근은 argocd-cm의 users.anonymous.enabled 필드에서 활성화할 수 있습니다 (argocd-cm.yaml 참고).

• https://argo-cd.readthedocs.io/en/stable/operator-manual/argocd-cm-yaml/

주의
익명 접근을 활성화할 때는 새 기본 역할을 만들고 policy.default에 role:unauthenticated를 할당하는 것을 고려해야 합니다.

RBAC 모델 구조

모델 구문은 Casbin(오픈소스 ACL)을 기반으로 하며, 정책 할당과 사용자-내부 역할 할당에 대한 두 가지 구문이 있습니다.

• Group: 인증된 사용자나 그룹을 내부 역할에 할당
• 구문: g, <user/group>, <role>
  • <user/group>: 역할이 할당될 대상, 로컬 사용자 또는 SSO 인증 사용자 (SSO 사용 시, 사용자는 sub 클레임 기준이며 그룹은 scopes 설정에 의해 반환되는 값 중 하나)
  • <role>: 할당될 내부 역할
• Policy: 권한을 엔티티에 할당
• 구문: p, <role/user/group>, <resource>, <action>, <object>, <effect>
  • <role/user/group>: 정책이 할당될 대상
  • <resource>: 동작이 수행되는 리소스 유형
  • <action>: 리소스에 대해 수행되는 작업
  • <object>: 작업이 수행되는 리소스 식별자 (리소스에 따라 형식이 다름)
  • <effect>: 대상 작업에 권한을 허용할지 제한할지 여부 (allow 또는 deny)

아래 표는 가능한 모든 리소스 종류와 각각 허용되는 작업(action)을 정리한 것입니다.

Application-Specific Policy

일부 정책은 애플리케이션 내에서만 의미를 가집니다. 해당 리소스는 다음과 같습니다.

• applications
• applicationsets
• logs
• exec

이들은 글로벌 설정에 적용할 수도 있지만, AppProject의 역할 내에서도 설정할 수 있습니다. 정책 구조에서 예상되는 <object> 값은 <app-project>/<app-name>으로 대체됩니다. 예를 들어, 다음 정책은 example-user에게 모든 applications에 대한 get 권한을 부여하지만, example-project 프로젝트의 my-app 애플리케이션 로그만 조회할 수 있게 합니다.

p, example-user, applications, get, *, allow 
p, example-user, logs, get, example-project/my-app, allow

여러 네임스페이스 어디서든 생성될 수 있는 애플리케이션

 

네임스페이스에 상관없이 애플리케이션이 허용된 경우, 정책 구조의 <object> 값은 <app-project>/<app-ns>/<app-name>으로 대체됩니다. 동일한 프로젝트 내에 같은 이름의 애플리케이션이 있을 수 있으므로, 아래 정책은 app-namespace로 접근을 제한합니다.

p, example-user, applications, get, */app-namespace/*, allow
p, example-user, logs, get, example-project/app-namespace/my-app, allow

applications 리소스

applications 리소스는 Application-Specific Policy에 해당합니다.

업데이트/삭제 작업에 대한 세밀한 권한

애플리케이션에 대해 update나 delete 권한이 있으면 애플리케이션 자체에 작업할 수 있으나, 그 하위 리소스에는 작업 권한이 자동으로 부여되지 않습니다. 하위 리소스에 작업할 경우 <action>은 <action>/<group>/<kind>/<ns>/<name> 형식을 가집니다. 예를 들어, example-user가 prod-app 애플리케이션 내 Pod만 삭제할 수 있도록 허용하려면 다음과 같이 설정합니다.

p, example-user, applications, delete/*/Pod/*/*, default/prod-app, allow

모든 애플리케이션 리소스 업데이트 권한을 주지만, 애플리케이션 자체는 제외하려면

p, example-user, applications, update/*, default/prod-app, allow

애플리케이션 삭제 권한은 거부하고, Pod 삭제만 허용하려면

p, example-user, applications, delete, default/prod-app, deny
p, example-user, applications, delete/*/Pod/*/*, default/prod-app, allow

애플리케이션 업데이트만 허용하고 하위 리소스 업데이트는 거부하려면

p, example-user, applications, update, default/prod-app, allow
p, example-user, applications, update/*, default/prod-app, deny

action 액션

action 액션은 Argo CD 저장소 내 빌트인 리소스 커스터마이징이나 사용자가 정의한 커스텀 리소스 액션입니다. 형식은 action/<group>/<kind>/<action-name>입니다. 예를 들어 resource_customizations/extensions/DaemonSet/actions/restart/action.lua는 action/extensions/DaemonSet/restart로 매핑됩니다. 그룹이 없는 리소스(예: Pods, ConfigMaps)는 action//Pod/action-name 형식입니다. 다음 정책은 DaemonSet 리소스에 모든 액션과 Pod에 maintenance-off 액션을 허용합니다.

p, example-user, applications, action//Pod/maintenance-off, default/*, allow
p, example-user, applications, action/extensions/DaemonSet/*, default/*, allow

모든 액션을 허용하려면

p, example-user, applications, action/*, default/*, allow

override 액션

sync 액션과 함께 부여되면, override 액션은 사용자가 Application에 로컬 매니페스트를 동기화하도록 허용합니다. 이는 다음 동기화 전까지 구성된 소스 대신 사용됩니다.

applicationsets 리소스

applicationsets 리소스는 Application-Specific Policy입니다. ApplicationSets는 선언적으로 Application을 자동 생성/업데이트/삭제하는 수단입니다. create 권한을 주면 Application 생성 권한을 주는 것이지만, 직접 생성은 아니며 ApplicationSet을 통해 생성 가능합니다. 이로 인해 RBAC에 의한 프로젝트 제한이 안전합니다. applicationsets 정책의 <object>는 <app-project>/<app-name> 형식을 가지지만, ApplicationSet은 프로젝트에 속하지 않으므로 <app-project>는 ApplicationSet이 Application을 생성할 수 있는 프로젝트를 의미합니다. 예를 들어 dev-group 사용자가 dev-project 외부에서 Application을 생성할 수 없게 하려면

p, dev-group, applicationsets, *, dev-project/*, allow

logs 리소스

logs 리소스는 Application-Specific Policy입니다. get 권한이 있으면 Argo CD UI를 통해 애플리케이션 Pod 로그를 볼 수 있습니다.
kubectl logs와 유사한 기능입니다.

exec 리소스

exec 리소스는 Application-Specific Policy입니다. create 권한이 있으면 Argo CD UI에서 애플리케이션 Pod에 exec할 수 있습니다.
kubectl exec와 유사한 기능입니다.

extensions 리소스

extensions 리소스는 프록시 확장 호출 권한을 설정합니다. extensions RBAC 검증은 applications 리소스와 함께 작동하며,
사용자는 요청이 시작된 애플리케이션에 대한 읽기 권한이 필요합니다. 예를 들어 다음 정책은 example-user가 default 프로젝트 내 모든 애플리케이션에서 httpbin 확장을 호출할 수 있게 합니다.

p, example-user, applications, get, default/*, allow
p, example-user, extensions, invoke, httpbin, allow

deny 효과

deny가 정책 효과일 경우, 정책이 일치하면 적용됩니다. allow 정책과 동시에 일치해도 deny가 우선합니다. 정책 파일 내 순서는 결과에 영향이 없으며, 결과는 결정적입니다.

정책 평가 및 매칭

접근 권한 평가는 기본 정책 검증과 사용자별 정책 검증 두 단계로 이루어집니다. 기본 정책에 의해 허용 또는 거부되면 추가 평가 없이 적용됩니다. 효과가 정의되지 않으면 사용자별 정책 평가로 진행됩니다. 접근 권한 평가는 사용자 및 사용자가 속한 그룹 각각에 대해 진행됩니다. 매칭 엔진(policy.matchMode)은 다음 두 가지 모드를 지원합니다.

• glob: glob 패키지 기반
• regex: regexp 패키지 기반

모든 토큰이 일치하면 효과가 반환됩니다. deny 효과 정책이 일치하면 즉시 접근이 거부되고, 모든 정책 평가 후 allow가 하나 이상 있고 deny가 없으면 접근이 허용됩니다.

Glob 매칭

glob 사용 시 정책 토큰은 구분자 없이 단일 용어로 처리됩니다.

p, example-user, applications, action/extensions/*, default/*, allow

example-user가 extensions/DaemonSet/test 액션을 수행하면,

• 사용자(example-user)가 토큰 example-user와 일치
• 리소스(applications)가 토큰 applications와 일치
• action/extensions/DaemonSet/test가 action/extensions/*와 일치 (여기서 /는 구분자 아님)
• default/my-app가 default/*와 일치

SSO 사용자/그룹 사용

scopes 필드는 RBAC 시행 시 검사할 OIDC scope를 제어하며, 기본값은 '[groups]'입니다. 문자열 또는 문자열 리스트로 지정 가능합니다. 예시: email과 groups를 타겟으로 하는 ConfigMap 설정

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
  labels:
    app.kubernetes.io/name: argocd-rbac-cm
    app.kubernetes.io/part-of: argocd
data:
  policy.csv: |
    p, my-org:team-alpha, applications, sync, my-project/*, allow
    g, my-org:team-beta, role:admin
    g, user@example.org, role:admin
  policy.default: role:readonly
  scopes: '[groups, email]'

이는 사용자 이메일과 그룹을 AppProject에 직접 연결하는 데 유용합니다.

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-beta-project
  namespace: argocd
spec:
  roles:
    - name: admin
      description: Admin privileges to team-beta
      policies:
        - p, proj:team-beta-project:admin, applications, *, *, allow
      groups:
        - user@example.org # Value from the email scope
        - my-org:team-beta # Value from the groups scope

Local Users/Accounts

로컬 사용자는 역할에 그룹화하거나 정책을 직접 할당하여 접근 권한을 부여받습니다. 다음은 로컬 사용자에게 정책을 직접 할당하는 예시입니다.

p, my-local-user, applications, sync, my-project/*, allow

로컬 사용자에게 역할을 할당하는 예시는 다음과 같습니다.

g, my-local-user, role:admin

Policy CSV 구성

argocd-rbac-cm ConfigMap에 추가 항목을 넣어 최종 정책 CSV를 구성할 수 있습니다. 추가 항목의 키는 policy.<any string>.csv 패턴을 따라야 합니다. Argo CD는 메인 정책(policy.csv) 아래에 이 패턴의 추가 정책을 모두 이어 붙입니다. 추가 정책의 순서는 키 이름에 따라 결정됩니다. 예를 들어 policy.A.csv와 policy.B.csv 두 개가 있다면, policy.A.csv가 먼저 이어지고 그 다음 policy.B.csv가 이어집니다. 이는 Kustomize, Helm 같은 구성 관리 도구에서 정책을 분할 관리할 때 유용합니다. 다음은 Kustomize overlay로 기존 RBAC ConfigMap에 추가 구성을 넣는 예시입니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  policy.tester-overlay.csv: |
    p, role:tester, applications, *, */*, allow
    p, role:tester, projects, *, *, allow
    g, my-org:team-qa, role:tester

 

RBAC 정책 검증 및 테스트

RBAC 정책이 의도대로 작동하는지 확인하려면 argocd admin settings rbac 명령어를 사용할 수 있습니다. 이 도구는 시스템에 아직 적용되지 않은 정책(로컬 파일이나 ConfigMap)으로도 권한을 테스트할 수 있고, 현재 클러스터에 적용된 라이브 RBAC 설정에 대해서도 검사할 수 있습니다.

정책 검증

정책 구성이 올바르고 Argo CD RBAC가 이해하는지 확인하려면 다음 명령을 사용합니다.

argocd admin settings rbac validate

정책 테스트

역할이나 주체(그룹 또는 로컬 사용자)가 특정 리소스에 대해 원하는 작업을 수행할 권한이 있는지 확인하려면 다음 명령을 사용합니다.

 argocd admin settings rbac can