보안과 거버넌스를 처음부터 넣는 방법

보안은 운영 직전에 붙이는 기능이 아니다

AI 플랫폼은 처음에는 작게 시작한다. 몇 명의 데이터 과학자가 노트북에서 실험하고, 한두 개의 학습 Job이 GPU 노드에서 실행된다. 이 단계에서는 보안 체계가 과해 보일 수 있다. 하지만 데이터셋, 모델 파일, API 키, 고객 로그가 모이기 시작하면 이야기가 달라진다. 누가 어떤 데이터를 볼 수 있는지, 어떤 이미지를 실행할 수 있는지, 모델 API가 어느 내부 서비스에 접근할 수 있는지를 나중에 정리하기는 어렵다.

Kubernetes 보안의 핵심은 하나의 거대한 방화벽이 아니다. API 접근 제어, 네임스페이스 분리, 네트워크 정책, Secret 관리, 감사 로그, Admission 정책을 여러 겹으로 쌓는 것이다. Kubernetes 공식 보안 문서에서도 클러스터 접근 제어, 워크로드 보호, 네트워크 제어, 감사 로깅 같은 요소를 중요한 축으로 다룬다.¹

AI 워크로드에서는 이 원칙이 더 중요하다. 학습 파이프라인은 대량의 원천 데이터에 접근하고, 추론 서비스는 실시간 요청과 내부 데이터 서비스를 연결하며, 실험 환경은 외부 패키지와 모델을 자주 가져온다. 따라서 보안의 목표는 "모든 것을 막는 것"이 아니라, 실험 속도를 유지하면서 위험한 경로를 기본적으로 닫아두는 것이다.

AI 생성 이미지

역할을 먼저 나누고 권한을 설계한다

가장 먼저 정할 것은 사람과 워크로드의 역할이다. Kubernetes에서는 RBAC, 즉 역할 기반 접근 제어를 통해 어떤 사용자가 어떤 리소스에 어떤 행동을 할 수 있는지 정의한다. 여기서 중요한 기준은 최소 권한이다. 필요한 권한만 주고, 필요가 끝나면 회수할 수 있어야 한다.

AI 플랫폼의 기본 역할은 다음처럼 나눌 수 있다.

네임스페이스는 권한의 기본 경계로 사용한다. 앞에서 제안한 ai-dev, ai-staging, ai-prod 구조를 보안 기준에도 그대로 연결한다. ai-dev에서는 실험을 빠르게 허용하되 민감 데이터 접근을 제한한다. ai-staging에서는 배포 전 검증과 보안 스캔을 통과한 이미지만 실행한다. ai-prod에서는 사람이 직접 수정하기보다 승인된 CI/CD 파이프라인이 배포하도록 만든다.

주의할 점은 사람 권한과 워크로드 권한을 섞지 않는 것이다. 학습 Job, 평가 Job, 추론 Pod는 각각 별도의 ServiceAccount를 사용해야 한다. 예를 들어 학습 Job은 학습 데이터 버킷과 체크포인트 저장소에 접근할 수 있지만 운영 추론 Secret은 읽을 수 없어야 한다. 추론 서비스는 모델 파일과 필요한 내부 API에만 접근해야 하며, 원천 학습 데이터 전체를 읽을 필요는 없는 경우가 많다.

작게 시작할 때의 기준은 간단하다.

• 사람에게는 네임스페이스 단위 RoleBinding을 우선 사용한다.

• ClusterRoleBinding은 꼭 필요한 운영자에게만 제한한다.

• ServiceAccount는 워크로드 유형별로 분리한다.

• ai-prod 변경은 사람의 직접 kubectl apply보다 승인된 배포 파이프라인을 통하게 한다.

• 권한 변경 이력은 티켓, Git, 감사 로그 중 하나로 추적 가능해야 한다.

이 정도만 해도 "모두가 관리자 권한을 갖고 실험하다가 운영까지 그대로 가는" 상황을 피할 수 있다. 보안 설계는 거창한 문서에서 시작하기보다, 누가 무엇을 할 수 있는지 표로 적어보는 것에서 시작하는 편이 훨씬 현실적이다.

