[사례연구] 사내 개인용 개발환경 이미지 실험기 2부: 만들면서 마주친 것들과 풀어간 방법

KT Cloud 플랫폼 엔지니어링팀이 개발자용 OpenStack 샌드박스 이미지를 구축하면서 마주친 세 가지 기술 과제(IP 자동 복구, GitOps 구조 진화, 자격증명 보안)와 그 해결 방법을 다룬다. 대규모 인프라 프로젝트가 아닌 실험적 이미지 구축 과정에서 나온 실전 의사결정을 공유한다.

핵심 포인트

부팅마다 바뀌는 IP 문제를 systemd 서비스로 자동화해 인증서 재발급, 매니페스트 IP 치환, kubelet 재시작까지 7단계 프로세스로 해결했다.
GitOps 구조를 helm install → Flux HelmRelease → ArgoCD 순으로 단계적으로 진화시켰다.
ArgoCD Vault Plugin(AVP) 대신 External Secrets Operator(ESO)를 선택한 이유는 ArgoCD v3 공식 호환 범위 밖이고 Flux와 ArgoCD가 공통 Secret을 참조해야 했기 때문이다.
Flux와 ArgoCD 양쪽이 공통 Secret을 참조하는 구조로 자격증명 단일 관리를 실현했다.
부트스트랩 자격증명에 읽기 전용, 단일 경로 스코프, 30일 TTL 정책을 적용해 최소 권한 원칙을 유지했다.

상세 정리

배경: OpenStack 기반 개발환경 이미지를 만드는 과정에서 IP가 부팅마다 변경되는 문제가 발생했고 자동화가 필요했다.
IP 자동 복구: 현재 IP 감지 → 인증서 재발급 → 매니페스트 IP 치환 → kubelet 재시작 등 7단계를 systemd 서비스로 묶어 부팅 시 자동 실행되도록 구성했다.
GitOps 1단계(helm install): 초기엔 직접 helm install로 시작했지만 환경별 values 관리가 어려워졌다.
GitOps 2단계(Flux HelmRelease): Flux를 도입해 values 파일을 ConfigMap으로 분리하고 helm template 검증 융통성을 확보했다.
GitOps 3단계(ArgoCD): 최종적으로 ArgoCD 기반 구조로 전환해 선언적 배포 관리를 완성했다.
AVP 미채택 이유: ArgoCD v3 공식 호환 범위 밖이고, Flux와 ArgoCD가 동시에 Secret을 참조해야 하는 구조라 단일 통합점이 필요했다.
ESO 채택: External Secrets Operator로 Vault 시크릿을 Kubernetes Secret으로 동기화하고, Flux와 ArgoCD 양쪽이 공통 Secret을 참조하도록 구성했다.
부트스트랩 자격증명 보안: Vault 초기 접근용 자격증명에 읽기 전용, 단일 경로 스코프, 30일 TTL을 적용해 최소 권한으로 제한했다.
Git 저장소와 이미지에 평문 자격증명이 남지 않도록 모든 시크릿을 Vault 경유로 관리한다.