Sentinel 정책 만들고 관리하기

Sentinel 정책 만들고 관리하기 (Create and manage Sentinel policies)

이 가이드에서는 정책을 만들고 다양한 시행(enforcement) 수준에서 작업에 적용하는 것을 연습해요. 마지막으로 Sentinel 언어의 세부사항에 대해 더 배워요.

엔터프라이즈: 이 기능은 노마드 엔터프라이즈를 필요로 해요.

출처: 문서

본문

사전 요구사항

다음 예시는 Sentinel 정책을 설치하는 방법을 보여줘요. ACL이 이미 부트스트랩되었고(ACL 가이드 참고), NOMAD_TOKEN 환경 변수가 management 토큰으로 설정되어 있다고 가정해요.

정책 만들고 설치하고 테스트하기

먼저 test.sentinel이라는 이름의 Sentinel 정책을 만들어요:

## Test policy always fails for demonstration purposes
main = rule { false }

그런 다음 실패 시 경고를 발행하는 "advisory" 정책으로 설치해요:

$ nomad sentinel apply -level=advisory test-policy test.sentinel
Successfully wrote "test-policy" Sentinel policy!

nomad job init을 사용해 job file을 만들어요.

$ nomad job init
Example job file written to example.nomad.hcl

nomad job run으로 그 job file을 제출해 봐요.

$ nomad job run example.nomad.hcl
Job Warnings:
1 warning(s):

* test-policy : Result: false (allowed failure based on level)

FALSE - test-policy:2:1 - Rule "main"

==> Monitoring evaluation "f43ac28d"
    Evaluation triggered by job "example"
    Evaluation within deployment: "11e01124"
    Allocation "2618f3b4" created: node "add8ce93", group "cache"
    Allocation "5c2674f2" created: node "add8ce93", group "cache"
    Allocation "9937811f" created: node "add8ce93", group "cache"
    Evaluation status changed: "pending" -> "complete"
==> Evaluation "f43ac28d" finished with status "complete"

출력은 정책이 실패했지만 "advisory" 시행 수준 때문에 작업이 수용되었음을 나타내요.

정책 업데이트하고 테스트하기

다음으로 test.sentinel을 "exec" 기반 드라이버만 허용하도록 변경해요:

# Test policy only allows exec based tasks
main = rule { all_drivers_exec }

# all_drivers_exec checks that all the drivers in use are exec
all_drivers_exec = rule {
    all job.task_groups as tg {
        all tg.tasks as task {
            task.driver is "exec"
        }
    }
}

그런 다음 soft mandatory 수준으로 정책을 업데이트해요:

$ nomad sentinel apply -level=soft-mandatory test-policy test.sentinel
Successfully wrote "test-policy" Sentinel policy!

새 정책으로 "docker" 드라이버를 사용하는 같은 작업을 제출해 봐요:

$ nomad run example.nomad.hcl
Error submitting job: Unexpected response code: 500 (1 error(s) occurred:

* test-policy : Result: false

FALSE - test-policy:2:1 - Rule "main"
  FALSE - test-policy:6:5 - all job.task_groups as tg {
  all tg.tasks as task {
    task.driver is "exec"
  }
}

FALSE - test-policy:5:1 - Rule "all_drivers_exec"
)

출력은 정책과 작업이 모두 실패했음을 나타내요.

정책 재정의

정책이 실패하므로 작업이 거부됐어요. 정책 수준이 "soft-mandatory"이므로 -policy-override 플래그로 재정의할 수 있어요.

-policy-override 플래그를 설정해 작업을 다시 제출해요:

$ nomad job run -policy-override example.nomad.hcl
Job Warnings:
1 warning(s):

* test-policy : Result: false (allowed failure based on level)

FALSE - test-policy:2:1 - Rule "main"
  FALSE - test-policy:6:5 - all job.task_groups as tg {
  all tg.tasks as task {
    task.driver is "exec"
  }
}

FALSE - test-policy:5:1 - Rule "all_drivers_exec"

==> Monitoring evaluation "16195b50"
    Evaluation triggered by job "example"
    Evaluation within deployment: "11e01124"
    Evaluation status changed: "pending" -> "complete"
==> Evaluation "16195b50" finished with status "complete"

이번에는 정책이 실패했지만 재정의되었다는 경고와 함께 작업이 수용됐어요.

지식 확장: 정책 명세

Sentinel 정책은 Sentinel Language로 지정돼요. 이 언어는 정책을 읽고 쓰는 사람이 이해할 수 있도록 설계되었으며 동시에 빠르게 평가되도록 해요. 정책이 얼마나 복잡해질 수 있는지에는 제한이 없지만 실행 경로에 있으므로 성능에 부정적 영향을 주지 않도록 주의해야 해요.

각 범위(scope)에는 제출되는 작업 같은 검사(introspection)에 사용 가능한 서로 다른 객체가 있어요. 정책은 이 객체들을 검사해 세밀한 정책을 적용할 수 있어요.

Sentinel 작업 객체

job 객체는 명시적 import 없이 submit-job 범위의 정책에 자동으로 제공돼요. 이 객체는 JSON 작업 명세에 매핑되지만 가독성을 위해 필드가 약간 달라요.

Sentinel의 식별자 규칙은 소문자이고 밑줄로 구분돼요. 작업의 모든 필드는 같은 이름으로 접근되며, camelCase를 소문자로 변환하고 밑줄로 구분해요. 몇 가지 예시는 다음과 같아요:

Sentinel에 대해 더 알아보기

Sentinel 작업에 대한 자세한 내용은 nomad sentinel 하위 명령과 HTTP API 문서를 참고해 주세요.

더 알아보기 (Learn more)

• Sentinel 정책
• Sentinel 정책 HTTP 엔드포인트
• Sentinel 정책 참조