[44편] kubectl을 그대로 쓰면서 접근 범위를 나눠봤다

쿠버네티스를 운영하는 팀이라면 kubectl을 자주 쓸 것이다. 설정을 확인할 때마다 웹 화면으로 옮겨가기보다, 평소 쓰던 명령으로 필요한 내용을 바로 보고 싶다.

이번에는 Multi Agent와 kubectl로 실습 클러스터에 접속해봤다. 같은 ConfigMap을 읽고 값을 바꾸는 요청을 차례로 보낸 뒤, QueryPie가 역할에 따라 어떻게 처리하는지 확인했다. 조회는 가능하게 두고, 설정 변경은 제한하는 상황이다.

설정은 읽되, 값은 바꾸지 않는 역할을 골랐다

앞서 만든 Orders Lab Viewer 역할을 사용했다. 이 역할에 연결된 정책은 acp-kac-lab 클러스터의 orders-lab 네임스페이스에서 ConfigMap 조회를 허용한다. 실습 대상인 kac-fixture에 대해서는 patch와 update를 명시적으로 제한해뒀다.

관리자 화면에서 정책을 다시 열어 확인했다. 허용할 리소스와 작업, 제한할 리소스와 작업을 각각 적을 수 있었다. 이번에는 설정 내용을 확인하는 담당자에게 맞춘 범위로 실습했다.

Agent 인증을 사용해 kubectl을 연결했다

Mac의 Multi Agent에서 Kubernetes 탭을 열고 Orders Lab Viewer를 선택했다. Manual Clusters 아래에 acp-kac-lab이 보였다. 서버 실습 때처럼 사용자에게 부여된 역할과 접속 대상을 먼저 확인할 수 있었다.

Agent의 Setting → Kubernetes에는 kubeconfig 저장 경로와 설정 안내가 있다. kubeconfig는 kubectl이 어느 클러스터에 어떤 인증 방식으로 접속할지 알려주는 파일이다.

이번에는 Agent가 만든 인증 설정을 바탕으로 실습용 client.kubeconfig를 따로 준비했다. 이 Mac에 공개한 QueryPie 프록시 주소를 지정하고, 인증에는 Agent의 qpctl을 사용했다. 명령마다 --kubeconfig 옵션으로 이 파일을 선택했다.

여기서 사용한 localhost:16444는 이번 Mac 실습 환경의 프록시 주소다. 클러스터의 API 서버 주소와 구분해 지정했다. 접속을 준비한 뒤에는 익숙한 kubectl 명령으로 작업을 이어갔다.

ConfigMap 조회는 평소처럼 실행됐다

먼저 kubectl get configmap으로 orders-lab의 kac-fixture를 조회했다. 이름과 데이터 항목 수가 나왔고, data 내용까지 읽어보니 status는 READY였다.

출력 형식을 바꾸는 옵션도 평소처럼 사용할 수 있었다. 설정값을 확인하기 위해 새로운 명령 체계를 익힐 필요가 없었다. 운영자가 쓰는 CLI를 유지하면서 QueryPie의 인증과 접근 정책을 적용하는 모습이었다.

같은 설정을 바꾸려 하자 정책이 적용됐다

이번에는 같은 ConfigMap의 status를 EP44_CHANGE로 바꾸는 kubectl patch 요청을 보냈다. 실제 서비스 설정이 아닌, 이 실습을 위해 만든 가상 설정값이다.

터미널에는 Forbidden과 함께 “QueryPie - Denied by policy to access the resource.”라는 메시지가 나왔다. 조회할 수 있는 설정이어도, 역할에서 제한한 변경 요청은 통과하지 않았다.

다시 get으로 이름, status, 리소스 버전을 조회했다. 값은 READY, 버전은 실습 전과 같은 559였다. 변경은 제한됐지만 필요한 조회는 이어서 할 수 있었다.

설정을 확인하는 일과 설정을 바꾸는 일을 역할에 맞춰 나눌 수 있다는 점이 좋았다. 담당자에게 점검에 필요한 조회를 열어주면서, 같은 리소스의 변경 작업은 별도로 관리할 수 있었다.

kubectl에서 보낸 요청도 감사 화면에서 확인했다

마지막으로 관리자 화면의 Audit → Request Audit을 열었다. 방금 보낸 변경 요청에는 Event Type DENY, Verb patch가 기록돼 있었다. 사용자, 역할, 클러스터, 네임스페이스와 ConfigMap 이름도 함께 확인했다.

Client Name은 kubectl/v1.36.1, Request Source는 Third-Party Tool이었다. Request Body에는 바꾸려 했던 값 EP44_CHANGE도 남아 있었다.

변경 시도 뒤 다시 조회한 기록도 열어봤다. 같은 사용자와 역할, 같은 ConfigMap에 대한 get 요청은 Success와 ALLOW로 표시됐다. 터미널에서 본 결과와 관리자 화면의 기록이 맞아떨어졌다.

직접 써보니 kubectl을 계속 쓰면서도 작업 범위를 나누고 이력을 남길 수 있다는 점이 편했다. 운영자는 기존 CLI로 점검을 이어가고, 관리자는 누가 어떤 역할로 어느 설정을 조회하거나 바꾸려 했는지 QueryPie에서 확인할 수 있었다.

실습은 QueryPie Community 11.6.7, Multi Agent, kubectl 1.36.1과 K3s 1.36.6 환경에서 진행했다. 화면의 사용자와 ConfigMap은 실습용이다.

참고: QueryPie Multi Agent 사용자 안내 · Kubernetes 정책 YAML 문법 안내