---
title: "서비스 토큰으로 명령어 허용"
description: "애플리케이션 서비스 토큰에 허용 명령어를 등록하고 sudo 동작을 확인합니다. 위험도 검사나 접근 규칙이 자동화 명령어를 거부할 때 조치할 수 있습니다. 실제 작업 전에 실행할 명령어와 일치하는 규칙을 작성하고, 거부된 명령어의 기록에서 원인을 먼저 확인하는 방법을 알아보세요."
---

> Full documentation index: https://docs.alpacax.com/llms.ko.txt

# 서비스 토큰으로 명령어 허용

<span id="명령-패턴과-sudo" />

자동화 작업을 실행하기 전에 토큰의 허용 명령어를 설정하세요. 정확한 매칭 조건과 거부 코드는 [토큰 명령어 매칭](/reference/tokens/command-patterns/)을 참고하세요.

## 실행하는 그대로 규칙을 작성하세요

규칙은 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](/use/audit/events/sudo/)에 기록됩니다.

**사람이 승인한 명령.** 작업 세션에 연결된 서비스 토큰 명령은 사람의 승인을 받을 때까지 보류될 수
있습니다([아래](#토큰-명령이-ai-판정에서-거부되면) 참고). 사람이 보류된
명령을 승인하면 승인한 명령줄에 적힌 `sudo`까지 승인한 것으로 봅니다. 심각을 포함한 모든 위험
수준에서 권한 상승이 허용되며, 그 결정과 연결된 허용 기록이 [Privilege elevation](/use/audit/events/sudo/)에 **관리자 승인**으로
남습니다. 워크스페이스에서 작성한 승인 정책이 명령을 거부하거나 승인자를 2명 이상 요구하는 경우에만
그 정책이 계속 적용됩니다.

**sudo 정책은 서비스 토큰에 적용되지 않습니다.** sudo 정책은 Alpacon 사용자를 대상으로 하며 서비스
토큰은 사용자가 아닙니다. 정책을 작성해도 위 결과는 바뀌지 않습니다.

**Advisory가 아니면 관리자가 기준을 더 엄격하게 정할 수 있습니다.** 워크스페이스의 `token_exec` 규칙으로 권한 상승과 아래의
[AI가 거부한 명령](#토큰-명령이-ai-판정에서-거부되면)을 심각보다 낮은 위험
수준부터 거부하도록 정할 수 있습니다. 둘 다 같은 정책을 읽기 때문입니다. 다만 토큰이 사람인 검토자를
기다리도록 만들 수는 없습니다.

**부여할 sudo 권한은 없습니다.** 토큰 범위 목록에는 `sudo` 작업을 제공하는 리소스가 없습니다. 따라서
애플리케이션의 역할이나 토큰 범위에서 권한 상승을 켜는 방식이 아닙니다. 허용 명령 항목과 명령의
평가된 위험 수준이 권한 상승 여부를 결정합니다.

**API 액세스 토큰은 다릅니다.** 개인 API 액세스 토큰은 단독으로 권한을 높일 수 없습니다. sudo 범위가
포함되고 sudo 정책이 적용되는 [작업 세션 개요](/use/work-sessions/)에서 명령을 실행하거나, 작업을
서비스 토큰으로 옮기세요.

자체 호스팅 배포에서는 서비스 토큰의 `sudo` 명령어가 누구의 작업인지 확인할 수 없어
`SUDO_COMMAND_NOT_AUTHORIZED`로 거부합니다. 로그인한 사람이 권한을 받아 명령어를 다시 실행하거나,
명령어와 일치하는 sudo 정책이 있는 작업 세션에서 다시 실행하세요.

## 토큰 명령이 AI 판정에서 거부되면

모든 명령은 실행 전에 Alpacon의 AI 위험도 검증을 거칩니다. 사람이 보냈거나
[작업 세션 개요](/use/work-sessions/)에서 보낸 명령이 거부되면, 보통 사람이 실행을 승인할 수 있도록
보류됩니다. 자세한 내용은 Commands의 [검증 상태](/use/audit/events/commands/#검증-상태)를
참고하세요.

**작업 세션 없이 보낸 서비스 토큰 명령은 보류되지 않습니다.** CI 작업 등 사람이 지켜보지 않는
자동화에서는 보류된 명령에 응답할 사람이 없기 때문입니다. 이런 명령이 AI 검증에서 거부되면, 판정이
나오는 즉시 워크스페이스의 토큰 실행 정책에 따라 처리됩니다.

- **심각** 위험도이거나 정책에서 거부하는 위험도이면 명령을 거부하고 결과를 *Command rejected by AI
  verification*로 기록함. 이어서 실행하도록 연결된 명령도 모두 취소하고 각각의 결과를 *Cancelled:
  prior command rejected*로 기록함
- 거부 기준보다 위험도가 낮으면 명령어를 그대로 실행함. **검증에서 반려됐지만 세션 없는 서비스 토큰으로 실행됨**
  표시와 함께 거부 판정 및 위험도를 기록함. 서명 모니터 모드에서 실행된 명령어와 구분할 수 있음.
  자세한 내용은 [검증 상태](/use/audit/events/commands/#검증-상태) 참고

**관리자는 이 기준을 더 엄격하게 설정할 수 있습니다.**
[토큰 sudo](#토큰이-sudo를-실행하면)를 결정하는 정책과 같은 정책입니다. 거부할 위험도
기준을 낮추면 명령 실행과 권한 상승이 함께 더 엄격해집니다. 다만 사람이 검토할 수 있도록 명령을
보류하는 방식으로 바꿀 수는 없습니다.

작업 세션에 연결된 서비스 토큰 명령과 기존 개인 [API 접근 토큰](/use/settings/api-tokens/)으로
보낸 모든 명령은 계속 보류됩니다. 파일 작업에는 영향이 없으며, 이 검증 기준은 실행 명령에만
적용됩니다.

## 권한 상승을 쓸 수 없을 때

명령어가 누구의 작업인지 확인할 수 없어 `sudo`가 거부된 경우에는 로그인한 사람이 권한을 받아 명령어를
다시 실행하거나, 명령어와 일치하는 sudo 정책이 있는 작업 세션에서 다시 실행하세요. 명령어가 심각
등급으로 평가되었거나 자동화에 다른 방법이 필요하다면 다음을 검토하세요.

- **sudo가 필요 없도록 구성.** 토큰 실행 계정에 관리 대상의 직접 제어 권한을 부여함. 서비스에는
  systemd 사용자 유닛을 사용하거나, 파일을 소유한 그룹에 계정을 추가할 수 있음. 권한 상승이 없으므로
  승인도 필요 없음. 범위가 가장 좁으므로 먼저 시도할 방법임
- **작업 세션에서 실행.** sudo 범위가 있는 작업 세션을 사용하면 승인과 감사 기록을 유지할 수 있음.
  다만 사람이 세션을 요청해야 하므로 배포를 완전히 무인으로 실행할 수 없음
- **호스트의 sudoers 파일에서 명령 허용.** 작업은 계속 무인으로 실행할 수 있지만, 해당 호스트의 권한
  상승은 Alpacon 밖에서 결정됨. 이 명령은 [Privilege elevation](/use/audit/events/sudo/)에 표시되지 않고 정책이나
  승인도 적용되지 않음. 최후의 수단으로만 사용해야 하며, Alpacon의 특권 접근 제어에서 의도적으로
  제외한 호스트에만 적용해야 함

## 명령어 매칭 참고

와일드카드, 계정과 그룹, sudo 정책 비교, 거부 코드는 [토큰 명령어 매칭](/reference/tokens/command-patterns/)에서 확인하세요.

<span id="명령-규칙은-어떻게-매칭되나요" />
<span id="끝의-와일드카드는-인자를-요구합니다" />
<span id="규칙의-사용자와-그룹" />
<span id="명령-규칙과-sudo-정책은-정반대입니다" />
<span id="거부-메시지" />

## 관련 문서

- [서비스 토큰](/use/iam/applications/service-tokens/)
- [토큰 명령어 매칭](/reference/tokens/command-patterns/)
- [권한 상승](/use/audit/events/sudo/)
- [MFA로 sudo 사용](/use/work-sessions/terminal/sudo-with-mfa/)
- [명령어 기록](/use/audit/events/commands/)

Source: https://docs.alpacax.com/ko/use/iam/applications/service-tokens/command-patterns/