안전하지 않은 이미지는 실행 전에 걸러낸다

AI 프로젝트에서는 컨테이너 이미지가 빠르게 늘어난다. 전처리 이미지, 학습 이미지, 평가 이미지, 추론 서버 이미지, 벤치마크 이미지가 별도로 만들어진다. 여기에 외부 모델 서버, 오픈소스 패키지, CUDA 라이브러리까지 포함되면 이미지 공급망이 복잡해진다.

이미지 보안은 실행 후 탐지보다 실행 전 차단이 더 효과적이다. Kubernetes에서는 API 서버로 들어오는 요청을 Admission 단계에서 검증하거나 변경할 수 있다. ValidatingAdmissionPolicy나 Admission Webhook을 사용하면 규칙을 어긴 Pod 생성을 차단하거나 경고할 수 있다.²

초기 AI 플랫폼에서 현실적인 이미지 정책은 다음 정도면 충분하다.

1. 승인된 레지스트리만 허용한다.
   운영 네임스페이스에서는 공개 레지스트리 이미지를 직접 실행하지 않는다. 내부 레지스트리나 승인된 프라이빗 레지스트리를 거치게 한다.

2. 취약점 스캔을 통과한 이미지만 배포한다.
   빌드 파이프라인에서 OS 패키지, Python 패키지, CUDA 관련 라이브러리의 알려진 취약점을 검사한다. 모든 취약점을 즉시 제거하기 어렵다면, 심각도 기준과 예외 승인 절차를 둔다.

3. 이미지 서명을 검증한다.
   Cosign 같은 도구를 사용해 이미지가 승인된 빌드 파이프라인에서 만들어졌는지 확인할 수 있다. 중요한 것은 도구 이름이 아니라 "누가 만든 이미지인지 증명하고, 배포 시점에 검증한다"는 흐름이다.

4. 태그보다 다이제스트를 우선한다.
   latest 태그는 같은 이름으로 다른 이미지가 실행될 수 있다. 운영 배포에서는 이미지 다이제스트 또는 불변 태그를 사용해 재현성을 높인다.

5. 위험한 Pod 설정을 금지한다.
   privileged 컨테이너, hostPath 마운트, hostNetwork, root 실행, 불필요한 Linux capability는 기본적으로 금지한다. 예외가 필요하면 네임스페이스, 기간, 사유를 남긴다.

이 정책은 데이터 과학자의 실험을 막기 위한 것이 아니다. 실험 이미지는 ai-dev에서 빠르게 검증하되, ai-staging과 ai-prod로 넘어갈 때는 스캔, 서명, 승인 절차를 거치게 하는 것이 균형 잡힌 접근이다. 예외가 필요할 때도 "이번 한 번만 허용"으로 끝내지 말고, 누가 승인했는지와 언제까지 허용할지를 남겨야 한다. 그래야 예외가 시간이 지나 기본값처럼 굳어지는 일을 막을 수 있다.

Secret, ConfigMap, 외부 시크릿 매니저를 구분한다

Kubernetes에서 설정값을 다룰 때 자주 혼동하는 리소스가 Secret과 ConfigMap이다. 둘 다 Pod에 값을 전달할 수 있지만 목적이 다르다.

ConfigMap은 민감하지 않은 설정에 사용한다. 예를 들어 모델 서버의 배치 크기, 로그 레벨, 피처 플래그, 내부 서비스 주소처럼 노출되어도 큰 문제가 없는 값이다. 반면 Secret은 API 키, 데이터베이스 비밀번호, 토큰, 인증서처럼 보호가 필요한 값에 사용한다. Kubernetes Secret은 편리한 기본 수단이지만, 이름과 달리 그 자체만으로 모든 보안이 해결되지는 않는다. 저장 시 암호화, 접근 RBAC, 회전, 감사가 함께 필요하다.¹

운영 환경에서는 외부 시크릿 매니저를 함께 고려한다. 예를 들어 클라우드의 Secret Manager, Vault, KMS 기반 시스템을 원본 저장소로 두고, Kubernetes에는 필요한 시점에만 주입한다. 이 방식은 Secret 회전, 접근 로그, 중앙 정책 관리에 유리하다.

