서비스 토큰으로 명령어 허용
자동화 작업을 실행하기 전에 토큰의 허용 명령어를 설정하세요. 정확한 매칭 조건과 거부 코드는 토큰 명령어 매칭을 참고하세요.
실행하는 그대로 규칙을 작성하세요
규칙은 root 권한으로 실행되는 명령어가 아니라 제출한 명령줄과 비교하므로, 관리자 권한이 필요한
명령어의 규칙에는 sudo가 있어야 합니다.
| 실행하는 명령어 | 허용하는 규칙 | 허용하지 않는 규칙 |
|---|---|---|
sudo systemctl restart nginx | sudo systemctl restart nginx | systemctl restart nginx |
sudo -n systemctl restart nginx | sudo -n systemctl restart nginx | sudo systemctl restart nginx |
sudo docker ps | sudo docker * | docker * |
sudo X와 sudo -n X는 서로 다른 명령줄이므로 각각 별도의 규칙이 필요합니다. 파이프라인이 실제로
실행하는 명령줄을 등록하세요. 작업에서 대화형 입력 없이 실행하려고 -n을 추가하거나 다른 계정으로
실행하려고 -u를 추가한다면, 그 플래그도 비교 대상에 포함됩니다.
sudo 와일드카드가 위험한 이유
sudo * 규칙을 허용하면 root 권한으로 모든 명령을 실행할 수 있습니다. 와일드카드는 따옴표로 묶인
부분까지 일치하므로 sudo bash -c "rm -rf /"도 허용됩니다. sudo bash -c *와 sudo sh -c *도 같은
결과를 낳습니다.
대신 권한이 필요한 명령을 정확히 지정하세요.
sudo systemctl restart nginx
sudo systemctl reload nginx토큰이 sudo를 실행하면
허용 명령 규칙을 통과하면 명령이 서버에 전달될 뿐입니다. 권한 상승 여부는 서버에서 sudo가 실행되는
순간 다시 결정됩니다.
Alpacon Cloud의 서비스 토큰. 워크스페이스 sudo 설정이 꺼져 있으면 workspace_sudo_with_mfa_disabled로 거부됩니다. 설정이 켜져 있고 Advisory이면 위험도를 이유로 거부하지 않고 판단을 기록합니다. Advisory가 아닐 때 명령이 허용 명령 규칙을 통과하면 평가된 위험 수준에 따라 권한 상승 여부가 자동으로
결정됩니다. 심각보다 낮은 모든 수준에서는 허용되고 심각 수준에서는 SUDO_RISK_DENIED로
거부됩니다. AI 검증에서 명령이 거부된 경우에는 전체 위험 수준과 거부 당시의 위험 수준 중 더 높은
수준을 적용합니다. 따라서 전체 위험 수준이 더 낮게 표시되어도 심각 수준에서 거부된 명령의 권한
상승은 거부됩니다. 위험을 평가할 수 없었던 명령도 허용하므로 위험 평가에 장애가 생겨도 파이프라인이
멈추지 않습니다. 파이프라인은 사람 없이 실행되므로 승인 요청에 답할 검토자를 기다리지 않습니다. Advisory 판단을 포함한 자동 권한 상승은 토큰을 소유한 애플리케이션 이름으로
Privilege elevation에 기록됩니다.
사람이 승인한 명령. 작업 세션에 연결된 서비스 토큰 명령은 사람의 승인을 받을 때까지 보류될 수
있습니다(아래 참고). 사람이 보류된
명령을 승인하면 승인한 명령줄에 적힌 sudo까지 승인한 것으로 봅니다. 심각을 포함한 모든 위험
수준에서 권한 상승이 허용되며, 그 결정과 연결된 허용 기록이 Privilege elevation에 관리자 승인으로
남습니다. 워크스페이스에서 작성한 승인 정책이 명령을 거부하거나 승인자를 2명 이상 요구하는 경우에만
그 정책이 계속 적용됩니다.
sudo 정책은 서비스 토큰에 적용되지 않습니다. sudo 정책은 Alpacon 사용자를 대상으로 하며 서비스 토큰은 사용자가 아닙니다. 정책을 작성해도 위 결과는 바뀌지 않습니다.
Advisory가 아니면 관리자가 기준을 더 엄격하게 정할 수 있습니다. 워크스페이스의 token_exec 규칙으로 권한 상승과 아래의
AI가 거부한 명령을 심각보다 낮은 위험
수준부터 거부하도록 정할 수 있습니다. 둘 다 같은 정책을 읽기 때문입니다. 다만 토큰이 사람인 검토자를
기다리도록 만들 수는 없습니다.
부여할 sudo 권한은 없습니다. 토큰 범위 목록에는 sudo 작업을 제공하는 리소스가 없습니다. 따라서
애플리케이션의 역할이나 토큰 범위에서 권한 상승을 켜는 방식이 아닙니다. 허용 명령 항목과 명령의
평가된 위험 수준이 권한 상승 여부를 결정합니다.
API 액세스 토큰은 다릅니다. 개인 API 액세스 토큰은 단독으로 권한을 높일 수 없습니다. sudo 범위가 포함되고 sudo 정책이 적용되는 작업 세션 개요에서 명령을 실행하거나, 작업을 서비스 토큰으로 옮기세요.
자체 호스팅 배포에서는 서비스 토큰의 sudo 명령어가 누구의 작업인지 확인할 수 없어
SUDO_COMMAND_NOT_AUTHORIZED로 거부합니다. 로그인한 사람이 권한을 받아 명령어를 다시 실행하거나,
명령어와 일치하는 sudo 정책이 있는 작업 세션에서 다시 실행하세요.
토큰 명령이 AI 판정에서 거부되면
모든 명령은 실행 전에 Alpacon의 AI 위험도 검증을 거칩니다. 사람이 보냈거나 작업 세션 개요에서 보낸 명령이 거부되면, 보통 사람이 실행을 승인할 수 있도록 보류됩니다. 자세한 내용은 Commands의 검증 상태를 참고하세요.
작업 세션 없이 보낸 서비스 토큰 명령은 보류되지 않습니다. CI 작업 등 사람이 지켜보지 않는 자동화에서는 보류된 명령에 응답할 사람이 없기 때문입니다. 이런 명령이 AI 검증에서 거부되면, 판정이 나오는 즉시 워크스페이스의 토큰 실행 정책에 따라 처리됩니다.
- 심각 위험도이거나 정책에서 거부하는 위험도이면 명령을 거부하고 결과를 Command rejected by AI verification로 기록함. 이어서 실행하도록 연결된 명령도 모두 취소하고 각각의 결과를 Cancelled: prior command rejected로 기록함
- 거부 기준보다 위험도가 낮으면 명령어를 그대로 실행함. 검증에서 반려됐지만 세션 없는 서비스 토큰으로 실행됨 표시와 함께 거부 판정 및 위험도를 기록함. 서명 모니터 모드에서 실행된 명령어와 구분할 수 있음. 자세한 내용은 검증 상태 참고
관리자는 이 기준을 더 엄격하게 설정할 수 있습니다. 토큰 sudo를 결정하는 정책과 같은 정책입니다. 거부할 위험도 기준을 낮추면 명령 실행과 권한 상승이 함께 더 엄격해집니다. 다만 사람이 검토할 수 있도록 명령을 보류하는 방식으로 바꿀 수는 없습니다.
작업 세션에 연결된 서비스 토큰 명령과 기존 개인 API 접근 토큰으로 보낸 모든 명령은 계속 보류됩니다. 파일 작업에는 영향이 없으며, 이 검증 기준은 실행 명령에만 적용됩니다.
권한 상승을 쓸 수 없을 때
명령어가 누구의 작업인지 확인할 수 없어 sudo가 거부된 경우에는 로그인한 사람이 권한을 받아 명령어를
다시 실행하거나, 명령어와 일치하는 sudo 정책이 있는 작업 세션에서 다시 실행하세요. 명령어가 심각
등급으로 평가되었거나 자동화에 다른 방법이 필요하다면 다음을 검토하세요.
- sudo가 필요 없도록 구성. 토큰 실행 계정에 관리 대상의 직접 제어 권한을 부여함. 서비스에는 systemd 사용자 유닛을 사용하거나, 파일을 소유한 그룹에 계정을 추가할 수 있음. 권한 상승이 없으므로 승인도 필요 없음. 범위가 가장 좁으므로 먼저 시도할 방법임
- 작업 세션에서 실행. sudo 범위가 있는 작업 세션을 사용하면 승인과 감사 기록을 유지할 수 있음. 다만 사람이 세션을 요청해야 하므로 배포를 완전히 무인으로 실행할 수 없음
- 호스트의 sudoers 파일에서 명령 허용. 작업은 계속 무인으로 실행할 수 있지만, 해당 호스트의 권한 상승은 Alpacon 밖에서 결정됨. 이 명령은 Privilege elevation에 표시되지 않고 정책이나 승인도 적용되지 않음. 최후의 수단으로만 사용해야 하며, Alpacon의 특권 접근 제어에서 의도적으로 제외한 호스트에만 적용해야 함
명령어 매칭 참고
와일드카드, 계정과 그룹, sudo 정책 비교, 거부 코드는 토큰 명령어 매칭에서 확인하세요.