"RBAC만 사용하세요"는 절반만 맞습니다. AI 에이전트를 위한 나머지 절반을 소개합니다.

저는 AI 코딩 에이전트의 쉘 명령이 실행되기 전에 작동하여 정책에서 금지하는 명령을 차단하는 오픈 소스 검사 도구인 Aegis-DevOps를 유지 관리하고 있습니다. 지난 2주 동안 같은 반론을 두 번 들었습니다. Reddit 스레드에서는 RBAC가 이미 이 기능을 수행한다고 말했습니다. 한 유지 관리자는 에이전트 하네스에 '이미 도구 사용 제어 기능이 내장되어 있다'는 이유로 플러그인 제출을 거부했습니다.

둘 다 절반만 맞습니다. RBAC를 갖추어야 하고, 에이전트의 권한 설정도 사용해야 합니다. 하지만 어느 쪽도 다음 질문에 답하지 못합니다. 에이전트가 kubectl delete를 실행하려 할 때, 이 에이전트가 지금 당장 이 작업을 수행해도 되는가?

면책 조항: 본 기사는 AI 어시스턴트의 도움을 받아 작성하고 제가 직접 검토했습니다. 아래 명령 결과는 aegis-devops 0.3.2를 예시 정책에 대해 실행한 것입니다.

에이전트 권한 설정은 텍스트와 일치합니다

Claude Code의 권한 규칙은 좋은 예이며, 그 문서도 이에 대해 이례적으로 솔직합니다. Bash 규칙은 모델이 작성하는 명령 텍스트와 일치합니다. 문서는 거부(deny) 규칙이 '프로그램을 둘러싼 보안 경계가 아니다'라고 말하며 다음과 같은 예를 제시합니다: Bash(git push *)는 git push origin main을 막지만, git -C . push origin main은 막지 못합니다. 명령 실행 전에 전체 명령을 검사하려면 PreToolUse 훅을 사용하도록 안내하고 있습니다.

이것은 권한 설정의 목적에 적합합니다: 사용자에게 물어보지 않고 에이전트가 무엇을 실행할 수 있는지 결정하는 것입니다. 이것은 정책 엔진이 아니며, 아무도 그렇게 주장하지 않습니다.

하지만 훅(hook)은 명령이 무엇을 하는지 파악할 수 있기 때문에 더 많은 것을 할 수 있습니다. 이 모든 것은 Aegis의 동일한 규칙(

RBAC과 IAM은 특정 신원(identity)이 무엇을 할 수 있는지 결정합니다. 노트북에 있는 코딩 에이전트는 보통 개발자 자신의 kubeconfig와 클라우드 자격 증명으로 실행됩니다. API 서버의 관점에서 볼 때, 이 에이전트는 개발자 그 자체이며, 개발자가 가진 모든 권한을 갖게 됩니다.

이것은 에이전트에게 고유한 신원을 부여함으로써 해결할 수 있으며, 그렇게 해야 합니다. 하지만 설령 그렇다 하더라도, RBAC은 정적인(static) 권한 부여 방식입니다. "이 서비스 계정은 프로덕션 환경에서 배포를 삭제할 수 있다"라고 말할 수는 있지만, "인간의 승인이 있고 릴리스 동결 기간이 아닐 때만 이 에이전트는 삭제할 수 없다"라는 규칙을 설정할 수는 없으며, 그 규칙이 어디서 왔는지 전혀 알지 못합니다.

바로 이 마지막 부분이 제가 Aegis를 구축한 이유입니다. 에이전트의 세계에서는 "규칙"이 Jira 티켓이나 에이전트가 읽도록 요청받은 Slack 메시지 내부에서 도착할 수 있습니다. 따라서 Aegis 규칙은 아무도 그것을 변경하지 않았고, 그 작성자가 그러한 종류의 규칙을 작성할 권한이 있었을 때만 투표를 얻습니다. 티켓에 심어진 한 줄은 어떤 투표도 얻지 못합니다.

세 가지 모두 사용하기

"왜 RBAC을 쓰지 않느냐?"라는 질문에 대한 솔직한 대답은 "예, 그리고(yes, and):"입니다.

• RBAC / IAM: 모든 신원이 할 수 있는 일에 대한 하드 상한선(hard ceiling)입니다. 이를 엄격하게 유지해야 합니다.
• 에이전트 권한 설정: 에이전트가 사용자에게 묻지 않고 실행할 수 있는 범위입니다.
• 사전 실행 정책 검사(pre-execution policy check): 이 특정 행동이 발생해야 하는지에 대한, 신뢰할 수 있는 규칙 기반의 확인 절차입니다.

정책 검사는 노트북에 머무를 필요가 없습니다. 에이전트들이 자체적인 신원을 갖게 되면, Aegis는 동일한 정책을 플랫폼 계층으로 컴파일합니다. aegis compile aws는 Service Control Policies를 작성하고, aegis compile kubernetes는 ValidatingAdmissionPolicies를 작성합니다. 이는 boto3 스크립트처럼 훅(hook)을 거치지 않는 호출까지 포괄합니다. 둘 다 프리뷰 버전이며, 저는 AWS 부분이 어떻게 작동하는지에 대해 정리했습니다.

아직 수행하지 않는 것들

독자들은 계속해서 실제적인 허점을 발견하고 있고, 이것이 이 게시물을 작성하는 목적입니다. 이번 주에는 네임스페이스 범위의 규칙(namespace-scoped rule)이 현재 kube 컨텍스트에서 네임스페이스에 의존하는 명령어를 일치시키지 못한다는 점과, 파이프된 매니페스트는 절대 읽히지 않기 때문에 kubectl apply -f -가 허용된다는 점을 발견했습니다. 두 문제 모두 수정되고 있습니다. Aegis는 알파 버전입니다. 저장소의 열린 허점들을 먼저 읽어보지 않고 중요한 곳에 사용하지 마십시오.

직접 사용해 보기

pip install aegis-devops && aegis init .aegis

# Claude Code
...

만약 여러분의 환경 설정에 RBAC 답변만으로 충분하다고 생각하신다면, 그 이유를 듣고 싶습니다. 이슈는 github.com/moneytool/aegis-devops에서 열려 있습니다.