실무 기준은 다음처럼 잡을 수 있다.

특히 피해야 할 방식은 Secret을 컨테이너 이미지에 넣는 것이다. 이미지에 들어간 키는 회수하기 어렵고, 레지스트리 접근 권한이 있는 사람에게 퍼질 수 있다. Git 저장소에 Secret을 올리는 것도 마찬가지로 위험하다. 환경 변수로 주입하는 방식도 로그나 디버깅 도구를 통해 노출될 수 있으므로, 가능하면 파일 마운트나 워크로드 아이덴티티 방식을 우선 검토한다.

여기서 핵심은 "Secret을 어디에 저장할 것인가"보다 "누가, 어떤 워크로드 신원으로, 언제 접근할 수 있는가"이다. 장기 운영되는 플랫폼일수록 키 파일을 Pod 안에 오래 넣어두는 방식보다, 짧은 수명의 토큰과 실행 신원 기반 접근으로 옮겨가는 편이 안전하다.

민감 데이터 파이프라인은 감사 가능한 단위로 나눈다

AI 보안에서 가장 자주 놓치는 부분은 데이터 접근 이력이다. 모델 파일은 배포 승인을 받지만, 그 모델이 어떤 데이터로 학습되었는지, 누가 원천 데이터에 접근했는지, 추론 요청 로그에 민감 정보가 포함되었는지는 뒤늦게 확인하려는 경우가 많다.

학습·추론 파이프라인이 민감 데이터를 다룬다면 다음 질문에 답할 수 있어야 한다.

• 어떤 ServiceAccount가 어떤 데이터 저장소에 접근했는가?

• 어떤 Job이 어떤 데이터 버전으로 실행되었는가?

• 학습 결과 모델은 어떤 평가와 승인을 거쳐 등록되었는가?

• 운영 추론 서비스가 요청과 응답을 어디까지 로그로 남기는가?

• 개인정보, 고객 식별자, 계약 데이터가 로그나 피처 저장소에 남지 않는가?

• 권한 변경, Secret 조회, 운영 배포 변경을 누가 수행했는가?

Kubernetes 감사 로그는 사용자, 애플리케이션, 컨트롤 플레인이 API 서버에 수행한 활동을 시간순으로 기록할 수 있다.¹ 다만 감사 로그만으로 데이터 거버넌스가 완성되지는 않는다. Kubernetes API에서 일어난 일은 볼 수 있지만, 오브젝트 스토리지에서 실제 파일을 읽은 이력이나 모델 레지스트리에 등록된 승인 이벤트까지 자동으로 설명해주지는 않는다. 오브젝트 스토리지 접근 로그, 모델 레지스트리 이벤트, CI/CD 승인 이력, 애플리케이션 로그가 함께 연결되어야 한다.

초기에는 모든 것을 완벽하게 중앙화하려 하기보다, 중요한 이벤트부터 표준화한다.

• 운영 네임스페이스의 배포 변경

• RBAC, RoleBinding, ServiceAccount 변경

• Secret 생성, 수정, 접근 권한 변경

• 민감 데이터 버킷 접근

• 모델 등록, 승인, 운영 반영

• 대량 추론 Job 실행

• 외부 API로 나가는 추론 또는 에이전트 호출

감사 로그는 "장애 후 원인 분석"뿐 아니라 "승인되지 않은 데이터 접근을 줄이는 장치"로 봐야 한다. 로그를 남긴다는 사실 자체가 운영 습관을 바꾼다. 어떤 이벤트를 남길지 정했다면 보관 기간과 열람 권한도 함께 정해야 한다. 감사 로그가 너무 짧게 보관되거나 너무 많은 사람이 볼 수 있다면, 정작 필요할 때 신뢰할 수 있는 근거가 되기 어렵다.

네트워크는 기본 차단 후 필요한 경로만 연다

Kubernetes 클러스터 안의 Pod는 기본 설정만으로는 서로 통신할 수 있는 경우가 많다. AI 플랫폼에서는 이것이 위험한 기본값이 될 수 있다. 실험용 노트북 Pod가 운영 데이터베이스에 접근하거나, 추론 서비스가 필요하지 않은 내부 관리 API에 연결되거나, 학습 Job이 외부 인터넷으로 대량 데이터를 전송하는 경로가 열릴 수 있다.

