GCP의 매니지드 Kubernetes인 GKE를 사용하면서 1개의 보안 취약점이 있었다.
바로 kubectl 명령어를 치는 사용자에 대한 권한제어가 없던 것이다.
예를 들자면 사용자가 GKE로 연결하기만하면 모든 kubectl 명령어가 가능했다.
(물론 GKE의 연결할 수 있는 IP를 제어하고 있는 상태지만 1차 보안만 한 느낌이다.)
GKE에서 권한관리를 하려면 IAM과 RBAC의 차이점을 알고 있어야한다.
GCP의 IAM은 Kubernetes 내부가 아닌 GKE 자체를 관리하는 권한이다.
예를 들어 Kubernetes의 단순 연결부터 GKE의 노드풀 관리, GKE 클러스터 관리등 GKE 자체의 권한과 밀접해있다.
반면에 RBAC는 Kubernetes 내부만 제어하므로 kubectl get, kubectl edit 등 kubectl 명령어에 대한 권한을 제어한다.
GCP의 IAM은 사내 정책에 따라 진행한다지만 Kubernetes RBAC 관리는 하지않고 있기에 보안적으로 위험하다고 생각했다.
여러 오픈소스들과 커뮤니티를 뒤져보니 RBAC를 관리하는 방법중에 끌리는 것들이 없었다.
이참에 DevOps 엔지니어지만 스크립트만 주구장창 만들어왔으니 제대로 개발 한 번 해보자는 욕심이들었다.
Backend와 Front를 각각 따로 개발하고, 이에 맞게끔 아키텍처를 구성하며 RBAC Manager라는 프로그램을 만들어보고자 했다.
RBAC Manager
목적 자체는 GKE에 접근한 사용자별로 RBAC를 관리해주는 프로그램이다.
그러면 사용자별로 관리가 되어야하고, 네임스페이스별로 담당자가 다르기에 RBAC는 사용자별, 네임스페이스별, 역할별로 나눠져야했다.
또한 언어자체는 늘 Python, Shell만 써왔기에 이번 기회를 토대로 Golang과 React를 써보기로 했다.
front, backend 전부 다 Container로 올리며, helm chart를 만들어 values.yaml으로 관리를 하고 싶어서 이에 맞는 Templates들을 만들었다.
추후 동시성 및 DB 또는 Redis를 추가할 수도 있기에 Deployment로 구성하고 Ingress, Service 등의 Templates들을 만들었다.
RBAC 자체를 사용자별, 네임스페이스별, 역할별로 나누게 되면 n * n * n 구조이기에 사용자를 기준으로 네임스페이스별 역할들이 출력되게끔 설계했다.
이때 현재 RBAC 목록자체들도 보여줘야하는거면 Kubernets 내부에서만 확인하려면 성능적으로 안좋아질 것 같다는 생각을 했다.
그래서 사용자별 권한들을 홍길동-index.json이라는 파일을 만들어 해당 파일을 기준으로 사용자별 권한을 제어하기로 했다.
당연하게도 이중화를 고려해야하기에 해당 json 파일은 GCS에서 읽고 쓰게끔 진행하였고, GCP Workload Identity를 사용하여 별도의 IAM Json Key없이 GCS에 연동한다.
front는 간단하게 2가지 페이지만 만들었다.
RBAC Manger의 접근을 Ingress에서 IP로 통제한다지만 인증이 필요하기에 /login 페이지와 / 페이지를 만들었다.
내가 담당하는 서비스들은 GCP에 전부 올라가있기에 별도의 인증방식을 만들기보다는 GCP SSO를 통해서 인증하게끔 했다.
GCP SSO를 쓰게 되면 따로 DB없이 수월하게 인증관리를 할 수 있다.
(다만 session_token 검증같은 부분으로 인해 추후 DB나 Redis를 써야 이중화가 가능할 것 같다.)
자 그러면 이렇게 아키텍처를 짜고 코드는 당연하게도 Claude와 GPT를 써서 같이 코딩을 하기로 했다.
(같이라고는 하지만 거의 검증만 하고 틀린 부분들만 잡아주면 된다.)
다음 게시글에는 실제 개발을 진행하면서 이슈가 됐던 부분과 간단한 코드 및 화면들을 첨부하고자 한다.