액세스 모니터링 규칙을 통해 관리자는 액세스 요청을 모니터링하고 특정 조건에 따라 알림 라우팅 규칙이나 자동 검토 규칙을 적용할 수 있습니다.

액세스 모니터링 규칙은 알림 라우팅 규칙과 자동 검토 규칙을 모두 구성하거나 하나만 포함할 수 있습니다.

YAML 사양#

액세스 모니터링 규칙은 다음과 유사한 구조를 가진 동적 Teleport 리소스입니다:

kind: access_monitoring_rule
version: v1
metadata:
  name: example_rule
spec:
  # subjects는 모니터링할 주제의 종류를 지정합니다.
  # 가능한 값: "access_request"
  subjects:
  - access_request

  # condition은 액세스 모니터링 규칙을 적용하기 위해 충족해야 하는 조건을 지정합니다.
  # 조건은 부울 값으로 평가되어야 하는 술어 표현식을 수락합니다.
  #
  # 이 조건은 다음 경우에 충족됩니다:
  # - `access` 역할이 요청됨
  # - 요청된 모든 리소스에 레이블 `env: dev`가 있음
  # - 요청한 사용자에게 `team: dev` 사용자 특성이 있음.
  condition: |-
    contains_all(set("access"), access_request.spec.roles) &&
    access_request.spec.resource_labels_intersection["env"].contains("dev") &&
    contains_any(user.traits["team"], set("dev"))

  # 선택 사항: desired_state는 규칙이 적용된 후 액세스 요청의 원하는 조정 상태를 지정합니다.
  # 자동 검토를 활성화하려면 이 필드를 "reviewed"로 설정해야 합니다.
  # 가능한 값: "reviewed".
  desired_state: reviewed

  # 선택 사항: automatic_review는 자동 검토 규칙을 구성합니다.
  automatic_review:
    # integration은 요청하는 사용자가 규칙 조건을 충족하는지 결정하는 데 도움이 되는
    # 외부 통합 소스의 이름을 지정합니다.
    # 외부 통합 없이 지정하려면 "builtin"을 사용합니다.
    # 가능한 값: "builtin"
    integration: builtin

    # decision은 액세스 요청을 자동으로 승인 또는 거부할지 결정합니다.
    # 가능한 값: "APPROVED" 또는 "DENIED"
    decision: APPROVED

  # 선택 사항: notification은 알림 라우팅 규칙을 구성합니다.
  notification:
    # name은 알림을 라우팅해야 하는 외부 통합을 지정합니다.
    # 가능한 값: "email", "discord", "slack", "pagerduty", "jira",
    # "mattermost", "msteams", "opsgenie", "servicenow", "datadog"
    name: email

    # recipients는 액세스 모니터링 규칙이 적용될 때 알림을 받을 수신자 목록을 지정합니다.
    recipients:
    - example@goteleport.com

  # 선택 사항: schedules는 이 규칙에 적용할 명명된 일정의 맵을 정의합니다.
  schedules:
    demo-schedule:
      time:
        # timezone은 일정의 시간대를 지정합니다. 이 필드는 선택 사항이며
        # 기본값은 "UTC"입니다. 허용되는 값은 IANA 시간대 데이터베이스에 정의된
        # 시간대 식별자를 따릅니다. 예: "America/Los_Angeles", "Europe/Lisbon",
        # "Asia/Singapore".
        #
        # 지원되는 값 목록은 https://data.iana.org/time-zones/tzdb/zone1970.tab를 참조하세요.
        timezone: America/Los_Angeles

        # shifts는 일정을 구성하는 시간 블록 목록입니다.
        # 각 교대는 요일, 시작 시간, 종료 시간을 지정합니다.
        # 시작 및 종료 시간은 포함됩니다.
        shifts:
        - weekday: Friday
          start: 17:00
          end: 23:59
        - weekday: Saturday
          start: 00:00
          end: 23:59

