AI 측의 가드레일(Guardrail)이나, Proxmox 측의 권한 설정 및 접속원 제어 등을 하는 것이 권장됩니다.
이 내용은 기사 작성 시점(PVE9.2)을 기준으로 합니다.
요즘은 Codex나 Claude Code 등을 사용하여 Proxmox 4 계열 또는 PVE 상의 게스트 OS에 대한 오퍼레이션을 수행하는 사람들도 많다고 생각합니다.
최근 저 역시 그렇게 구축하고 운영하고 있습니다.
평가용 4계열 + 다수 PVE 클러스터 + 연동되는 Zabbix나 Ansible 유지보수가 힘들잖아요
여러 가지 방법이 있을 것이라 생각하여, 일단 정리해 보고 소감을 메모해 두겠습니다.
호스트 관리자 입장에서의 코멘트입니다.
참고로 상세한 절차는 작성하지 않겠습니다.
AI에게 조사하도록 하는 편이 확실하다고 생각하며~~ 무엇보다 저 자신도 AI에 맡기고 있기 때문에 (커맨드 레벨에서 파악하고) 완전히 이해하고 있지는 않습니다.~~
아래와 같은 것들을 검토했습니다.
| 방법 | AI에게 전달할 내용 | 도달 범위 | 장점 | 단점 | 소감 |
|---|
| SSH (ID・비밀번호) | root의 비밀번호 | 호스트 전체 (같은 비밀번호로 GUI 및 API 모두 접근 가능) | 준비물이 필요 없음 | 비밀번호가 커맨드라인이나 대화 기록에 남음 | 논외 |
| ... | | | | | |
| 호스트를 관리하려면 실질적으로 SSH가 전제되어야 한다고 생각합니다. | | | | | |
GUI나 API로는 할 수 없는 것들이 여러 가지 있기 때문입니다.
또한 root로 접속하지 않고 sudoers를 사용한 제어 등도 있을 것이라 생각합니다.
AI에게 ID와 비밀번호를 전달하는 것은 보안적으로 논외라고 생각합니다.
단말기에 저장된 비밀키(Secret Key)를 사용하여 접속합니다.
단말기 자체에 보안 사고가 없는 한, 기본적으로는 괜찮다고 인식하고 있습니다.
더욱 안전한 방법으로는 YubiKey와 같은 물리 키를 사용하는 방안도 있을 것이라 생각합니다.
검토했지만, 원격 단말기를 통해 관리하는 클러스터가 있었을 경우 사용하기 어렵고, 무엇보다 물리 키 관리에 자신이 없었기 때문에 시도해 보지 못했습니다.
또한 비용적인 면에서도 부담이 됩니다.
다만 개인적으로는 Proxmox에 한정하지 않고, 좀 더 중요한 계정 보호(예: Google 계정 등)에 사용해 볼까 아직 고민하고 있습니다.
앞서 말씀드린 것처럼 API로는 할 수 없는 조작들이 있으므로, 호스트 관리자용이라기보다는 VM의 관리자나 사용자에게 적합한 제어/조작 방법이라고 생각합니다.
AI에게 비밀번호를 전달하게 되므로, SSH ID와 비밀번호가 가진 문제점이 있습니다.
API라면 API 토큰을 사용하는 것이 보안 면이나 운영 면에서 장점이 크기 때문에, 굳이 이것을 선택할 필요는 없을 것 같습니다.
가드레일의 관점에서는 아래와 같은 것을 할 수 있다는 점이 큰 장점입니다.
- 권한 분리 (Privilege Separation): 새로 만드는 토큰의 기본 권한은 사용자 권한과 토큰 권한이 겹치는 부분만으로 제한됨 - 만료 기간 (Expire): 기한을 넘기면 사용할 수 없게 됨 - 폐기: 토큰이 유출되어도 사용자를 막지 않고 토큰만 제거할 수 있음
- 비밀 정보 재설정: PVE9.2부터 토큰의 비밀 정보를 다시 만들 수 있습니다 (--regenerate)
MCP에 대해서는 GitHub에서 Proxmox용 MCP 서버가 몇 개 공개되어 있습니다.
예를 들어 다음과 같습니다.
개인의 프로젝트를 사용하는 것이 꺼려지기 때문에 (보안 문제나 리셀러로서 사용자에게 제안할 수 있는지 등), MCP가 필요하게 되면 Claude Code나 Codex를 사용해서 직접 만들 것 같습니다.
애초에, MCP를 거쳐 API를 호출해야 하는 상황은 호스트 관리자 관점에서는 떠오르지 않았습니다.
PVE의 권한이 부족해서 MCP 서버 측에서 구현하는 경우라든지, 환경 제약이 있는 경우일까요?
Ansible은 호스트 단독이라기보다는 여러 호스트・VM・그 위의 게스트 OS・애플리케이션을 구축할 때 유용하다고 생각합니다.
재현성이나 공집합성(Idempotency)의 관점도 그렇고, AI 토큰 소비 (사용료)라는 비용적인 관점에서도 Ansible 같은 구성 관리 도구가 더 유리하다고 생각합니다.
다만 저 역시 실제로 그 부분을 'Ansible vs AI'와 같은 형태로 평가한 것은 아니라는 점을 덧붙입니다.
혹시 AI 측에 스킬이나 가드레일을 제대로 전달해 준다면, Ansible와 동등하거나 그 이상의 것을 할 수도 있을지 모릅니다.
또한, Ansible의 playbook 등을 AI에게 작성하도록 하는 것도 조합 기술로서 유효하다고 생각합니다.
다른 조작 방법으로는 Claude나 Codex의 브라우저 확장 기능을 사용하여 브라우저를 통해 사용하는 것도 있습니다.
이 방식의 장점은 다음과 같습니다:
- 사람이 GUI에 로그인한 세션을 사용하므로, TOTP와 같은 2단계 인증(Two-Factor Authentication)을 설정해 두었더라도 사용할 수 있습니다.
- GUI 조작이 가능하여 스크린샷을 찍거나 할 수 있습니다.
- 환경상의 이유로 다른 인증이 필요하거나, 직접 SSH나 API를 호출할 수 없는 경우에 사용할 수 있습니다.
다만, GUI에서도 root로 로그인했다면 셸(shell)을 조작할 수 있으니 주의해야 합니다.
원래 사용하고 있는 환경이 폐쇄적인(closed) 환경이기 때문에, root에게 SSH 연결을 하고 있습니다. 물론 개인 키(private key)를 사용하여 연결합니다.
또한, 연결 출처 IP는 만약을 대비하여 제한하고 있습니다.
AI의 가드레일(harness)로는, 우선 가장 처음에 허가한 조작 외에는 수행하지 않도록 가드레일을 걸었습니다.
실제로 운영하면서, 항상 허가할 조작과 그때마다 승인을 요청하는 조작을 지정하고, 그 외의 것은 수행하지 않도록 지정했습니다.
게스트 OS 위에 여러 가지를 만들고 싶었기 때문에, Ansible로 할 수 있는 것은 전부 Ansible로 처리하고, VM 템플릿을 사용하여 복제하거나, 백업(backup) 및 스냅샷(snapshot)을 사용하여 특정 시점으로 되돌릴 수 있는 지시도 내리고 있습니다.
PVE를 제외한 4개의 형제(sibling)들도 스케줄링하여 자동 업데이트 및 자동 테스트 등을 진행하고 있습니다.
기술의 발전 덕분에, 감사의 정권 펀치 Proxmox의 유지보수 시간이 대폭 줄었습니다. 덕분에 기도하는 시간 다른 평가를 할 시간이 늘어나서 기쁩니다.
Zabbix 8 RC1과 PVE의 OpenTelemetry 평가도 했기 때문에, 다음번에 작성하려고 합니다.
