AI에게 cluster-admin을 줬나요? 운영 Kubernetes를 지키는 7개의 안전장치

9월 16, 2026

어두운 공간에서 AI 코딩 에이전트로 운영 작업을 수행하는 개발자 — AI가 위험한 것이 아니다. 검증되지 않은 판단에 운영 권한을 함께 준 구조가 위험하다. Photo: Makeen M.Alaa / Unsplash

“배포가 안 돼. 알아서 고쳐줘.” 이 한 문장을 받은 AI 코딩 에이전트가 운영 클러스터의 cluster-admin 권한까지 가지고 있다면, 문제 해결과 장애 확산의 경계는 명령 한 줄보다 얇습니다.

에이전트는 로그를 읽고 원인을 추론하고 명령을 실행합니다. 생산성을 폭발시키는 바로 그 능력이 운영 Kubernetes에서는 위험 반경을 폭발시킵니다. 잘못된 추론, 저장소 문서에 섞인 악성 지시, 과도한 자동 복구가 kubectl delete, 잘못된 이미지 배포, Secret 노출로 이어질 수 있기 때문입니다.

AI에게 운영 kubeconfig를 넘겼다면, 안전장치는 프롬프트가 아니다 “삭제하지 마”, “운영에서는 조심해” 같은 문장은 권한 통제가 아닙니다. 실수를 해도 실행되지 않도록 RBAC, GitOps, 승인, 정책 엔진과 감사 로그가 시스템 수준에서 막아야 합니다.

가장 위험한 착각: “읽기 전용이면 괜찮겠지”

Kubernetes에서 권한 이름과 실제 영향은 다를 수 있습니다. 공식 RBAC 가이드에 따르면 Secret의 list와 watch도 값 전체를 노출할 수 있습니다. Pod 생성 권한은 같은 네임스페이스의 Secret을 마운트하거나 ServiceAccount 권한을 빌려 쓸 수 있어 사실상 더 큰 권한으로 이어질 수 있습니다. 심지어 nodes/proxy의 get은 Kubelet API를 통한 명령 실행으로 이어질 수 있습니다.

겉보기 권한	실제 위험	기본 대응
`list/watch secrets`	네임스페이스 비밀값 일괄 노출	에이전트 역할에서 제외
`create pods`	Secret·볼륨·ServiceAccount 우회 접근	직접 생성 금지, GitOps로만 변경
`get nodes/proxy`	Kubelet 경유 실행·접근 가능성	명시적 차단
`*` 리소스·동사	미래에 추가될 CRD까지 자동 허용	리소스와 동사를 열거

AI 에이전트의 운영 접근을 멈추는 비상 정지 버튼 — 운영 자동화에는 시작 버튼보다 확실한 정지 버튼이 먼저 필요하다. Photo: Serge S / Unsplash

운영 클러스터를 지키는 7개의 안전장치

1. 에이전트에서 운영 kubeconfig를 제거한다

가장 강력한 통제는 “조심해서 사용”이 아니라 “애초에 보유하지 않음”입니다. 개발 에이전트가 운영 API 서버에 직접 닿지 못하게 네트워크와 자격 증명을 분리하세요. 운영 변경은 Git 브랜치와 Pull Request를 통과하게 합니다.

2. 진단 계정은 네임스페이스 단위로 최소화한다

직접 조회가 꼭 필요하다면 전용 ServiceAccount와 Role을 만드세요. 아래 예제는 Pod 상태·이벤트·로그만 읽습니다. Secret, pods/exec, workload 생성, 클러스터 범위 리소스는 포함하지 않습니다. 단, 애플리케이션이 비밀값을 로그에 남기면 로그 조회도 민감 권한이 되므로 별도 점검이 필요합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ai-diagnostics
  namespace: my-service