알림 라우팅 규칙#

관리자는 액세스 모니터링 규칙을 사용하여 외부 알림 시스템으로 알림을 라우팅할 수 있습니다.

호스팅된 통합#

사용 가능한 호스팅된 통합의 이름을 나열하려면 다음 명령을 사용할 수 있습니다:

$ tctl get plugins
Name          Status
------------- -----------
datadog       RUNNING
email         RUNNING
slack-default RUNNING

통합이 나열되지 않으면 먼저 플러그인을 등록하세요. 플러그인 등록 방법에 대한 단계별 가이드는 액세스 요청 플러그인을 참조하세요.

수신자#

recipients 필드의 허용 값은 선택한 알림 시스템에 따라 다릅니다.

알림 라우팅 규칙 예시#

다음 규칙이 구성된 경우 access 역할에 대한 액세스 요청이 생성될 때마다 #teleport-access Slack 채널로 알림이 전송됩니다.

kind: access_monitoring_rule
version: v1
metadata:
  name: slack-notifications
spec:
  subjects:
  - access_request
  condition: contains_any(access_request.spec.roles, set("access"))
  notification:
    name: slack-default
    recipients:
    - teleport-access

자동 검토 규칙#

관리자는 조건이 충족될 때 액세스 요청을 자동으로 검토하도록 액세스 모니터링 규칙을 구성할 수 있습니다.

자동 검토를 활성화하려면 spec.desired_state를 reviewed로 설정하고 automatic_review를 정의합니다.

검토 결정#

automatic_review.decision 옵션은 APPROVED 또는 DENIED일 수 있습니다.

자동 검토는 일반 검토처럼 작동합니다. 요청 상태를 직접 변경하지 않으며 필요한 검토 임계값을 준수합니다.

여러 자동 검토 규칙이 액세스 요청과 일치하면 DENIED 규칙이 우선합니다.

자동 검토 규칙 예시#

다음 규칙이 구성된 경우 team: sre 특성을 가진 사용자가 access 역할에 대한 액세스 요청을 생성할 때마다 자동으로 승인됩니다.

kind: access_monitoring_rule
version: v1
metadata:
  name: sre-automatic-approval
spec:
  subjects:
  - access_request
  condition: |-
    contains_all(set("access"), access_request.spec.roles) &&
    contains_any(user.traits["team"], set("sre"))
  desired_state: reviewed
  automatic_review:
    integration: builtin
    decision: APPROVED

리소스에 대한 자동 검토 규칙 예시#

다음 규칙이 구성된 경우 access 역할과 env: dev 레이블이 있는 리소스에 대한 액세스 요청은 자동으로 승인됩니다.

kind: access_monitoring_rule
version: v1
metadata:
  name: env-dev-approval
spec:
  subjects:
  - access_request
  condition: |-
    contains_all(set("access"), access_request.spec.roles) &&
    access_request.spec.resource_labels_intersection["env"].contains("dev")
  desired_state: reviewed
  automatic_review:
    integration: builtin
    decision: APPROVED

예약된 자동 검토 규칙 예시#

다음 규칙이 구성된 경우 access 역할과 env: dev 레이블이 있는 리소스에 대한 액세스 요청은 일요일(UTC 시간)에 자동으로 승인됩니다.

kind: access_monitoring_rule
version: v1
metadata:
  name: env-dev-approval
spec:
  subjects:
  - access_request
  condition: |-
    contains_all(set("access"), access_request.spec.roles) &&
    access_request.spec.resource_labels_intersection["env"].contains("dev")
  desired_state: reviewed
  automatic_review:
    integration: builtin
    decision: APPROVED
  schedules:
    dev-on-call:
      time:
        timezone: UTC
        shifts:
        - weekday: Sunday
          start: 00:00
          end: 23:59

와일드카드 또는 정규 표현식이 있는 자동 검토 규칙 예시#

