LabHub
学习 学习路径 课程

GitOps 与 Argo CD

点了同步却毫无反应——用文件判定策略

在 LabHub 中继续学习

한국어 원문으로 표시합니다.

목표

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:devdev 프로젝트의 애플리케이션을 getsync 할 수 있게 하는 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:oncallprod/*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.defaultrole:readonly 이고 data.policy.csv 는 1단계의 세 줄을 그대로 담습니다. 이 파일도 --policy-file 로 그대로 넘길 수 있습니다 — 아무 역할에도 없는 zoegetsync 를 물어 차이를 확인하세요.
  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 에 저장하세요.

참고

정책 한 장을 쓰고 문법을 검사한다

/root/ga-rbac/policy.csv 를 만드세요. role:devdev 프로젝트의 애플리케이션을 getsync 할 수 있게 하는 p 줄 두 개와, alice 를 그 역할에 묶는 g 줄 하나입니다. argocd admin settings rbac validate --policy-file /root/ga-rbac/policy.csv 가 통과해야 합니다.

p 줄은 p, <주체>, <자원>, <동작>, <객체>, allow|deny 여섯 칸입니다. 자원은 applications, 객체는 <프로젝트>/<앱이름> 표기라서 dev 프로젝트 전체는 dev/* 입니다. g 줄은 g, <사용자>, <역할> 세 칸입니다.

정책에 직접 물어본다

/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 를 그대로 씁니다.

명령의 마지막 줄이 Yes 또는 No 입니다. 종료 코드도 같이 알려 줍니다 — Yes 면 0, No 면 1. bob 은 어느 역할에도 묶여 있지 않다는 점을 생각해 보세요.

칸이 모자란 줄은 어떻게 드러나는가

/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 에 저장하세요. 그 파일에는 정책이 유효하지 않다는 문장이 들어 있어야 합니다.

출력과 오류를 함께 담으려면 > 파일 2>&1 을 씁니다. 이 명령은 정책이 잘못됐을 때 0 이 아닌 종료 코드를 내므로, 정답지에서도 실패로 멈추지 않게 조심하세요.

deny 는 줄 순서와 상관없이 이긴다

/root/ga-rbac/deny.csv 를 만드세요. role:oncallprod/*sync 할 수 있지만 prod/payments 만은 deny 입니다. deny 줄을 allow 줄보다 먼저 쓰고, carol 을 그 역할에 묶으세요. 그다음 /root/ga-rbac/deny.txt 에 두 줄 — prod/web <답>prod/payments <답> — 을 적습니다.

casbin 은 첫 일치 규칙을 쓰는 방식이 아니라, deny 가 하나라도 걸리면 거절합니다. 그래서 순서를 바꿔 써도 결과가 같습니다 — 직접 확인해 보세요.

아무 역할에도 없는 사람에게 무엇을 줄 것인가

/root/ga-rbac/argocd-rbac-cm.yaml 을 ConfigMap 모양으로 쓰세요. 이름은 argocd-rbac-cm, 네임스페이스는 argocd, data.policy.defaultrole:readonly 이고 data.policy.csv 는 1단계의 세 줄을 그대로 담습니다. 이 파일도 --policy-file 로 그대로 넘길 수 있습니다 — 아무 역할에도 없는 zoegetsync 를 물어 차이를 확인하세요.

policy.default 는 정책에 걸리지 않은 요청에 적용할 역할입니다. role:readonly 는 Argo CD 가 기본으로 들고 있는 내장 역할이라 policy.csv 에 쓰지 않아도 있습니다. ConfigMap 의 여러 줄 값은 | 블록으로 씁니다.

없는 자원 이름·없는 동작은 물어보는 단계에서 걸린다

rbac can 에 존재하지 않는 자원 이름(workloads)과 존재하지 않는 동작(deploy)을 물어 보고, 두 출력을 표준오류까지 합쳐 /root/ga-rbac/strict.txt 에 이어 붙이세요. 이어서 같은 물음에 --strict=false 를 붙인 결과를 /root/ga-rbac/loose.txt 에 저장하세요. 정책 파일은 1단계의 policy.csv 를 씁니다.

rbac can 은 기본이 strict 입니다 — 자원과 동작 이름을 Argo CD 가 아는 목록과 대조해 모르는 이름이면 바로 멈춥니다. 오타 난 정책을 배포한 뒤에 알게 되는 것보다 낫습니다. --strict=false 를 주면 대조를 건너뛰고 그냥 판정합니다.

프로젝트 안에서만 통하는 역할을 만든다

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 으로 판정이 같은지 확인하세요.

프로젝트 역할의 주체 이름은 proj:<프로젝트>:<역할> 형식입니다. 전역 policy.csv 와 같은 문법이라 같은 도구로 검사할 수 있습니다 — 다른 것은 이 줄이 AppProject 안에 살아서 그 프로젝트 관리자가 직접 고칠 수 있다는 점입니다.

표를 만들어 놓고 정책이 바뀔 때마다 돌린다

/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 에 저장하세요.

표의 기대값은 5단계의 ConfigMap 기준입니다 — alice 는 dev 를 동기화할 수 있고, 아무 역할에도 없는 사람은 policy.default 덕에 읽기만 됩니다. 스크립트가 파일을 직접 쓰면 채점기가 다시 돌릴 때 학생 산출물을 덮어씁니다. 표준출력으로만 내보내고 리다이렉션은 사람이 하세요.