동기화 단추를 눌렀는데 아무 일도 없었다 — 정책을 파일로 판정한다

목표

argocd-rbac-cm 의 policy.csv 를 직접 쓰고, argocd admin settings rbac 로 문법과 판정을 서버 없이 확인한다. 끝나면 '이 사람은 이것을 할 수 있어야 한다' 는 표를 정책과 함께 저장소에 두고 회귀 검사로 돌릴 수 있다.

왜 중요한가

Argo CD 의 권한은 쿠버네티스 RBAC 와 다른 표다. 클러스터에서 아무 권한이 없는 사람도 Argo CD 계정만 있으면 Argo CD 가 가진 권한으로 무엇이든 동기화할 수 있다 — 그래서 실제 경계는 policy.csv 가 긋는다. 그런데 이 파일은 배포해서 사람이 눌러 보기 전에는 맞는지 알기 어려웠다. argocd admin settings rbac 는 이 판정을 로컬 파일만으로 해 준다. 정책을 코드로 다루고, 바꿀 때마다 기대표를 돌려 보는 일이 그래서 가능해진다. 권한은 한 번 넓히면 아무도 좁히지 않는다 — 좁힐 근거가 표로 남아 있지 않으면 더욱 그렇다.

단계

1. /root/ga-rbac/policy.csv 를 만드세요. role:dev 가 dev 프로젝트의 애플리케이션을 get 과 sync 할 수 있게 하는 p 줄 두 개와, alice 를 그 역할에 묶는 g 줄 하나입니다. argocd admin settings rbac validate --policy-file /root/ga-rbac/policy.csv 가 통과해야 합니다.
2. /root/ga-rbac/can-basic.txt 에 네 줄을 적으세요. 각 줄은 <주체> <동작> <객체> <답> 네 칸을 공백으로 구분합니다. 물어볼 네 가지는 alice get dev/web, alice sync dev/web, alice sync prod/web, bob sync dev/web 이고, 답은 argocd admin settings rbac can <주체> <동작> applications <객체> --policy-file 이 출력하는 Yes 또는 No 를 그대로 씁니다.
3. /root/ga-rbac/broken.csv 에 일부러 잘못된 정책을 쓰세요 — p 줄에서 마지막 allow/deny 칸을 빼면 됩니다. argocd admin settings rbac validate --policy-file /root/ga-rbac/broken.csv 의 출력을 표준오류까지 합쳐 /root/ga-rbac/broken.txt 에 저장하세요. 그 파일에는 정책이 유효하지 않다는 문장이 들어 있어야 합니다.
4. /root/ga-rbac/deny.csv 를 만드세요. role:oncall 은 prod/* 를 sync 할 수 있지만 prod/payments 만은 deny 입니다. deny 줄을 allow 줄보다 먼저 쓰고, carol 을 그 역할에 묶으세요. 그다음 /root/ga-rbac/deny.txt 에 두 줄 — prod/web <답> 과 prod/payments <답> — 을 적습니다.
5. /root/ga-rbac/argocd-rbac-cm.yaml 을 ConfigMap 모양으로 쓰세요. 이름은 argocd-rbac-cm, 네임스페이스는 argocd, data.policy.default 는 role:readonly 이고 data.policy.csv 는 1단계의 세 줄을 그대로 담습니다. 이 파일도 --policy-file 로 그대로 넘길 수 있습니다 — 아무 역할에도 없는 zoe 로 get 과 sync 를 물어 차이를 확인하세요.
6. rbac can 에 존재하지 않는 자원 이름(workloads)과 존재하지 않는 동작(deploy)을 물어 보고, 두 출력을 표준오류까지 합쳐 /root/ga-rbac/strict.txt 에 이어 붙이세요. 이어서 같은 물음에 --strict=false 를 붙인 결과를 /root/ga-rbac/loose.txt 에 저장하세요. 정책 파일은 1단계의 policy.csv 를 씁니다.
7. kwok 클러스터의 argocd 네임스페이스에 AppProject ga-team-a 를 만드세요(/root/ga-rbac/appproject.yaml 로 저장한 뒤 적용). spec.roles 에 이름이 deployer 인 역할을 두고, 정책 한 줄 p, proj:ga-team-a:deployer, applications, sync, ga-team-a/*, allow 와 그룹 ga-team-a-oncall 을 넣습니다. 같은 정책 줄과 g, dana, proj:ga-team-a:deployer 를 /root/ga-rbac/project-role.csv 에도 적어 rbac can 으로 판정이 같은지 확인하세요.
8. /root/ga-rbac/matrix.tsv 에 여섯 줄 이상을 탭으로 구분해 적으세요 — <주체>\t<동작>\t<자원>\t<객체>\t<기대> 이고 기대는 Yes 또는 No 입니다. Yes 와 No 가 모두 한 줄 이상 있어야 합니다. /root/ga-rbac/check-rbac.sh 는 이 표를 한 줄씩 읽어 /root/ga-rbac/argocd-rbac-cm.yaml 에 대해 rbac can 을 돌리고, 맞으면 OK …, 틀리면 MISMATCH … 를 표준출력에만 찍고 한 줄이라도 틀리면 0 이 아닌 코드로 끝나야 합니다. 그 출력을 /root/ga-rbac/matrix-result.txt 에 저장하세요.

참고

• argocd admin settings rbac validate --policy-file <파일> 은 문법만 봅니다. 의미가 맞는지는 rbac can 이 답합니다.
• rbac can 의 인자 순서는 <주체> <동작> <자원> [<객체>] 입니다. 객체는 <프로젝트>/<앱> 표기입니다.
• 정책 파일은 순수 CSV 도 되고 argocd-rbac-cm ConfigMap YAML 도 그대로 받습니다.
• 흔한 실수: p 줄의 마지막 allow/deny 칸을 빠뜨린다. 문법 오류로 잡힙니다.
• 흔한 실수: 객체를 web 처럼 앱 이름만 적는다 — dev/web 처럼 프로젝트까지 적어야 맞습니다.
• 참고: https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/

단계 8개

1. 정책 한 장을 쓰고 문법을 검사한다
2. 정책에 직접 물어본다
3. 칸이 모자란 줄은 어떻게 드러나는가
4. deny 는 줄 순서와 상관없이 이긴다
5. 아무 역할에도 없는 사람에게 무엇을 줄 것인가
6. 없는 자원 이름·없는 동작은 물어보는 단계에서 걸린다
7. 프로젝트 안에서만 통하는 역할을 만든다
8. 표를 만들어 놓고 정책이 바뀔 때마다 돌린다