명령을 어디까지 통제할지 직접 정하고, 세션이 어떤 계정으로 접속할지 승인 단계에서 확정하고, 자동화에는 별도의 자격 증명을 발급할 수 있습니다.
모든 서버가 같은 수준의 통제를 필요로 하지는 않습니다. 그만한 통제가 필요하지 않은 곳에서는 명령마다 승인을 기다리는 것 자체가 비용입니다.
이제 워크스페이스가 명령을 어디까지 통제할지 직접 정합니다. 모든 명령을 판단하고 기록하되 아무것도 막지 않는 상태로 둘 수도 있고, 쌓인 판단을 읽어보고 그것을 근거로 차단하는 쪽으로 넘어갈 수도 있습니다. 승인 요청에는 세션이 접속할 서버 계정도 함께 표시되며, 서비스 토큰은 승인을 기다리는 동안 미리 설정해 둘 수 있습니다.
모든 명령을 판단하되, 실행을 막을지는 직접 정합니다
Policies > Server access policies에 새로운 Execution control 카드가 추가되었습니다. 이 카드에서 AI 명령 검증과 명령 서명 검증이 워크스페이스의 명령 실행을 차단할지 정할 수 있습니다.
기본값은 Enforce입니다. 이 상태에서는 검증 결과에 따라 명령이 승인 대기 상태로 보류되거나 차단됩니다. CRITICAL로 판단된 명령은 다른 규칙에서 허용하더라도 항상 차단됩니다.
Advisory로 전환해도 모든 판단은 동일하게 이루어지며 감사 기록에도 남습니다. 다만 명령 실행을 멈추지는 않습니다. 모든 명령이 승인 없이 실행되며 차단되는 명령도 없습니다. Enforce로 전환하기 전에 팀이 실제로 사용하는 명령이 어떻게 판단되는지, 어떤 명령이 승인 대기 상태가 될지 미리 확인할 수 있습니다.
Advisory에서 달라지는 것은 명령 실행 제어뿐입니다. 로그인과 신원 확인, 역할과 권한, 토큰 인가, 세션 범위와 만료, 세션 녹화, 감사 기록, 자격 증명이 포함된 명령의 거부는 이전과 동일하게 작동합니다.
실행 제어 모드는 워크스페이스 superuser만 변경할 수 있습니다. exec-sudo gate를 monitor 모드로 운영하는 환경에서는 Advisory로 전환해도 sudo의 동작이 달라지지 않습니다.
어떤 계정으로 접속할지는 승인 단계에서 확정됩니다
서버에 접속하려면 해당 서버에서 사용할 계정을 정해야 합니다. 세션을 만들 때 'Connect as'에서 계정을 선택할 수 있으며, 기본값은 본인 계정입니다.
실제로 사용할 수 있는 계정만 선택할 수 있습니다. 나머지는 목록 아래에 사용할 수 없는 계정이 몇 개인지와 그 이유를 볼 수 있도록 나열됩니다. 다른 사용자에게 바인딩된 계정, application에 바인딩된 계정, 워크스페이스에서 직접 root 접속이 비활성화된 계정 등이 이에 해당합니다. 관리자가 해결할 수 있는 경우에는 rebind를 요청하라는 안내도 함께 표시되므로, 관리자에게 요청할지 다른 계정을 선택할지 바로 판단할 수 있습니다.
선택한 계정은 승인 요청에 함께 표시됩니다. 승인자는 세션이 어떤 계정으로 접속할지 확인한 뒤 그대로 승인하거나, 변경할 수 있는 다른 계정을 선택해 승인할 수 있습니다.
승인된 계정은 이후 과정에도 그대로 적용됩니다. Alpacon CLI 예시 명령, 콘솔의 Run 버튼, WebFTP 자동 연결이 모두 해당 계정을 사용합니다.
세션이 끝난 뒤에도 실행 계정 정보는 남습니다. 명령 상세 화면에서 각 명령이 어떤 계정으로 실행되었는지 확인할 수 있어, 승인된 내용과 실제 실행 결과를 나중에 대조할 수 있습니다.
자동화에 사람의 계정을 빌려주지 않아도 됩니다
서비스 토큰은 사람이 아닌 주체가 서버에 접근할 때 사용하는 자격 증명입니다. CI 파이프라인, 배포 스크립트, AI 에이전트 등이 이에 해당합니다. 사람 계정의 토큰을 공유하는 대신, 각 주체에 별도의 토큰을 직접 발급할 수 있습니다.
IAM > Applications에서 애플리케이션을 만든 뒤, 해당 애플리케이션에 토큰을 발급합니다. 각 토큰에는 수행할 수 있는 작업의 범위를 지정하며, 이 범위에 따라 위험도가 결정됩니다. 위험도가 높은 범위를 선택하면 토큰 발급에 관리자 승인이 필요할 수 있습니다.
발급된 토큰으로 Alpacon CLI에 로그인하면 별도의 사용자 로그인 없이 자동화를 실행할 수 있습니다.
이번 업데이트에서는 토큰이 발급되는 순서가 달라졌습니다. 이제 토큰은 요청 즉시 생성되고, 승인을 받으면 활성화됩니다. 승인 대기 중에도 키를 확인할 수 있어 CI 작업이나 에이전트 설정을 미리 마칠 수 있습니다. 단, 활성화되기 전에는 해당 키로 어떤 작업도 실행할 수 없습니다.
접근 규칙에 막힌 요청은 어떤 규칙에 막혔는지 담은 권한 오류를 돌려줍니다. Alpacon CLI가 이를 그대로 보여주므로, 연동이 잘못된 것인지 규칙이 제대로 동작한 것인지 구분됩니다.
애플리케이션에는 AI 에이전트 같은 서비스 유형이 함께 기록됩니다. Server access에서 각 서버에 쓸 계정을 서버당 하나씩 지정하므로, 에이전트가 여러 서버에 접근해도 어디서 어떤 계정으로 접속하는지 정해져 있습니다. Credentials에는 토큰이, Roles에는 권한이, Activity에는 실제로 실행한 작업이 담깁니다.
openSUSE와 SLES 서버도 콘솔에서 등록할 수 있습니다
서버를 등록하면 먼저 OS를 묻는데, 여기에 SUSE family가 추가되었습니다. Debian, RedHat, macOS, Windows와 나란히 놓이며 openSUSE Leap, openSUSE Tumbleweed, SLES를 다룹니다. 다른 항목과 마찬가지로 설치 명령을 돌려줍니다.
그 밖의 변경 사항
- 승인 권한이 있다면 워크스페이스 superuser가 아니어도 승인 콘솔을 열 수 있습니다.
- 에이전트가 목적을 선언해야 보류된 명령이 승인 대기열에 등록됩니다.
- 승인자가 여러 명인 경우 각 승인자의 결정이 기록되어 함께 반영됩니다. 요청에 대한 결정이 내려지면 나머지 승인자에게 보낸 알림도 정리됩니다.
- 명령 및 파일 ACL 관리 권한은 토큰 바인딩 권한을 기준으로 결정됩니다.
- 사용자가 이미 보고 있는 세션에서는 승인 요청이 화면 위 알림으로 쌓이지 않고 세션 안에 바로 표시됩니다.
- 이미 결정된 승인 요청의 링크를 열면 빈 목록이 아니라 해당 요청으로 이동합니다.
- 계정을 삭제할 수 없는 경우 삭제를 막고 있는 항목을 안내합니다.
- Websh에서 Ctrl+Shift+C와 Ctrl+Shift+V가 동작합니다.
alpacon note ls가--tail과--server를 올바르게 처리하며, 노트의 고정 여부와 등록 시각도 함께 표시합니다.- 잘못 설정된 자체 호스팅 AI 커넥터는 사용자의 첫 로그인 시점이 아니라 시작 단계에서 오류를 표시합니다.
- 보안 개선 사항이 포함되었습니다. 자체 호스팅 환경을 사용하는 고객에게 업데이트를 권장합니다.
동작 변경 사항
선언된 목적에서 벗어난 sudo 명령의 종료 코드가 1에서 4로 변경됩니다. 해당 명령은 실패가 아니라 승인 대기 상태로 분류됩니다. --wait를 사용하면 즉시 실패하지 않고 승인자가 결정할 때까지 최대 5분 동안 기다립니다. 종료 코드를 기준으로 분기하는 스크립트는 수정이 필요합니다.
허용 도메인 설정과 도메인 기반 가입 기능이 제거되었습니다. 이제 등록된 도메인의 이메일 주소를 사용하더라도 워크스페이스에 자동으로 참여하지 않습니다. 기존에 이 방식을 사용했다면 초대 방식으로 전환해야 합니다.