rules:
  - apiGroups: [""]
    resources: ["pods", "events"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get"]

3. 변경은 GitOps가 실행하고, AI는 PR만 만든다

권한의 경계를 명확히 나누세요. AI는 YAML을 수정하고 테스트 결과와 영향 범위를 PR에 작성합니다. 리뷰어가 승인한 커밋만 Argo CD가 동기화합니다. 그러면 누가 어떤 의도로 무엇을 바꿨는지 Git 기록이 남고, 에이전트가 API 서버에 직접 명령할 이유가 사라집니다.

AI 분석·코드 변경 → Pull Request → 테스트·정책 검사 → 사람 승인 → Argo CD 동기화 → Kubernetes

4. 운영 배포에는 승인과 시간 창을 건다

개발 환경 자동화와 운영 자동화를 동일하게 취급하지 마세요. Argo CD Sync Window로 운영 배포 가능 시간을 제한하고, 운영은 수동 승인 또는 별도 역할을 요구하도록 구성합니다. 장애 대응용 예외 절차도 사전에 문서화해야 급한 순간에 cluster-admin을 공유하는 일을 막을 수 있습니다.

5. 자격 증명은 짧게, 작업마다 새로 발급한다

장기간 유효한 kubeconfig와 정적 토큰은 유출 후에도 공격자가 계속 사용할 수 있습니다. 작업 단위의 단기 토큰, 제한된 audience, 만료 시간, 즉시 폐기 가능한 별도 ServiceAccount를 사용하세요. 에이전트 실행 환경에 사용자의 관리자 kubeconfig를 마운트하지 않는 것이 핵심입니다.

6. 허용된 요청도 정책 엔진으로 다시 막는다

RBAC는 “어떤 API를 호출할 수 있는가”를 통제하지만 안전한 Pod 사양까지 보장하지는 않습니다. Pod Security Standards의 Restricted 정책이나 Kyverno·Gatekeeper 같은 Admission 정책으로 privileged 컨테이너, hostPath, hostNetwork, 무제한 리소스, 승인되지 않은 이미지 레지스트리를 차단하세요.

7. 모든 행동을 기록하고 즉시 끊을 수 있게 한다

Kubernetes Audit Log에는 누가, 언제, 어떤 리소스에 어떤 동작을 했는지 남길 수 있습니다. 에이전트 전용 identity를 사용하면 사람의 작업과 구분할 수 있습니다. 이상 징후가 보이면 토큰 폐기, RoleBinding 제거, 네트워크 차단을 한 번에 실행하는 킬 스위치도 준비하세요.

AI 자동화 뒤에서 실제 운영 트래픽을 처리하는 서버 인프라 — 프롬프트 뒤에는 실제 고객 트래픽과 데이터가 있는 서버가 작동한다. Photo: Eric Stoynov / Unsplash

우리 팀은 어디까지 자동화해도 될까?

단계	AI가 할 수 있는 일	필수 통제
관찰	상태·이벤트·정제된 로그 분석	전용 읽기 계정, Secret·exec 제외
제안	패치·매니페스트·롤백안 생성	Git PR, 테스트, 정책 검사
비운영 실행	개발 네임스페이스 배포·검증	격리 클러스터, 쿼터, 자동 만료
운영 실행	승인된 변경의 제한적 동기화	사람 승인, Sync Window, 감사·킬 스위치

오늘 바로 확인할 한 가지 AI 에이전트가 실행되는 서버에서 kubectl auth can-i --list를 확인하세요. 결과에 *, Secrets 조회, Pod 생성·exec, RBAC 변경이 보인다면 생산성 개선보다 권한 축소가 먼저입니다.

마무리: AI의 판단 속도보다 권한의 브레이크가 빨라야 한다

AI 에이전트는 운영자의 의도를 완벽히 이해하는 동료가 아니라, 주어진 정보와 권한 안에서 다음 행동을 선택하는 자동화 시스템입니다. 그래서 안전성은 모델이 얼마나 똑똑한지가 아니라 잘못 선택해도 피해가 제한되는 구조에서 나옵니다.

운영 kubeconfig를 넘기는 순간 AI는 도우미가 아니라 운영자가 됩니다. 그런데 그 운영자에게는 아직 호출할 전화번호도, 피로도도, 망설임도 없습니다.

참고 문서: Kubernetes RBAC Good Practices · Kubernetes Auditing · Argo CD Sync Windows · OWASP Excessive Agency

이 블로그 검색

디에스 DevOps Lab