다음 규칙이 구성된 경우 "on-call" 구문이 포함된 요청 이유로 access 역할에 대한 액세스 요청은 자동으로 승인됩니다.

kind: access_monitoring_rule
version: v1
metadata:
  name: on-call-automatic-approval
spec:
  subjects:
  - access_request
  condition: |-
    regexp.match(set(access_request.spec.request_reason), "*on-call*")
  desired_state: reviewed
  automatic_review:
    integration: builtin
    decision: APPROVED

조건#

condition 필드는 부울 값으로 평가되고 규칙이 적용되는 액세스 요청을 결정하는 술어 표현식입니다.

조건 술어 표현식에서 허용되는 필드:

예시:

# 요청에 하나 이상의 역할이 포함된 경우 적용됩니다.
condition: !is_empty(access_request.spec.roles)

# "example_user"가 생성한 경우 적용됩니다.
condition: access_request.spec.user == "example_user"

# "example_role" 역할이 요청된 경우 적용됩니다.
condition: access_request.spec.roles.contains("example_role")

# 요청된 모든 역할이 "role_1" 또는 "role_2"인 경우 적용됩니다.
condition: set("role_1", "role_2").contains_all(access_request.spec.roles)

# 사용자에게 특성 "team: dev" 또는 "team: stage"가 있는 경우 적용됩니다.
condition: contains_any(user.traits["team"], set("dev", "stage"))

# 요청된 모든 리소스에 `env: dev` 레이블이 있는 경우 적용됩니다.
condition: access_request.spec.resource_labels_intersection["env"].contains("dev")

# 요청된 리소스 중 하나에 `env: prod` 레이블이 있는 경우 적용됩니다.
condition: access_request.spec.resource_labels_union["env"].contains("prod")

# 요청 이유에 "on-call" 구문이 포함된 경우 적용됩니다.
condition: regexp.match(set(access_request.spec.request_reason), "*on-call*")

자세한 내용은 술어 언어를 참조하세요.

SSO 사용자 및 IdP 속성#

액세스 모니터링 규칙은 IdP에서 제공하는 속성을 사용하는 SSO 사용자와 함께 사용할 수 있습니다.

예를 들어 다음 GitHub SSO 구성이 사용되면 example-team 팀의 GitHub 사용자는 github_teams: example-team 특성을 가진 Teleport 사용자로 매핑됩니다.

# github.yaml
kind: github
version: v3
metadata:
  name: github
spec:
  teams_to_roles:
  - organization: example-org
    roles:
    - demo-access-request
    team: example-team
...

이제 github_teams 특성을 기반으로 자동 검토를 적용하는 액세스 모니터링 규칙을 생성할 수 있습니다:

kind: access_monitoring_rule
version: v1
metadata:
  name: dev-automatic-approval
spec:
  subjects:
  - access_request
  condition: |-
    contains_all(set("access"), access_request.spec.roles) &&
    contains_any(user.traits["github_teams"], set("example-team"))
  desired_state: reviewed
  automatic_review:
    integration: builtin
    decision: APPROVED

특성 매핑은 SSO 공급자에 따라 다릅니다. 구성 지침은 단일 로그인 구성을 참조하세요.

인프라스트럭처 코드를 사용한 액세스 모니터링 규칙#

액세스 모니터링 규칙은 Terraform을 사용하여 인프라스트럭처 코드로 관리할 수 있습니다. 다음은 리소스 정의 예시입니다:

resource "teleport_access_monitoring_rule" "example_rule" {
  version = "v1"
  metadata = {
    name = "example_rule"
  }
  spec = {
    subjects      = ["access_request"]
    condition     = "access_request.spec.roles.contains(\"example-role\")"
    desired_state = "reviewed"
    notification = {
      name       = "slack"
      recipients = ["example-channel"]
    }
    automatic_review = {
      integration = "builtin"
      decision    = "APPROVED"
    }
  }
}

자세한 내용은 Terraform 공급자를 참조하세요.