접근 제어는 이 아이덴티티가 이 자원에 접근해도 되는지를 확인합니다. 실행 제어가 묻는 것은 이 명령어가 세션의 선언된 목적에 맞는지입니다. 클러스터 앞의 점프 호스트는 첫 번째 질문에만 답합니다. Teleport는 exec 동작을 통제하고, 다른 도구는 명령어 문자열을 미리 작성한 목록과 대조합니다. 그래도 고정된 패턴만으로는 세션이 선언한 목적을 표현할 수 없습니다.
점프 호스트는 클러스터 접속만 인증합니다. 접속한 뒤 실행되는 kubectl exec 명령어에 대해서는 아무런 판단을 하지 않습니다. 사람이 직접 입력했든, 에이전트나 자동화 작업이 같은 API를 호출해 실행했든 마찬가지입니다.
이 차이는 눈에 잘 띄지 않습니다. 모든 접속을 강화된 베스천 한 곳으로 모으면 노트북에서 kubectl로 클러스터에 직접 접속하는 것보다 안전해 보이기 때문입니다. 그러나 점프 호스트가 확인하는 것은 누가 서버에 접속하는지입니다. 접속 후 무엇을 실행하는지는 별도로 판단하지 않습니다.
부여받은 권한이 아니라 물려받는 권한
허쉬버그가 설명하는 구성에서는 점프 호스트에 들어가는 순간 kubeconfig가 이미 로드된 셸이 주어집니다. ARMO의 CTO 벤 허쉬버그가 2023년 점프 호스트 위험을 다룬 글에서 밝혔듯, 이 kubeconfig에는 "십중팔구 클러스터 관리 권한(cluster administration privileges)"이 붙어 있습니다. 이 방식은 편리합니다. 베스천을 거칠 때마다 클러스터에 다시 인증하고 싶은 사람은 없기 때문입니다.
동시에 이 편리함이 위험이기도 합니다. 서버가 이렇게 구성돼 있으면 SSH 세션을 장악한 쪽이 클러스터까지 장악하게 됩니다. 자격증명이 피싱으로 넘어가거나 세션이 하이재킹되면, 공격자는 그 kubeconfig에 묶여 있던 권한을 그대로 손에 넣습니다. 그 범위는 대개 넓게 잡혀 있습니다. RBAC은 요청마다 여전히 평가됩니다. 그 셸이 클러스터 관리자 권한을 지니고 있다면 RBAC이 더 이상 제한할 것이 남아 있지 않을 뿐입니다.
이 공백은 공격자에게만 유리한 것이 아닙니다. kubeconfig를 프로덕션으로 바꿔 둔 걸 깜빡한 채 실행한 kubectl delete나 kubectl apply도 명령어 단위의 판단이 없으면 입력한 그대로 실행됩니다. 셸 계층에서는 어느 클러스터를 의도했는지 묻지 않고, 점프 호스트는 로그인이 끝난 순간 이미 제 역할을 마칩니다. 탈취된 자격증명과 컨텍스트를 실수로 프로덕션에 둔 채 친 명령은 실패 유형이 다릅니다. 하지만 셸과 API 서버 사이에서 이 명령어가 여기 있어도 되는지 판단하지 않는다는 점은 같습니다.
허쉬버그는 더 어려운 문제도 지적합니다. 점프 호스트의 SSH 인증을 우회하려면, 적절히 인증된 상태로 직접 노출된 쿠버네티스 API 엔드포인트를 우회할 때와 같은 수준의 암호화를 깨야 합니다. 베스천을 둔다고 문턱이 크게 높아지는 것은 아닙니다. 경유 지점 하나와 별도로 관리할 구성 하나가 늘어날 뿐입니다.
동작 통제와 명령어 판단은 다릅니다
예를 들어 Teleport는 exec라는 동작 자체를 통제합니다. 특정 파드나 네임스페이스에 셸을 열 수 있는지 여부까지만 보고 거기서 멈춥니다. 다른 도구들은 한 걸음 더 나아가 명령어 문자열 자체를 실행 전에 고정된 허용·차단 목록과 대조합니다. 어느 쪽이든 미리 작성해 둔 패턴이 결과를 정합니다. 이 세션에서 이 명령어를 두고 내린 판단은 아닙니다.
kubectl exec payments-pod -- psql -c 'select * from customers'는 실패한 쿼리를 디버깅하려고 연 세션에서든, 테이블을 통째로 빼내려고 연 세션에서든 같은 문자열입니다. 고정 목록은 두 경우 모두 같은 명령어로 볼 뿐, 세션이 선언한 목적이 만드는 차이는 담아내지 못합니다.
접근 제어와 실행 제어의 구분은 인프라 보안의 다른 영역에서도 반복됩니다. 접근 제어는 "이 아이덴티티가 이 자원에 접근해도 되는가"를 묻습니다. 실행 제어는 "이 세션의 목적을 고려할 때 이 명령어를 실행해도 되는가"를 묻습니다. exec 동작을 제한하거나 고정된 명령어 목록과 대조하는 방식은 접근 제어를 더 세분화한 것입니다. 어느 방식도 두 번째 질문을 하도록 설계된 것은 아닙니다.
AlpacaX의 Alpacon이 제안하는 방법
남는 방법은 이미 접근 권한을 가진 사용자나 에이전트가 실제로 쓰는 명령어를 한 번 더 점검하는 것입니다. 하지만 명령 API나 MCP처럼 AI가 명령을 대신 실행하는 경로에서는 사람이 매번 다시 판단하는 방식이 병목이 됩니다. 위험을 먼저 진단하고 방향을 제시하는 역할은 AI가 맡아야 합니다.
Alpacon의 실행 경로(command API, MCP, 에이전트의 execute 호출)로 들어온 kubectl exec는 내부 명령어까지 포함해 전체를 판단합니다. 먼저 규칙을 적용하고, 기존 행동 패턴과 비교한 뒤, 마지막으로 LLM이 의도를 읽습니다. 이 경로의 다른 명령어도 같은 기준으로 평가합니다. 위험도 평가에서 회색 지대에 놓인 명령어는 실행 전에 사람의 별도 승인을 기다리도록 보류할 수 있습니다.
점프 호스트가 접속 이후의 명령어를 판단하지 않는 문제에는 이처럼 실행 경로에서 명령어를 평가하는 방식으로 대응할 수 있습니다.
중요한 것은 어느 벤더의 장비를 거쳐 SSH로 접속하느냐가 아닙니다. 클러스터에 도달하는 kubectl exec 명령 가운데 에이전트가 발행하는 비중이 커질수록 이 차이는 더 커집니다. 명령어 자체를 평가하지 않으면 접근 제어만으로 필요한 통제를 제공하기 어렵습니다.
FAQ
kubectl exec 동작만 통제하면 이 문제가 해결되나요? 부분적으로만 해결됩니다. Teleport의 exec 동작 통제처럼 동작 단위로 제한하는 방식은 특정 파드에 셸을 열 수 있는지 여부까지만 판단합니다. 이 역시 접근 제어를 더 세분화한 것일 뿐, 셸을 연 뒤 실행되는 명령어 자체는 판단하지 않습니다.
고정된 명령어 허용 목록으로 이 문제를 해결할 수 있나요?
아닙니다. 미리 작성해 둔 고정 패턴은 세션의 목적과 관계없이 같은 명령어 문자열에 항상 같은 판정을 내립니다. kubectl exec payments-pod -- psql -c 'select * from customers'는 실패한 쿼리를 디버깅하려는 세션에서든 테이블을 통째로 빼내려는 세션에서든 동일하게 읽힙니다.