NetworkPolicy는 Pod 간 트래픽과 외부 네트워크 방향 트래픽을 제한하는 Kubernetes의 기본 정책 리소스다.¹ 단, 실제 적용 여부는 사용하는 CNI 플러그인이 NetworkPolicy를 지원해야 한다. 또한 기본 NetworkPolicy만으로 도메인 이름 단위의 세밀한 외부 API 제어가 항상 되는 것은 아니므로, 필요하면 egress gateway, 프록시, 방화벽 정책과 함께 설계한다.

권장 출발점은 민감 네임스페이스부터 기본 차단 정책을 적용하는 것이다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: ai-prod
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

이 정책을 적용하면 ai-prod의 모든 Pod는 기본적으로 들어오는 연결과 나가는 연결이 막힌다. 이후 필요한 경로만 허용한다. 예를 들어 추론 Pod는 API Gateway에서 들어오는 요청, 모델 저장소 접근, 특정 피처 서비스 접근, 모니터링 시스템으로의 메트릭 전송만 허용할 수 있다.

모델 API와 내부 데이터 서비스 접근은 다음 기준으로 제한한다.

• 추론 서비스는 필요한 데이터 서비스에만 접근한다.

• 학습 Job은 원천 데이터와 체크포인트 저장소에 접근하되 운영 DB에는 직접 접근하지 않는다.

• 노트북 환경은 운영 네트워크와 분리한다.

• 외부 LLM API나 SaaS 호출은 프록시 또는 게이트웨이를 거쳐 기록한다.

• DNS, 패키지 저장소, 모델 다운로드 경로도 허용 목록으로 관리한다.

서비스 메시를 사용하는 조직이라면 더 세밀한 제어가 가능하다. 서비스 간 mTLS, 요청 단위 인증, 라우팅 정책, 트래픽 관측을 적용할 수 있다. 다만 서비스 메시는 복잡도를 높인다. 모든 팀에 바로 적용하기보다, 운영 추론 서비스와 민감 데이터 서비스 사이처럼 가치가 분명한 구간부터 시작하는 편이 현실적이다.

작게 시작하는 보안 체크리스트

AI 플랫폼이 아직 초기라면 다음 항목부터 점검하면 된다.

• ai-dev, ai-staging, ai-prod 네임스페이스가 분리되어 있는가?

• 데이터 과학자, ML 엔지니어, 운영자의 RBAC가 다르게 정의되어 있는가?

• 운영 배포는 승인된 CI/CD 파이프라인을 통해서만 이루어지는가?

• 워크로드별 ServiceAccount가 분리되어 있는가?

• 운영 네임스페이스에서 승인되지 않은 레지스트리 이미지 실행을 막는가?

• 이미지 스캔과 서명 검증을 배포 흐름에 넣었는가?

• 위험한 Pod 설정을 정책으로 차단하거나 승인 절차로 관리하는가?

• Secret과 ConfigMap 사용 기준이 문서화되어 있는가?

• 장기 키를 이미지나 Git 저장소에 넣지 않는가?

• 민감 데이터 접근, 모델 등록, 운영 배포 변경 이력이 남는가?

• ai-prod 또는 민감 데이터 네임스페이스에 기본 차단 NetworkPolicy가 있는가?

• 외부 API 호출 경로를 기록하고 제한할 수 있는가?

이 정도의 안전장치는 대규모 보안 조직이 없어도 시작할 수 있다. 중요한 것은 처음부터 완성된 보안 플랫폼을 만드는 것이 아니다. 권한, 이미지, Secret, 데이터 접근, 네트워크 경로를 운영 단위로 분리해두는 것이다. 이 경계가 있어야 플랫폼이 커질 때 정책을 강화할 수 있고, 문제가 생겼을 때 영향을 제한할 수 있다.

AI 플랫폼의 보안과 거버넌스는 속도를 늦추기 위한 절차가 아니다. 실험이 운영으로 넘어갈 수 있게 만드는 최소한의 신뢰 기반이다.

참고

¹Kubernetes Security

²Kubernetes Policies