금융권에서 LLM Agent 플랫폼을 쿠버네티스(Kubernetes)로 올리려다 보면, 국내에 “K8S 보안 요건”이 세세하게 정리된 문서를 찾기 어렵다는 벽을 자주 만납니다.
이 글에서는 DoD(미 국방부) 관점의 Kubernetes Hardening Guidance(STIG 계열 철학)를 바탕으로, 망분리 환경에서 더 현실적인 위협(내부 계정 탈취·과권한 RBAC)을 중심에 두고 “플랫폼이 강제할 수 있는” 하드닝 프레임을 정리해봅니다.
왜 DoD(STIG)식 하드닝이 금융권에도 잘 맞는가
제가 하드닝 가이드를 보며 강하게 느낀 건 다음의 “종심방어(Defense in Depth)” 철학입니다.
- 뚫린다는 걸 전제합니다(assume breach)
- 기본값(default)을 믿지 말라고 합니다
- 최소 권한(least privilege)은 협상 불가라고 봅니다
- 공급망(supply chain)도 공격 경로로 봅니다
- 못 보면 못 막습니다(가시성/감사/로깅)
금융권은 망분리가 기본이라 “외부에서 못 들어오니 안전”으로 착각하기 쉬운데, 실제로는 내부 계정 탈취 + 과권한이 반복되면 망분리는 방어선이 되기 어렵습니다. 특히 LLM Agent는 일반 서비스보다 “데이터 접근 + 도구 호출(행위)” 범위가 넓어, 쿠버네티스에서 의도된 경로만 가능하게 강제하는 플랫폼 통제가 필수가 됩니다.
위협 모델을 “외부 침투”에서 “내부 계정 탈취”로 옮기기
대화에서 가장 현실적이고 자주 일어난다고 한 시나리오는 이거였습니다.
- (1) 개발자/운영자 계정 탈취로 과권한 RBAC 악용
이 시나리오에서 핵심은 “침해를 0으로 만들기”가 아니라, 탈취된 자격증명으로도 피해가 확산되지 않게 만드는 것 입니다. 즉 하드닝의 목표는 다음처럼 바뀝니다.
- 사람/CI 토큰이 유출돼도 클러스터 전역 권한 상승이 안 되게
- 한 네임스페이스가 뚫려도 옆 서비스로 횡적 이동(lateral movement)이 안 되게
- 무엇을 했는지 감사로그가 남고, 나중에 증적이 되게
이 관점이 잡히면, 하드닝 체크리스트는 “문서”가 아니라 플랫폼 강제 정책(Policy-as-Code) 으로 내려가야 합니다.
플랫폼이 강제해야 효과가 나는 하드닝 축 5가지
DoD 가이드가 요구하는 건 크게 API 서버/etcd/노드/애드온 전반의 강화 + 운영 통제인데, 금융권 플랫폼팀이 “표준으로 강제”할 때 실무적으로는 아래 5축으로 정리하면 실행이 쉬웠습니다.
1) RBAC: “최소 권한 + 경계(네임스페이스) + 짧은 수명”을 기본값으로
계정 탈취가 반복되는 조직이라면 RBAC는 “잘 짜면 된다” 수준이 아니라 안전장치가 여러 겹이어야 합니다.
- 클러스터 범위 권한(ClusterRoleBinding) 남발 금지
- 서비스별 네임스페이스 경계 고정 + 교차 접근 최소화
- 사람 계정: SSO/MFA, 세션·토큰 수명 최소화(JIT 접근까지 가면 베스트)
- 서비스 계정: 토큰 자동 마운트 금지/최소화, 필요한 경우에만 명시적으로 허용
예: 서비스 어카운트 토큰 자동 마운트 방지(기본 안전장치)
apiVersion: v1
kind: ServiceAccount
metadata:
name: agent-backend
namespace: llm-agent
automountServiceAccountToken: false
이 한 줄이 만능은 아니지만, “컨테이너가 기본으로 쿠버네티스 API 권한을 가진다”는 전제를 끊어주는 효과가 큽니다.
2) 네트워크 격리: East-West 트래픽을 “기본 거부(deny)”로 두기
망분리 환경에서 실제 사고 확산은 보통 클러스터 내부(East-West)에서 일어납니다. 그래서 네트워크 정책은 “있으면 좋음”이 아니라 기본값(deny all) 로 시작해야 합니다.
예: 네임스페이스 단위 default deny (Ingress/Egress 모두 차단)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: llm-agent
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
이후에 필요한 통신만 allowlist로 열어줍니다. 플랫폼팀이 “엔드포인트를 하나도 허용 못 한다”로 가는 경우가 많은데, 저는 이걸 “허용/비허용”이 아니라 정책으로 통제 가능한 경로만 열자로 프레이밍을 바꾸는 게 협상에 도움이 되었습니다.
3) 기본값 강화: API Server/etcd/노드 설정은 “운영 표준”으로 고정하기
DoD 가이드는 구성요소별로 최소 권한, 접근통제, 암호화, 로깅을 강하게 요구합니다. 실무적으로 중요한 포인트만 뽑으면:
- API Server: 익명 접근 차단, 강한 인증/인가, 감사로그 필수
- etcd: 암호화(전송/저장), 접근 경로 최소화, 백업/키 관리
- 노드: 호스트 권한을 뚫는 기능(Privileged, hostPath 등) 최소화, 런타임 보안
여기서 핵심 인사이트는 기본값을 믿지 말라는 말이 “사람이 잘하자”가 아니라 “플랫폼이 고정하자”로 연결돼야 한다는 점입니다.
4) 이미지/공급망: “신뢰된 이미지”만 클러스터에 들어오게 만들기
LLM 플랫폼은 패키지/모델/서드파티 라이브러리 의존성이 많아서 공급망 공격 표면이 커집니다. DoD 가이드도 이미지 검증·서명, 취약점 관리 같은 운영 통제를 강하게 강조합니다.
플랫폼 기준으로는 보통 아래를 “기본 통제”로 잡습니다.
- 사내 레지스트리만 허용(외부 pull 금지)
- 이미지 서명/검증(예: Sigstore/cosign 계열)
- CI 단계에서 취약점 스캔 + 배포 차단 게이트
- 태그 대신 digest pinning(재현 가능/변조 방지)
5) 감사로그/가시성: “못 보면 못 막는다”를 증적으로 바꾸기
플랫폼팀이 egress를 막고 싶어하는 배경에는 종종 “무슨 트래픽이 나갔는지 증적을 못 뽑는다”는 불안이 있습니다. DoD 가이드가 말하는 로깅·모니터링은 결국 다음 질문에 답하게 만드는 장치입니다.
- 누가(어떤 주체가) 언제 어떤 리소스에 접근했나?
- 어떤 권한으로 무엇을 변경했나?
- 이상 징후가 발생하면 어디서 탐지하고 어떻게 추적하나?
쿠버네티스에서 가장 기본은 Audit Log 활성화 + 보관/무결성(변조 방지) 이고, 여기에 네트워크/런타임/이미지 이벤트를 결합해 “사고 대응 가능한 로그 체인”을 만드는 게 목표입니다.
“규정 준수 하드닝 vs 개발/배포 속도”의 균형을 어떻게 잡을까
구축 단계에서 흔한 실패 패턴은 둘 중 하나로 치우치는 겁니다.
- 모든 걸 막아버려서(예: “어느 엔드포인트도 허용 불가”) 플랫폼 가치가 0에 수렴
- 반대로 빨리 하자고 예외(클러스터어드민, 와일드카드 egress)가 쌓여서 통제가 붕괴
제가 현실적으로 추천하는 균형점은 이렇습니다.
- “절대 금지”는 소수만 박고, 나머지는 “조건부 허용(정책+로깅+승인)”으로 설계합니다.
- 그리고 하드닝 문서를 “권고사항”으로 남기지 말고, OPA/Kyverno, NetworkPolicy, Pod 보안 정책 등으로 강제합니다(플랫폼 팀이 표준으로 강제할 가능성이 높다고 하셨으니 특히요).
결국 금융권에서 살아남는 하드닝은 “잘하자”가 아니라 강제 + 예외 절차 + 증적 자동화로 완성됩니다.
마무리
DoD(STIG)식 쿠버네티스 하드닝은 규정 준수 체크리스트처럼 보이지 실제로는 망분리 환경에서 더 자주 터지는 내부 침해(계정 탈취·과권한·횡적 이동) 를 막기 위한 종심방어 설계에 가깝습니다. LLM Agent 플랫폼이라면 더더욱 “기본값 강화 + 최소권한 + 네트워크 기본 deny + 공급망 검증 + 감사 가시성”을 플랫폼 정책으로 강제하는 방향이 가장 안전하고, 장기적으로 운영 효율도 좋아집니다.