[26편] Kubernetes 설정은 읽고, 변경은 막아봤다 — QueryPie 역할과 접근 정책

운영 중인 Kubernetes 설정을 확인해야 한다고 해서, 그 설정을 바꾸는 권한까지 필요한 것은 아니다. 장애를 살펴보거나 배포 상태를 점검할 때도 현재 값을 읽는 것만으로 충분한 일이 많다.

이번에는 QueryPie Community에서 개발자에게 ConfigMap 조회 권한을 주고, 설정값을 바꾸는 요청은 막아 봤다. 브라우저에서 설정을 읽을 수 있었고, 변경을 적용하자 QueryPie 정책에 따라 거부됐다는 메시지가 나왔다. 관리자는 조회와 변경 시도를 같은 감사 화면에서 확인할 수 있었다.

실습용 Kubernetes 클러스터를 등록했다

Mac에 별도로 만든 Kubernetes 클러스터를 acp-kac-lab이라는 이름으로 등록했다. 주문 서비스의 설정을 확인하는 상황을 가정해 orders-lab 네임스페이스에 kac-fixture라는 ConfigMap을 준비했다. ConfigMap은 애플리케이션에서 사용하는 설정값을 담는 Kubernetes 리소스다.

QueryPie 관리자 화면에서 클러스터의 API 주소와 연결 정보를 입력하고 Verify Credential을 눌렀다. Verified가 표시된 것을 확인한 뒤 저장했다. 요청 기록을 남기기 위한 Request Audit도 켜 두었다.

설정 조회 업무에 맞는 역할을 만들었다

정책 이름은 Orders Lab ConfigMap Read Only로 정했다. orders-lab의 ConfigMap에 get, list, watch를 허용하고, 실습 대상인 kac-fixture의 patch와 update는 거부하도록 설정했다. 어떤 클러스터에서, 어떤 종류의 리소스에, 어떤 작업을 허용할지 나눠 지정할 수 있었다.

이 정책을 Orders Lab Viewer 역할에 연결하고 Demo Developer에게 부여했다. 사용자에게 역할을 줄 때는 만료일도 함께 확인할 수 있었다. 업무에 필요한 권한을 역할 하나로 묶어 관리할 수 있다는 점이 편했다.

개발자 계정으로 설정을 열어 봤다

이제 Demo Developer로 로그인해 Kubernetes 메뉴에서 Orders Lab Viewer를 선택했다. 등록한 클러스터의 Connect를 누르자 Web Client가 열렸다. 이번 작업은 브라우저에서 진행할 수 있었다.

Config & Storage 아래의 ConfigMap을 열고 orders-lab을 선택했다. 목록에 실습용 kac-fixture가 나타났다. 해당 항목의 YAML 탭에서 설정 내용을 확인하니 status 값은 READY였다.

클러스터 전체를 관리하는 권한을 주지 않고도 필요한 설정을 찾아 읽을 수 있었다. 운영 담당자는 접근 범위를 정하고, 사용자는 자기 역할을 선택해 필요한 정보를 확인하는 방식이었다.

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

YAML 화면에서 Edit를 누르고 status를 READY에서 QUERYPIE_CHANGE_TEST로 바꿨다. View Diff를 열자 바뀌는 한 줄이 좌우로 비교됐다. 실제로 적용하기 전에 변경 내용을 확인할 수 있어 알아보기 쉬웠다.

Apply를 누르자 “QueryPie - Denied by policy to access the resource.”라는 메시지가 나왔다. 설정을 읽는 것은 가능했지만, 바꾸는 요청은 QueryPie 정책에 따라 거부됐다.

편집 창을 닫고 같은 ConfigMap을 새로 불러왔다. status는 여전히 READY였고 리소스 버전도 그대로였다. 조회 작업은 계속할 수 있으면서, 허용하지 않은 변경은 적용되지 않은 것이다.

이번 실습에서는 이 ConfigMap에 대한 변경이 Kubernetes 자체 권한으로는 가능한 조건을 준비해 뒀다. 그 위에 QueryPie의 조회용 정책을 적용했을 때 실제 변경 요청이 거부되는 것을 확인했다. 기존 Kubernetes 권한에 더해 사용자 업무에 맞는 접근 기준을 관리할 수 있다는 점이 잘 보였다.

감사 기록에서 누가 무엇을 바꾸려 했는지 확인했다

관리자 화면의 Audit → Kubernetes → Request Audit를 열었다. 방금 수행한 조회와 변경 요청이 나란히 있었다. 변경 시도의 상세에는 Demo Developer, Orders Lab Viewer, acp-kac-lab이 표시됐고, 대상도 orders-lab의 kac-fixture로 정확히 남았다.

이 요청의 Verb는 update, Event Type은 DENY였다. 메시지에는 정책에 따라 접근을 거부했다는 설명이 있었고, Request Body에는 바꾸려던 QUERYPIE_CHANGE_TEST 값도 들어 있었다.

변경이 막혔다는 사실뿐 아니라 어떤 작업을 시도했는지까지 살펴볼 수 있었다. 사용자에게 별도로 상황을 물어보기 전에 관리자가 기록에서 확인할 수 있는 정보가 많았다.

조회와 변경을 구분해 운영할 수 있었다

변경 요청 뒤에 다시 읽은 기록도 열어 봤다. 같은 사용자의 get 요청은 Success, Event Type은 ALLOW였다. Request Source에는 Web Client가 표시됐고, 실제 조회에 사용한 Kubernetes 그룹 qp-kac-demo도 확인할 수 있었다.

직접 써 보니 “설정은 확인하되 변경은 맡기지 않는다”는 업무 구분을 정책과 역할로 표현할 수 있다는 점이 좋았다. 사용자는 필요한 정보를 브라우저에서 확인하고, 관리자는 변경 권한을 통제하면서 요청 이력까지 살펴볼 수 있었다.

DB 조회와 서버 명령을 다뤘던 앞선 글에 이어, 이번에는 Kubernetes 설정에서도 같은 관리 흐름을 경험했다. 여러 종류의 자원에 대한 사용자 권한과 작업 기록을 QueryPie에서 함께 다룰 수 있다는 점이 도입 담당자에게 유용하겠다.

이번 실습은 QueryPie Community 11.6.7의 Web Client(Beta)와 별도 Kubernetes 실습 클러스터에서 진행했다. 사용한 ConfigMap에는 실습용 설정값만 넣었다.

참고: Kubernetes 정책 문법 · Web Client 사용 안내 · Request Audit