InfoGrab Docs

접근 요청 구성

요약

이 가이드는 Teleport 접근 요청을 구성할 때 고려해야 할 사항을 설명합니다. 접근 요청은 역할별로 구성할 수 있습니다. 전체 접근 요청 라이프사이클 예시를 보려면 다음 방법 가이드 중 하나를 따르세요: 기본적으로 Teleport 사용자는 상승된 권한을 요청할 수 없습니다.

이 가이드는 Teleport 접근 요청을 구성할 때 고려해야 할 사항을 설명합니다. 접근 요청은 Teleport 사용자가 동일한 Teleport 클러스터의 하나 이상의 사용자로부터 승인을 받아 상승된 권한을 얻을 수 있도록 합니다.

접근 요청은 역할별로 구성할 수 있습니다. 사용자가 SSO 공급자를 통해 Teleport에 인증하면, Teleport Auth Service는 사용자의 모든 역할을 조합하여 해당 사용자의 접근 요청 구성을 결정합니다. 그런 다음 Teleport는 사용자가 만드는 모든 접근 요청에 이 구성을 적용합니다.

전체 접근 요청 라이프사이클 예시를 보려면 다음 방법 가이드 중 하나를 따르세요:

사용자가 요청할 수 있는 접근#

기본적으로 Teleport 사용자는 상승된 권한을 요청할 수 없습니다. 사용자가 요청할 수 있는 상승된 접근을 구성하려면 다음을 수행하는 Teleport 역할을 정의할 수 있습니다:

  • 사용자가 요청할 수 있는 다른 Teleport 역할을 명시합니다.
  • 사용자가 데이터베이스 또는 Kubernetes 클러스터와 같은 요청할 리소스를 검색하는 데 사용할 수 있는 다른 Teleport 역할을 명시합니다.

Teleport 역할이 사용자가 이러한 역할에 대한 접근을 요청하지 못하도록 방지하도록 구성할 수도 있습니다.

역할 요청 제한#

사용자가 접근 요청을 제출할 때 접근을 요청하고 싶은 역할을 지정할 수 있습니다.

다음 구성 옵션을 사용하여 사용자가 특정 역할에 대한 접근을 요청하도록 허용하고 다른 역할에 대한 접근을 거부할 수 있습니다:

  • allow.request.roles
  • allow.request.claims_to_roles
  • deny.request.roles
  • deny.request.claims_to_roles

다음은 employee 사용자가 dev와 dba 역할을 요청할 수 있도록 허용하고 아래에서 설명할 더 복잡한 제한 사항을 지정하는 예시입니다:

kind: role
version: v7
metadata:
  name: employee
spec:
  allow:
    request:
      roles:
        - 'dev'
        - 'dba'
      claims_to_roles:
        - claim: groups
          value: admins
          roles: ['*']
  deny:
    request:
      claims_to_roles:
        - claim: groups
          value: contractors
          roles: ['*']

Teleport Auth Service는 사용자의 모든 역할에 대한 이러한 필드의 값을 두 개의 역할 매처 목록으로 결합합니다:

  • 거부: 요청된 역할이 이 중 하나와 일치하면 Teleport가 요청을 거부합니다.
  • 허용: 요청된 역할이 이 중 하나와 일치하고 거부 매처도 역할과 일치하지 않으면 Teleport가 요청을 허용합니다.

역할 매처에는 다음 값이 포함될 수 있습니다:

  • 역할의 리터럴 이름(예: admin).
  • 역할 이름에서 하나 이상의 문자와 일치하는 와일드카드 문자. 예를 들어 db-*는 db-reader 및 db-writer와 일치합니다.
  • ^로 시작하고 $로 끝나는 문자열 내의 Go 정규 표현식. 예를 들어 AWS 리전별로 역할을 정의하는 경우, 역할 매처는 ^db-writer-us-(east|west)-[0-9]+ 정규 표현식을 사용하여 db-writer-us-east-1 및 db-writer-us-west-2 역할과 일치시킬 수 있습니다.

Auth Service는 사용자의 트레잇으로 템플릿 표현식을 평가하여 claims_to_roles의 값을 역할 매처 목록에 추가합니다. Teleport가 claims_to_roles 필드에서 사용자 트레잇으로 템플릿 표현식을 실행하는 방법에 대한 자세한 내용은 역할 템플릿을 참조하세요.

위의 employee 역할에서 사용자가 admins 그룹에 있으면(SSO 공급자가 선언한 대로), 이 역할을 통해 모든 역할에 대한 접근을 요청할 수 있습니다. contractors 그룹에 있으면 이 역할은 역할 요청을 거부합니다.

리소스 요청 제한#

사용자는 특정 Teleport 리소스에 대한 접근 요청을 제출할 수도 있습니다.

다음 Teleport 역할 필드는 사용자가 Teleport 리소스를 검색할 때 어떤 역할을 가정하는지를 나타냅니다:

  • allow.request.search_as_roles
  • deny.request.search_as_roles

예를 들어, 다음 역할을 통해 사용자는 k8s-viewer 역할이 접근을 허용하는 리소스를 검색할 수 있습니다.

# requester.yaml
kind: role
version: v7
metadata:
  name: k8s-requester
spec:
  allow:
    request:
      search_as_roles:
        - k8s-viewer

역할 요청 구성과 달리, request.search_as_roles 필드는 리터럴 역할 이름 목록만 허용하며 와일드카드나 정규 표현식을 지원하지 않습니다.

Teleport Auth Service는 사용자의 Teleport 역할 모두에 대한 이러한 필드의 값을 결합하여 사용자의 접근 요청을 검증합니다.

사용자가 Teleport 리소스(서버 및 데이터베이스 등) 또는 Kubernetes 리소스(파드 및 배포 등)를 나열하려고 할 때, Auth Service는 사용자가 검색으로 허용된 역할을 확인합니다. 사용자의 Teleport 역할 또는 search_as_roles에 지정된 역할이 사용자의 리소스 검색을 허용하면 Teleport Auth Service는 리소스에 대한 정보를 반환합니다.

사용자가 리소스 ID에 대한 접근을 요청하면 Teleport Auth Service는 다음을 수행합니다:

  1. allow.request.search_as_roles에 명시된 모든 역할을 수집하여 deny.request.search_as_roles 또는 deny.request.roles에 지정된 역할을 제외합니다.
  2. 나머지 역할 중 요청된 리소스에 접근할 수 있는 역할을 결정합니다. 리소스 접근 요청이 유효하려면 사용자의 search_as_roles 구성에 나열된 역할 중 하나가 요청된 리소스에 대한 접근을 허용해야 합니다.

접근 지속 시간#

승인된 접근 요청에 대해 Teleport가 사용자에게 상승된 권한을 부여하는 기간을 구성할 수 있습니다.

상승된 권한 기간 계산#

Teleport는 다음 로직을 사용하여 사용자의 상승된 권한 기간을 계산합니다:

  1. 접근 요청이 승인된 경우 상승된 권한의 최대 기간을 계산합니다. 다음 중 가장 낮은 값입니다:
    • tsh request create 명령의 --max-duration 플래그(요청을 만드는 사용자가 이 플래그를 제공하는 경우).
    • 사용자의 요청된 역할 중 하나에 포함된 request.max_duration 필드의 가장 낮은 값.
  2. Teleport가 접근 요청을 승인한다면 사용자가 받을 인증서의 세션 TTL을 계산합니다. 이 계산은 다음 중 가장 낮은 값을 선택합니다:
    • 요청된 세션 만료 시간으로 tsh request create의 --session-ttl 플래그 값.
    • 사용자의 현재 Teleport 세션의 남은 시간.
    • 사용자의 요청된 역할에서 options.max_session_ttl 필드의 가장 낮은 값.
  3. 최대 기간이 0보다 크면 상승된 권한의 기간을 최대 기간 또는 앞서 계산한 세션 TTL 중 더 짧은 것으로 설정합니다. 그렇지 않으면 세션 TTL로 설정합니다.

사용자가 상승된 권한을 가정할 수 있는 시기 설정#

접근 요청을 만들거나 검토할 때 --assume-start-time 플래그를 사용하여 사용자가 상승된 권한을 가정할 수 있는 가장 이른 시간을 지정할 수 있습니다. 이 플래그는 tsh request create 및 tsh request review 명령에서 사용할 수 있습니다. 허용되는 형식은 RFC 3339에 정의되어 있습니다. 예: 2023-12-12T23:20:50.52Z. 지정된 시간은 미래여야 합니다.

검토자는 접근 요청을 승인할 때 이 시간을 재정의할 수 있습니다. 여러 검토자가 시작 시간을 재정의하면 가장 최근 재정의가 선택됩니다.

request.max_duration 필드#

max_duration 옵션은 특정 역할에 대해 사용자가 상승된 권한을 가질 수 있는 최대 기간을 나타냅니다. 사용자가 성공적인 접근 요청을 만든 후 최대 기간이 경과할 때까지 상승된 접근으로 Teleport에 인증할 수 있습니다.

사용자가 Teleport에 인증할 때마다 Teleport는 이전 섹션에서 설명한 공식을 사용하여 사용자의 Teleport 세션 TTL을 계산합니다. 사용자는 최대 기간이 경과하기 전에 여러 세션으로 상승된 권한을 가질 수 있습니다.

다음과 같은 역할로 max_duration 옵션을 지정할 수 있습니다:

kind: role
version: v7
metadata:
  name: temp-dba
spec:
  allow:
    request:
      # Allow access to role `dba` for up to 4 days.
      roles: ['dba']
      max_duration: 4d

max_duration의 값은 14일을 초과할 수 없습니다.

접근 요청의 유효 기간#

Teleport는 다음 로직을 사용하여 접근 요청이 승인을 기다리는 동안 얼마나 유효한지를 결정합니다:

  1. tsh request create 명령의 --request-ttl 플래그로 사용자가 설정할 수 있는 접근 요청의 기본 만료로 시작합니다. 설정되지 않은 경우 요청 TTL은 1시간입니다.
  2. 사용자의 Teleport 세션이 기본 만료 시간 전에 만료될 경우, Teleport는 접근 요청 만료를 Teleport 세션 종료로 설정합니다.
  3. 접근 요청에서 요청된 Teleport 역할 중 하나의 options.max_session_ttl이 만료 시간 전에 만료되면 Teleport는 접근 요청의 만료를 해당 시간으로 설정합니다.
  4. --request-ttl 값이 이전 단계에서 계산된 요청 TTL보다 크면 오류를 반환합니다.

클라이언트의 접근 요청 방법#

사용자의 Teleport 역할은 접근 요청을 제출하는 방법, 접근 요청이 선택 사항인지 필수 사항인지, 요청 시 이유를 제공해야 하는지를 결정합니다.

역할의 options.request_access 설정은 접근 요청을 생성하는 전략을 지정합니다. 다음 값 중 하나를 포함할 수 있습니다:

값 의미
optional 기본값. 사용자는 요청할 때 이유를 지정할 필요가 없습니다. 사용자는 Teleport에 로그인할 때 수동으로 요청을 시작해야 합니다.
always 사용자가 Teleport에 로그인할 때 클라이언트는 이유 없이 사용자에게 사용 가능한 모든 역할에 대한 접근 요청을 자동으로 생성합니다.
reason 사용자가 Teleport에 로그인할 때 클라이언트는 사용자에게 사용 가능한 모든 역할에 대한 접근 요청을 자동으로 생성합니다. 사용자는 인증 시 이유를 제공해야 합니다.

역할에 reason 전략이 포함된 경우, 사용자가 이유 없이 접근 요청을 만들려고 할 때 이유를 제공하도록 상기시키는 프롬프트를 지정할 수 있습니다. 이를 위해 역할의 options.request_prompt 옵션을 설정합니다.

예를 들어, 다음 역할은 "Please provide your ticket ID"라는 텍스트로 사용자에게 프롬프트를 표시합니다:

kind: role
version: v7
metadata:
  name: employee
spec:
  allow:
    request:
      roles:
        - 'dba'
  options:
    request_access: reason
    request_prompt: Please provide your ticket ID

Teleport Auth Service는 다음 로직을 사용하여 사용자에게 속한 다른 역할의 request_access 필드에 지정된 전략을 결합합니다:

  1. 사용자의 역할 중 하나에 reason 또는 always 전략이 포함된 경우, Teleport는 사용자가 인증할 때 사용자에게 사용 가능한 모든 역할을 자동으로 요청합니다.
  2. 사용자의 역할 중 하나에 reason 전략이 포함된 경우, 사용자는 인증 시 이유를 제공해야 합니다.

요청 이유 요구#

spec.allow.request.reason.mode 필드는 사용자가 접근 요청을 제출할 때 이유가 필요한지를 제어합니다.

허용되는 값:

값 의미
optional 기본값. 사용자는 요청할 때 이유를 제공할 필요가 없습니다.
required 사용자는 요청할 때 비어 있지 않은 이유를 제공해야 합니다.

spec.allow.request.reason.prompt를 사용하여 특정 요청 가능한 역할이나 리소스에 대해 이유를 제공하도록 상기시키는 범위가 지정된 프롬프트를 지정할 수 있습니다.

예시:

kind: role
version: v7
metadata:
  name: node-requester
spec:
  allow:
    request:
      roles:
        - 'node-access'
      search_as_roles:
        - 'root-node-access'
      reason:
        mode: 'required'
        prompt: 'Please give a reason for accessing node resources'

node-requester 역할이 할당된 사용자가 node-access 역할이나 root-node-access에서 허용하는 리소스에 대한 접근 요청을 만들면 이유를 제공해야 합니다. 사용자의 역할 세트에 동일한 역할 및 리소스에 대한 접근 요청을 제어하는 여러 역할이 포함된 경우, required 모드가 우선합니다.

커스텀 요청 이유 프롬프트#

사용자에 대한 커스텀 요청 프롬프트를 지정할 수 있습니다:

  • 단일 역할로 지정된 요청 가능한 리소스 또는 역할에 대해
  • 사용자가 만드는 모든 접근 요청에 대해

단일 역할로 지정된 요청 가능한 리소스에 대한 범위가 지정된 프롬프트를 지정하려면 spec.allow.request.reason.prompt를 비어 있지 않은 문자열로 설정합니다. 이는 특정 리소스 또는 역할을 포함하는 접근 요청에만 영향을 미칩니다.

커스텀 글로벌 요청 프롬프트는 spec.options.request_prompt를 비어 있지 않은 문자열로 설정하여 사용자에게 역할을 할당함으로써 지정할 수 있습니다. 이 글로벌 프롬프트는 사용자가 만드는 모든 접근 요청에 적용됩니다.

동일한 접근 요청에 여러 글로벌 프롬프트와 범위가 지정된 프롬프트가 적용되면, 모든 프롬프트가 요청 이유 양식에서 알파벳 순서로 나열됩니다.

예시:

kind: role
version: v7
metadata:
  name: k8s-requester
spec:
  allow:
    request:
      search_as_roles:
        - 'k8s-viewer'
      reason:
        # If a user is assigned this role, the prompt below will be displayed
        # when any resource allowed by k8s-viewer role is requested.
        prompt: 'Please give a reason for accessing kubernetes resources'

kind: role
version: v7
metadata:
  name: employee
spec:
  allow: {}
  options:
    # If a user is assigned this role, the prompt below will be displayed for
    # all access requests made by this user.
    request_prompt: 'Please provide your ticket ID'

k8s-requester 및 employee 역할이 할당된 사용자가 k8s-viewer로 검색 가능한 리소스에 대한 접근 요청을 만들면, "Please give a reason for accessing kubernetes resources"라는 텍스트가 첫 번째 줄에, "Please provide your ticket ID"가 두 번째 줄에 알파벳 순서로 프롬프트됩니다.

검토 임계값#

접근 요청이 Teleport에 의해 승인되거나 거부되기 전에 충족해야 하는 기준을 지정하도록 사용자의 역할을 구성할 수 있습니다. 이를 위해 allow.request.thresholds 필드를 구성합니다.

allow.request.thresholds 필드#

다음은 요청 가능한 역할에 대한 검토 임계값을 지정하는 역할 예시입니다:

kind: role
version: v7
metadata:
  name: devops
spec:
  allow:
    request:
      roles: ['dbadmin']
      thresholds:
        - approve: 3
          deny: 2
          filter: '!contains(reviewer.traits.team, "dev")'
        - approve: 1
          deny: 1
          filter: 'contains(reviewer.roles, "admin")'

해당 deny.requests.thresholds 필드가 없으며, Teleport는 그것을 포함하는 역할을 거부합니다.

각 임계값에는 다음 필드가 포함됩니다:

필드 설명
approve 접근 요청을 승인하기 위해 승인해야 하는 검토자의 수. 기본값은 1.
deny 접근 요청을 거부하기 위해 거부해야 하는 검토자의 수. 기본값은 1.
filter 검토가 임계값의 승인 또는 거부 횟수에 추가되기 전에 접근 요청 또는 검토가 충족해야 하는 조건. 다음 섹션에서 더 자세히 설명됩니다.

위의 devops 역할에서는 dbadmin 역할과 관련된 두 개의 임계값이 있습니다. 결과적으로 요청이 승인되거나 거부되기 전에 다음 조건 중 하나가 충족되어야 합니다:

  1. 세 명의 사용자가 요청을 승인하고 두 명의 사용자가 거부해야 하며, 이 사용자들은 dev 값을 가진 team 트레잇을 가지지 않아야 합니다.
  2. 한 명의 사용자가 검토를 승인하고 한 명의 사용자가 거부해야 하며, 검토를 제출하는 사용자는 admin 역할을 가져야 합니다.

임계값 필터#

Teleport가 특정 역할에 대한 접근 요청을 처리할 때, 요청이 해당 역할과 관련된 allow.request.thresholds의 임계값 중 하나에 지정된 기준을 충족했는지 확인합니다.

filter 값은 Teleport 조건 언어를 사용하는 표현식입니다.

예를 들어, 다음 구성에는 4개의 임계값이 포함되어 있으며, 그 중 3개에는 필터가 있습니다:

spec:
  allow:
    request:
      roles: ['dbadmin']
      thresholds:
        - approve: 3
          deny: 1
        - filter: 'contains(reviewer.roles, "super-approver")'
          approve: 2
          deny: 1
        - filter: '!equals(request.reason, "") && contains(reviewer.roles, "super-approver")'
          approve: 1
          deny: 1
        - filter: 'regexp.match(request.reason, "^Ticket [0-9]+.*$") && !equals(review.reason, "")'
          approve: 1
          deny: 1

첫 번째 임계값은 세 명의 사용자가 승인하고 한 명의 사용자가 거부해야 합니다. 그러나 각 검토자가 super-approver 역할을 가지고 있으면 두 번의 승인만 필요합니다. 요청에 비어 있지 않은 이유가 있으면 super-approver 역할을 가진 사용자로부터 한 번의 승인만 필요합니다. 요청의 이유가 정규식 ^Ticket [0-9]+.*$와 일치하면 검토자가 비어 있지 않은 이유를 제공하는 한 어떤 검토자로부터도 한 번의 승인만 필요합니다.

필터 표현식은 각 접근 요청 검토와 관련된 다음 데이터를 활용할 수 있습니다: 요청, 검토자, 검토 자체:

필드 유형 설명
reviewer.roles []string 검토자의 역할.
reviewer.traits map[string][]string 검토자의 트레잇.
review.reason string 검토에 제공된 이유.
review.annotations map[string][]string 검토에 추가된 주석. 접근 요청을 승인하거나 거부하는 프로그래밍 방식의 Teleport 클라이언트가 추가합니다.
request.roles []string 요청에 포함된 역할.
request.reason string 요청에 제공된 이유.
request.system_annotations map[string][]string 요청 주석.

다음 연산자와 함수를 포함하는 표현식에서 이러한 필드를 사용할 수 있습니다:

연산자/함수 설명
equals(val1,val2) val1이 val2와 같으면 true, 그렇지 않으면 false를 반환합니다.
contains(list, item) list에 item과 정확히 일치하는 항목이 포함되어 있으면 true를 반환합니다.
regexp.match(list, re) list에 re와 일치하는 항목이 포함되어 있으면 true를 반환합니다.
expr1 && expr2 expr1과 expr2 모두 true로 평가되면 true로 평가됩니다.
expr1 || expr2 expr1, expr2 또는 둘 다 true로 평가되면 true로 평가됩니다.
!expr expr을 부정합니다.

위에서 list라는 인수는 값 목록(예: request.roles) 또는 단일 값(예: request.reason)을 허용할 수 있습니다.

regexp.match에 대한 re 인수는 글로브 스타일 와일드카드(* 문자)와 Go 스타일 정규 표현식을 모두 지원합니다. 표현식이 ^ 문자로 시작하고 $ 문자로 끝나면 Teleport는 이를 정규 표현식으로 평가합니다. 그렇지 않으면 와일드카드 표현식으로 평가합니다. 와일드카드는 0개 이상의 문자 시퀀스와 일치합니다.

제안된 검토자#

제안된 검토자를 접근 요청에 제안하도록 Teleport 역할을 구성할 수 있습니다.

Teleport는 사용자의 역할에 있는 allow.request.suggested_reviewers 필드에 명시된 모든 검토자를 결합합니다. 접근 요청에 제안된 검토자가 없으면 Teleport는 사용자의 제안된 검토자를 요청에 추가합니다.

다음 역할은 제안된 검토자로 user1과 user2를 추가합니다:

kind: role
version: v7
metadata:
  name: employee
spec:
  allow:
    request:
      roles:
        - 'dev'
        - 'dba'
      suggested_reviewers:
       - 'user1'
       - 'user2'

제안된 검토자는 제안된 검토자와 동일한 role 리소스에 명시된 역할뿐만 아니라 사용자가 접근을 요청할 수 있는 모든 역할에 적용됩니다.

Teleport는 비어 있지 않은 deny.request.suggested_reviewers 필드가 있는 역할을 수락하지만 접근 요청을 평가할 때 allow.request.suggested_reviewers 필드만 고려합니다.

제안된 검토자로서의 접근 목록 소유자#

Teleport는 접근 요청 생성 시 접근 목록 소유자를 자동으로 검토자로 제안할 수 있습니다.

Teleport는 두 가지 경우에 이를 수행합니다:

요청을 접근 목록으로 승격할 수 있는 경우#

리소스 기반 접근 요청의 경우, 요청된 리소스에 대한 접근을 부여하는 접근 목록의 소유자가 제안된 검토자로 자동으로 추가될 수 있습니다.

접근 목록의 소유자는 다음 조건이 충족될 때 제안됩니다.

  • 요청자가 아직 접근 목록의 멤버가 아닌 경우.
  • 요청자가 접근 목록에 가입할 자격이 있는 경우.
  • 접근 목록이 요청된 모든 리소스에 대한 접근을 부여하는 경우.

요청자가 이미 해당 접근 목록의 멤버인 경우#

해당 접근 목록의 소유자도 요청자가 이미 접근 목록의 멤버인 경우 제안된 검토자로 자동으로 추가될 수 있습니다.

접근 목록의 소유자는 다음 조건이 충족될 때 제안됩니다.

  • 요청자가 이미 접근 목록의 멤버인 경우.
  • 접근 목록을 접근 요청에 적용할 수 있는 경우.
  • 접근 목록 소유자가 요청된 역할에 대한 요청을 검토할 수 있도록 허용된 경우.

단기 요청의 경우, 접근 목록의 멤버 권한에 요청된 역할 중 하나를 요청할 수 있는 역할이 포함되어 있으면 접근 목록이 적용 가능합니다.

장기 요청의 경우, 접근 목록이 요청된 역할 중 하나를 직접 부여하면 접근 목록이 적용 가능합니다.

리소스 요청의 경우, 이는 접근 목록이 요청된 리소스에 대한 접근을 부여하는 역할을 요청할 수 있는 역할을 부여함을 의미합니다.

두 경우 모두 이 소유자들은 여전히 그러한 접근 요청을 검토할 수 있도록 허용하는 적절한 Teleport 역할이 있어야 합니다.

이러한 사용 사례에 대한 자세한 내용은 접근 요청 검토 가이드에서 확인할 수 있습니다.

검토자가 접근을 부여할 수 있는 역할#

Teleport 사용자는 특정 역할에 대한 접근 요청을 검토할 권한이 있어야 합니다. 일부 Teleport 역할에 대한 접근 요청을 검토할 수 있도록 사용자의 Teleport 역할을 구성하고 다른 역할에 대한 요청 검토 능력을 거부할 수 있습니다.

특정 역할에 대한 검토 허용 및 거부#

특정 역할에 대한 요청은 검토할 수 있지만 다른 역할은 검토할 수 없도록 하려면 다음 역할 필드를 편집하세요:

  • allow.review_requests.roles
  • allow.review_requests.claims_to_roles
  • deny.review_requests.roles
  • deny.review_requests.claims_to_roles

Auth Service는 사용자의 트레잇으로 템플릿 표현식을 사용하여 claims_to_roles 필드를 평가합니다.

사용자가 특정 역할에 대한 접근 요청을 검토하려면 최소 하나의 허용 규칙이 사용자에게 해당 역할에 대한 요청 검토 접근을 부여해야 합니다. 해당 역할 검토 접근을 허용하지 않는 거부 규칙이 없어야 합니다.

where 표현식#

requests.roles 및 requests.claims_to_roles 필드와 달리, review_requests.roles 및 review_requests.claims_to_roles 필드를 사용하면 where 표현식에 따라 역할의 접근 요청을 검토하는 권한을 부여하거나 거부할 수 있습니다. 표현식이 접근 요청에 대해 성립하면 Teleport는 review_requests_claims_to_roles 및 review_requests.roles 필드에 대한 허용 또는 거부 규칙을 적용합니다.

예를 들어, 다음 구성은 역할이 contractor-prod이고 요청 이유가 비어 있지 않는 한 검토자가 모든 역할에 대한 요청을 검토할 수 있도록 허용합니다:

metadata:
  name: reviewer
# ...
allow:
  review_requests:
    roles: ['*']
deny:
  review_requests:
    roles: ['contractor-prod']
    where: 'request.reason == ""'

접근 요청 검토를 검증할 때 Teleport는 검토자의 모든 역할에 있는 각 where 표현식을 고려합니다. 하나의 where 표현식이 검토에 대해 성립하면 Teleport는 검토자가 해당 where 표현식과 동일한 Teleport 역할에 정의된 해당 역할에 대한 요청을 검토할 권한이 있는지 확인합니다.

예를 들어 사용자가 contractor-prod 역할을 요청하고 요청에 빈 이유를 남기면, 위에서 정의한 reviewer 역할을 가진 사용자는 요청을 검토할 수 없습니다.

where 표현식은 접근 요청과 관련된 다음 데이터를 활용할 수 있습니다:

필드 유형 설명
reviewer.roles []string 검토자의 Teleport 역할.
reviewer.traits map[string][]string 검토자의 Teleport 트레잇.
request.roles []string 접근 요청에서 요청된 역할.
request.reason string 요청 이유.
request.system_annotations map[string][]string 요청 주석.

다음 연산자와 함수를 포함하는 표현식에서 이러한 필드를 사용할 수 있습니다:

연산자/함수 설명
equals(val1,val2) val1이 val2와 같으면 true, 그렇지 않으면 false를 반환합니다.
contains(list, item) list에 item과 정확히 일치하는 항목이 포함되어 있으면 true를 반환합니다.
regexp.match(list, re) list에 re와 일치하는 항목이 포함되어 있으면 true를 반환합니다.
expr1 && expr2 expr1과 expr2 모두 true로 평가되면 true로 평가됩니다.
expr1 || expr2 expr1, expr2 또는 둘 다 true로 평가되면 true로 평가됩니다.
!expr expr의 반대로 평가됩니다.

위에서 list라는 인수는 값 목록(예: request.roles) 또는 단일 값(예: request.reason)을 허용할 수 있습니다.

regexp.match에 대한 re 인수는 글로브 스타일 와일드카드(* 문자)와 Go 스타일 정규 표현식을 모두 지원합니다. 표현식이 ^ 문자로 시작하고 $ 문자로 끝나면 Teleport는 이를 정규 표현식으로 평가합니다. 그렇지 않으면 와일드카드 표현식으로 평가합니다. 와일드카드는 0개 이상의 문자 시퀀스와 일치합니다.

요청된 리소스 검사#

Teleport 사용자는 리소스에 접근하지 않고 해당 리소스에 대한 정보를 볼 수 있습니다. 이는 다른 사용자의 접근 요청을 승인하여 사용자에게 접근을 부여하기 전에 리소스를 검사하는 데 유용합니다.

리소스에 접근하지 않고 Teleport 리소스를 나열하는 사용자 능력을 부여하거나 거부하려면 사용자의 역할에서 allow.review_requests.preview_as_roles 및 deny.review_requests.preview_as_roles 필드를 사용합니다:

kind: role
version: v7
metadata:
  name: reviewer
spec:
  allow:
    review_requests:
      roles:
        - access
      preview_as_roles:
        - access

사용자가 tsh ls 명령을 사용하는 등 Teleport 리소스를 나열하려고 할 때, Teleport Auth Service는 사용자의 preview_as_roles가 리소스를 나열하는 접근을 부여하는지 확인하고, 그렇다면 리소스를 나열합니다. 이는 배포 및 파드와 같이 Teleport로 보호된 Kubernetes 리소스를 나열하려는 사용자에게도 적용됩니다.

리소스를 미리 볼 수 없으면 검토자는 접근 요청에서 제공한 리소스의 UUID만 볼 수 있습니다.

요청 주석#

사용자가 접근 요청을 만들 때 Teleport Auth Service는 임의의 메타데이터를 요청에 쓸 수 있습니다. 접근 요청을 사용하는 Teleport 통합은 메타데이터를 읽어 동작을 지시할 수 있습니다.

주석은 단일 키가 값 목록에 해당하는 키-값 쌍입니다. 모든 값은 문자열입니다.

요청 주석을 지원하는 플러그인#

다음 Teleport 지원 접근 요청 플러그인은 요청 주석을 읽습니다:

통합 주석 키 주석 사용 방법
Pagerduty pagerduty_notify_service, pagerduty_services 사용자가 접근 요청을 제출할 때 pagerduty_notify_service에 명시된 서비스에서 인시던트를 엽니다. 사용자가 pagerduty_services에 명시된 서비스의 온콜 로테이션에 있으면 Teleport는 해당 사용자가 열린 접근 요청을 자동으로 승인합니다.
Opsgenie teleport.dev/notify-services, teleport.dev/schedules 통합은 사용자가 teleport.dev/schedules에 나열된 서비스 중 하나에 온콜인 경우 사용자의 접근 요청을 승인합니다. 또한 사용자가 접근 요청을 만들 때 teleport.dev/notify-services에 명시된 서비스에서 알림을 만듭니다.
ServiceNow teleport.dev/notify-services, teleport.dev/schedules 통합은 사용자가 teleport.dev/schedules에 나열된 서비스 중 하나에 온콜인 경우 사용자의 접근 요청을 승인합니다. 또한 사용자가 접근 요청을 만들 때 teleport.dev/notify-services에 명시된 서비스에서 알림을 만듭니다.

주석 허용 및 거부#

Teleport Auth Service는 다음 로직을 적용하여 사용자의 역할에서 접근 요청 주석을 평가합니다: 주어진 키가 있는 모든 허용된 주석 값에 대해, 동일한 키의 거부된 주석 값도 있는지 확인합니다. 있으면 건너뜁니다. 그렇지 않으면 주석을 접근 요청에 추가합니다.

예를 들어, 다음 필드가 있는 역할을 정의했다고 가정해 보겠습니다:

allow:
  request:
    annotations:
      pagerduty_services:
        - data-writer
        - data-reader

또한 다음 필드가 있는 역할을 정의했습니다:

deny:
  request:
    annotations:
      pagerduty_services:
        - data-reader

이 경우 사용자의 접근 요청에 대한 최종 주석 매핑에는 다음 주석이 포함됩니다:

pagerduty_services:
 - data-writer

커스텀 플러그인에서 주석 읽기#

자체 접근 요청 플러그인을 작성하는 경우, 프로그램은 다음과 유사한 함수를 사용하여 시스템 주석에 접근할 수 있습니다:

func getMyAnnotation(req types.AccessRequest) ([]string, error) {
	result, ok := req.GetSystemAnnotations()["my-annotation"]
	if !ok {
		return nil, trace.NotFound("annotation not found")
	}
	return result, nil
}

이 함수는 types.AccessRequest 유형의 GetSystemAnnotations 메서드를 사용하여 키 my-annotation이 있는 접근 요청의 모든 주석 값을 가져옵니다.

추가 읽기#

Teleport 역할 내의 구성 옵션에 대한 전체 설명은 접근 제어 레퍼런스를 참조하세요.

접근 요청 구성

원문 보기
요약

이 가이드는 Teleport 접근 요청을 구성할 때 고려해야 할 사항을 설명합니다. 접근 요청은 역할별로 구성할 수 있습니다. 전체 접근 요청 라이프사이클 예시를 보려면 다음 방법 가이드 중 하나를 따르세요: 기본적으로 Teleport 사용자는 상승된 권한을 요청할 수 없습니다.

이 가이드는 Teleport 접근 요청을 구성할 때 고려해야 할 사항을 설명합니다. 접근 요청은 Teleport 사용자가 동일한 Teleport 클러스터의 하나 이상의 사용자로부터 승인을 받아 상승된 권한을 얻을 수 있도록 합니다.

접근 요청은 역할별로 구성할 수 있습니다. 사용자가 SSO 공급자를 통해 Teleport에 인증하면, Teleport Auth Service는 사용자의 모든 역할을 조합하여 해당 사용자의 접근 요청 구성을 결정합니다. 그런 다음 Teleport는 사용자가 만드는 모든 접근 요청에 이 구성을 적용합니다.

전체 접근 요청 라이프사이클 예시를 보려면 다음 방법 가이드 중 하나를 따르세요:

사용자가 요청할 수 있는 접근#

기본적으로 Teleport 사용자는 상승된 권한을 요청할 수 없습니다. 사용자가 요청할 수 있는 상승된 접근을 구성하려면 다음을 수행하는 Teleport 역할을 정의할 수 있습니다:

  • 사용자가 요청할 수 있는 다른 Teleport 역할을 명시합니다.
  • 사용자가 데이터베이스 또는 Kubernetes 클러스터와 같은 요청할 리소스를 검색하는 데 사용할 수 있는 다른 Teleport 역할을 명시합니다.

Teleport 역할이 사용자가 이러한 역할에 대한 접근을 요청하지 못하도록 방지하도록 구성할 수도 있습니다.

역할 요청 제한#

사용자가 접근 요청을 제출할 때 접근을 요청하고 싶은 역할을 지정할 수 있습니다.

다음 구성 옵션을 사용하여 사용자가 특정 역할에 대한 접근을 요청하도록 허용하고 다른 역할에 대한 접근을 거부할 수 있습니다:

  • allow.request.roles
  • allow.request.claims_to_roles
  • deny.request.roles
  • deny.request.claims_to_roles

다음은 employee 사용자가 dev와 dba 역할을 요청할 수 있도록 허용하고 아래에서 설명할 더 복잡한 제한 사항을 지정하는 예시입니다:

kind: role
version: v7
metadata:
  name: employee
spec:
  allow:
    request:
      roles:
        - 'dev'
        - 'dba'
      claims_to_roles:
        - claim: groups
          value: admins
          roles: ['*']
  deny:
    request:
      claims_to_roles:
        - claim: groups
          value: contractors
          roles: ['*']

Teleport Auth Service는 사용자의 모든 역할에 대한 이러한 필드의 값을 두 개의 역할 매처 목록으로 결합합니다:

  • 거부: 요청된 역할이 이 중 하나와 일치하면 Teleport가 요청을 거부합니다.
  • 허용: 요청된 역할이 이 중 하나와 일치하고 거부 매처도 역할과 일치하지 않으면 Teleport가 요청을 허용합니다.

역할 매처에는 다음 값이 포함될 수 있습니다:

  • 역할의 리터럴 이름(예: admin).
  • 역할 이름에서 하나 이상의 문자와 일치하는 와일드카드 문자. 예를 들어 db-*는 db-reader 및 db-writer와 일치합니다.
  • ^로 시작하고 $로 끝나는 문자열 내의 Go 정규 표현식. 예를 들어 AWS 리전별로 역할을 정의하는 경우, 역할 매처는 ^db-writer-us-(east|west)-[0-9]+ 정규 표현식을 사용하여 db-writer-us-east-1 및 db-writer-us-west-2 역할과 일치시킬 수 있습니다.

Auth Service는 사용자의 트레잇으로 템플릿 표현식을 평가하여 claims_to_roles의 값을 역할 매처 목록에 추가합니다. Teleport가 claims_to_roles 필드에서 사용자 트레잇으로 템플릿 표현식을 실행하는 방법에 대한 자세한 내용은 역할 템플릿을 참조하세요.

위의 employee 역할에서 사용자가 admins 그룹에 있으면(SSO 공급자가 선언한 대로), 이 역할을 통해 모든 역할에 대한 접근을 요청할 수 있습니다. contractors 그룹에 있으면 이 역할은 역할 요청을 거부합니다.

리소스 요청 제한#

사용자는 특정 Teleport 리소스에 대한 접근 요청을 제출할 수도 있습니다.

다음 Teleport 역할 필드는 사용자가 Teleport 리소스를 검색할 때 어떤 역할을 가정하는지를 나타냅니다:

  • allow.request.search_as_roles
  • deny.request.search_as_roles

예를 들어, 다음 역할을 통해 사용자는 k8s-viewer 역할이 접근을 허용하는 리소스를 검색할 수 있습니다.

# requester.yaml
kind: role
version: v7
metadata:
  name: k8s-requester
spec:
  allow:
    request:
      search_as_roles:
        - k8s-viewer

역할 요청 구성과 달리, request.search_as_roles 필드는 리터럴 역할 이름 목록만 허용하며 와일드카드나 정규 표현식을 지원하지 않습니다.

Teleport Auth Service는 사용자의 Teleport 역할 모두에 대한 이러한 필드의 값을 결합하여 사용자의 접근 요청을 검증합니다.

사용자가 Teleport 리소스(서버 및 데이터베이스 등) 또는 Kubernetes 리소스(파드 및 배포 등)를 나열하려고 할 때, Auth Service는 사용자가 검색으로 허용된 역할을 확인합니다. 사용자의 Teleport 역할 또는 search_as_roles에 지정된 역할이 사용자의 리소스 검색을 허용하면 Teleport Auth Service는 리소스에 대한 정보를 반환합니다.

사용자가 리소스 ID에 대한 접근을 요청하면 Teleport Auth Service는 다음을 수행합니다:

  1. allow.request.search_as_roles에 명시된 모든 역할을 수집하여 deny.request.search_as_roles 또는 deny.request.roles에 지정된 역할을 제외합니다.
  2. 나머지 역할 중 요청된 리소스에 접근할 수 있는 역할을 결정합니다. 리소스 접근 요청이 유효하려면 사용자의 search_as_roles 구성에 나열된 역할 중 하나가 요청된 리소스에 대한 접근을 허용해야 합니다.

접근 지속 시간#

승인된 접근 요청에 대해 Teleport가 사용자에게 상승된 권한을 부여하는 기간을 구성할 수 있습니다.

상승된 권한 기간 계산#

Teleport는 다음 로직을 사용하여 사용자의 상승된 권한 기간을 계산합니다:

  1. 접근 요청이 승인된 경우 상승된 권한의 최대 기간을 계산합니다. 다음 중 가장 낮은 값입니다:
    • tsh request create 명령의 --max-duration 플래그(요청을 만드는 사용자가 이 플래그를 제공하는 경우).
    • 사용자의 요청된 역할 중 하나에 포함된 request.max_duration 필드의 가장 낮은 값.
  2. Teleport가 접근 요청을 승인한다면 사용자가 받을 인증서의 세션 TTL을 계산합니다. 이 계산은 다음 중 가장 낮은 값을 선택합니다:
    • 요청된 세션 만료 시간으로 tsh request create의 --session-ttl 플래그 값.
    • 사용자의 현재 Teleport 세션의 남은 시간.
    • 사용자의 요청된 역할에서 options.max_session_ttl 필드의 가장 낮은 값.
  3. 최대 기간이 0보다 크면 상승된 권한의 기간을 최대 기간 또는 앞서 계산한 세션 TTL 중 더 짧은 것으로 설정합니다. 그렇지 않으면 세션 TTL로 설정합니다.

사용자가 상승된 권한을 가정할 수 있는 시기 설정#

접근 요청을 만들거나 검토할 때 --assume-start-time 플래그를 사용하여 사용자가 상승된 권한을 가정할 수 있는 가장 이른 시간을 지정할 수 있습니다. 이 플래그는 tsh request create 및 tsh request review 명령에서 사용할 수 있습니다. 허용되는 형식은 RFC 3339에 정의되어 있습니다. 예: 2023-12-12T23:20:50.52Z. 지정된 시간은 미래여야 합니다.

검토자는 접근 요청을 승인할 때 이 시간을 재정의할 수 있습니다. 여러 검토자가 시작 시간을 재정의하면 가장 최근 재정의가 선택됩니다.

request.max_duration 필드#

max_duration 옵션은 특정 역할에 대해 사용자가 상승된 권한을 가질 수 있는 최대 기간을 나타냅니다. 사용자가 성공적인 접근 요청을 만든 후 최대 기간이 경과할 때까지 상승된 접근으로 Teleport에 인증할 수 있습니다.

사용자가 Teleport에 인증할 때마다 Teleport는 이전 섹션에서 설명한 공식을 사용하여 사용자의 Teleport 세션 TTL을 계산합니다. 사용자는 최대 기간이 경과하기 전에 여러 세션으로 상승된 권한을 가질 수 있습니다.

다음과 같은 역할로 max_duration 옵션을 지정할 수 있습니다:

kind: role
version: v7
metadata:
  name: temp-dba
spec:
  allow:
    request:
      # Allow access to role `dba` for up to 4 days.
      roles: ['dba']
      max_duration: 4d

max_duration의 값은 14일을 초과할 수 없습니다.

접근 요청의 유효 기간#

Teleport는 다음 로직을 사용하여 접근 요청이 승인을 기다리는 동안 얼마나 유효한지를 결정합니다:

  1. tsh request create 명령의 --request-ttl 플래그로 사용자가 설정할 수 있는 접근 요청의 기본 만료로 시작합니다. 설정되지 않은 경우 요청 TTL은 1시간입니다.
  2. 사용자의 Teleport 세션이 기본 만료 시간 전에 만료될 경우, Teleport는 접근 요청 만료를 Teleport 세션 종료로 설정합니다.
  3. 접근 요청에서 요청된 Teleport 역할 중 하나의 options.max_session_ttl이 만료 시간 전에 만료되면 Teleport는 접근 요청의 만료를 해당 시간으로 설정합니다.
  4. --request-ttl 값이 이전 단계에서 계산된 요청 TTL보다 크면 오류를 반환합니다.

클라이언트의 접근 요청 방법#

사용자의 Teleport 역할은 접근 요청을 제출하는 방법, 접근 요청이 선택 사항인지 필수 사항인지, 요청 시 이유를 제공해야 하는지를 결정합니다.

역할의 options.request_access 설정은 접근 요청을 생성하는 전략을 지정합니다. 다음 값 중 하나를 포함할 수 있습니다:

값 의미
optional 기본값. 사용자는 요청할 때 이유를 지정할 필요가 없습니다. 사용자는 Teleport에 로그인할 때 수동으로 요청을 시작해야 합니다.
always 사용자가 Teleport에 로그인할 때 클라이언트는 이유 없이 사용자에게 사용 가능한 모든 역할에 대한 접근 요청을 자동으로 생성합니다.
reason 사용자가 Teleport에 로그인할 때 클라이언트는 사용자에게 사용 가능한 모든 역할에 대한 접근 요청을 자동으로 생성합니다. 사용자는 인증 시 이유를 제공해야 합니다.

역할에 reason 전략이 포함된 경우, 사용자가 이유 없이 접근 요청을 만들려고 할 때 이유를 제공하도록 상기시키는 프롬프트를 지정할 수 있습니다. 이를 위해 역할의 options.request_prompt 옵션을 설정합니다.

예를 들어, 다음 역할은 "Please provide your ticket ID"라는 텍스트로 사용자에게 프롬프트를 표시합니다:

kind: role
version: v7
metadata:
  name: employee
spec:
  allow:
    request:
      roles:
        - 'dba'
  options:
    request_access: reason
    request_prompt: Please provide your ticket ID

Teleport Auth Service는 다음 로직을 사용하여 사용자에게 속한 다른 역할의 request_access 필드에 지정된 전략을 결합합니다:

  1. 사용자의 역할 중 하나에 reason 또는 always 전략이 포함된 경우, Teleport는 사용자가 인증할 때 사용자에게 사용 가능한 모든 역할을 자동으로 요청합니다.
  2. 사용자의 역할 중 하나에 reason 전략이 포함된 경우, 사용자는 인증 시 이유를 제공해야 합니다.

요청 이유 요구#

spec.allow.request.reason.mode 필드는 사용자가 접근 요청을 제출할 때 이유가 필요한지를 제어합니다.

허용되는 값:

값 의미
optional 기본값. 사용자는 요청할 때 이유를 제공할 필요가 없습니다.
required 사용자는 요청할 때 비어 있지 않은 이유를 제공해야 합니다.

spec.allow.request.reason.prompt를 사용하여 특정 요청 가능한 역할이나 리소스에 대해 이유를 제공하도록 상기시키는 범위가 지정된 프롬프트를 지정할 수 있습니다.

예시:

kind: role
version: v7
metadata:
  name: node-requester
spec:
  allow:
    request:
      roles:
        - 'node-access'
      search_as_roles:
        - 'root-node-access'
      reason:
        mode: 'required'
        prompt: 'Please give a reason for accessing node resources'

node-requester 역할이 할당된 사용자가 node-access 역할이나 root-node-access에서 허용하는 리소스에 대한 접근 요청을 만들면 이유를 제공해야 합니다. 사용자의 역할 세트에 동일한 역할 및 리소스에 대한 접근 요청을 제어하는 여러 역할이 포함된 경우, required 모드가 우선합니다.

커스텀 요청 이유 프롬프트#

사용자에 대한 커스텀 요청 프롬프트를 지정할 수 있습니다:

  • 단일 역할로 지정된 요청 가능한 리소스 또는 역할에 대해
  • 사용자가 만드는 모든 접근 요청에 대해

단일 역할로 지정된 요청 가능한 리소스에 대한 범위가 지정된 프롬프트를 지정하려면 spec.allow.request.reason.prompt를 비어 있지 않은 문자열로 설정합니다. 이는 특정 리소스 또는 역할을 포함하는 접근 요청에만 영향을 미칩니다.

커스텀 글로벌 요청 프롬프트는 spec.options.request_prompt를 비어 있지 않은 문자열로 설정하여 사용자에게 역할을 할당함으로써 지정할 수 있습니다. 이 글로벌 프롬프트는 사용자가 만드는 모든 접근 요청에 적용됩니다.

동일한 접근 요청에 여러 글로벌 프롬프트와 범위가 지정된 프롬프트가 적용되면, 모든 프롬프트가 요청 이유 양식에서 알파벳 순서로 나열됩니다.

예시:

kind: role
version: v7
metadata:
  name: k8s-requester
spec:
  allow:
    request:
      search_as_roles:
        - 'k8s-viewer'
      reason:
        # If a user is assigned this role, the prompt below will be displayed
        # when any resource allowed by k8s-viewer role is requested.
        prompt: 'Please give a reason for accessing kubernetes resources'

kind: role
version: v7
metadata:
  name: employee
spec:
  allow: {}
  options:
    # If a user is assigned this role, the prompt below will be displayed for
    # all access requests made by this user.
    request_prompt: 'Please provide your ticket ID'

k8s-requester 및 employee 역할이 할당된 사용자가 k8s-viewer로 검색 가능한 리소스에 대한 접근 요청을 만들면, "Please give a reason for accessing kubernetes resources"라는 텍스트가 첫 번째 줄에, "Please provide your ticket ID"가 두 번째 줄에 알파벳 순서로 프롬프트됩니다.

검토 임계값#

접근 요청이 Teleport에 의해 승인되거나 거부되기 전에 충족해야 하는 기준을 지정하도록 사용자의 역할을 구성할 수 있습니다. 이를 위해 allow.request.thresholds 필드를 구성합니다.

allow.request.thresholds 필드#

다음은 요청 가능한 역할에 대한 검토 임계값을 지정하는 역할 예시입니다:

kind: role
version: v7
metadata:
  name: devops
spec:
  allow:
    request:
      roles: ['dbadmin']
      thresholds:
        - approve: 3
          deny: 2
          filter: '!contains(reviewer.traits.team, "dev")'
        - approve: 1
          deny: 1
          filter: 'contains(reviewer.roles, "admin")'

해당 deny.requests.thresholds 필드가 없으며, Teleport는 그것을 포함하는 역할을 거부합니다.

각 임계값에는 다음 필드가 포함됩니다:

필드 설명
approve 접근 요청을 승인하기 위해 승인해야 하는 검토자의 수. 기본값은 1.
deny 접근 요청을 거부하기 위해 거부해야 하는 검토자의 수. 기본값은 1.
filter 검토가 임계값의 승인 또는 거부 횟수에 추가되기 전에 접근 요청 또는 검토가 충족해야 하는 조건. 다음 섹션에서 더 자세히 설명됩니다.

위의 devops 역할에서는 dbadmin 역할과 관련된 두 개의 임계값이 있습니다. 결과적으로 요청이 승인되거나 거부되기 전에 다음 조건 중 하나가 충족되어야 합니다:

  1. 세 명의 사용자가 요청을 승인하고 두 명의 사용자가 거부해야 하며, 이 사용자들은 dev 값을 가진 team 트레잇을 가지지 않아야 합니다.
  2. 한 명의 사용자가 검토를 승인하고 한 명의 사용자가 거부해야 하며, 검토를 제출하는 사용자는 admin 역할을 가져야 합니다.

임계값 필터#

Teleport가 특정 역할에 대한 접근 요청을 처리할 때, 요청이 해당 역할과 관련된 allow.request.thresholds의 임계값 중 하나에 지정된 기준을 충족했는지 확인합니다.

filter 값은 Teleport 조건 언어를 사용하는 표현식입니다.

예를 들어, 다음 구성에는 4개의 임계값이 포함되어 있으며, 그 중 3개에는 필터가 있습니다:

spec:
  allow:
    request:
      roles: ['dbadmin']
      thresholds:
        - approve: 3
          deny: 1
        - filter: 'contains(reviewer.roles, "super-approver")'
          approve: 2
          deny: 1
        - filter: '!equals(request.reason, "") && contains(reviewer.roles, "super-approver")'
          approve: 1
          deny: 1
        - filter: 'regexp.match(request.reason, "^Ticket [0-9]+.*$") && !equals(review.reason, "")'
          approve: 1
          deny: 1

첫 번째 임계값은 세 명의 사용자가 승인하고 한 명의 사용자가 거부해야 합니다. 그러나 각 검토자가 super-approver 역할을 가지고 있으면 두 번의 승인만 필요합니다. 요청에 비어 있지 않은 이유가 있으면 super-approver 역할을 가진 사용자로부터 한 번의 승인만 필요합니다. 요청의 이유가 정규식 ^Ticket [0-9]+.*$와 일치하면 검토자가 비어 있지 않은 이유를 제공하는 한 어떤 검토자로부터도 한 번의 승인만 필요합니다.

필터 표현식은 각 접근 요청 검토와 관련된 다음 데이터를 활용할 수 있습니다: 요청, 검토자, 검토 자체:

필드 유형 설명
reviewer.roles []string 검토자의 역할.
reviewer.traits map[string][]string 검토자의 트레잇.
review.reason string 검토에 제공된 이유.
review.annotations map[string][]string 검토에 추가된 주석. 접근 요청을 승인하거나 거부하는 프로그래밍 방식의 Teleport 클라이언트가 추가합니다.
request.roles []string 요청에 포함된 역할.
request.reason string 요청에 제공된 이유.
request.system_annotations map[string][]string 요청 주석.

다음 연산자와 함수를 포함하는 표현식에서 이러한 필드를 사용할 수 있습니다:

연산자/함수 설명
equals(val1,val2) val1이 val2와 같으면 true, 그렇지 않으면 false를 반환합니다.
contains(list, item) list에 item과 정확히 일치하는 항목이 포함되어 있으면 true를 반환합니다.
regexp.match(list, re) list에 re와 일치하는 항목이 포함되어 있으면 true를 반환합니다.
expr1 && expr2 expr1과 expr2 모두 true로 평가되면 true로 평가됩니다.
expr1 || expr2 expr1, expr2 또는 둘 다 true로 평가되면 true로 평가됩니다.
!expr expr을 부정합니다.

위에서 list라는 인수는 값 목록(예: request.roles) 또는 단일 값(예: request.reason)을 허용할 수 있습니다.

regexp.match에 대한 re 인수는 글로브 스타일 와일드카드(* 문자)와 Go 스타일 정규 표현식을 모두 지원합니다. 표현식이 ^ 문자로 시작하고 $ 문자로 끝나면 Teleport는 이를 정규 표현식으로 평가합니다. 그렇지 않으면 와일드카드 표현식으로 평가합니다. 와일드카드는 0개 이상의 문자 시퀀스와 일치합니다.

제안된 검토자#

제안된 검토자를 접근 요청에 제안하도록 Teleport 역할을 구성할 수 있습니다.

Teleport는 사용자의 역할에 있는 allow.request.suggested_reviewers 필드에 명시된 모든 검토자를 결합합니다. 접근 요청에 제안된 검토자가 없으면 Teleport는 사용자의 제안된 검토자를 요청에 추가합니다.

다음 역할은 제안된 검토자로 user1과 user2를 추가합니다:

kind: role
version: v7
metadata:
  name: employee
spec:
  allow:
    request:
      roles:
        - 'dev'
        - 'dba'
      suggested_reviewers:
       - 'user1'
       - 'user2'

제안된 검토자는 제안된 검토자와 동일한 role 리소스에 명시된 역할뿐만 아니라 사용자가 접근을 요청할 수 있는 모든 역할에 적용됩니다.

Teleport는 비어 있지 않은 deny.request.suggested_reviewers 필드가 있는 역할을 수락하지만 접근 요청을 평가할 때 allow.request.suggested_reviewers 필드만 고려합니다.

제안된 검토자로서의 접근 목록 소유자#

Teleport는 접근 요청 생성 시 접근 목록 소유자를 자동으로 검토자로 제안할 수 있습니다.

Teleport는 두 가지 경우에 이를 수행합니다:

요청을 접근 목록으로 승격할 수 있는 경우#

리소스 기반 접근 요청의 경우, 요청된 리소스에 대한 접근을 부여하는 접근 목록의 소유자가 제안된 검토자로 자동으로 추가될 수 있습니다.

접근 목록의 소유자는 다음 조건이 충족될 때 제안됩니다.

  • 요청자가 아직 접근 목록의 멤버가 아닌 경우.
  • 요청자가 접근 목록에 가입할 자격이 있는 경우.
  • 접근 목록이 요청된 모든 리소스에 대한 접근을 부여하는 경우.

요청자가 이미 해당 접근 목록의 멤버인 경우#

해당 접근 목록의 소유자도 요청자가 이미 접근 목록의 멤버인 경우 제안된 검토자로 자동으로 추가될 수 있습니다.

접근 목록의 소유자는 다음 조건이 충족될 때 제안됩니다.

  • 요청자가 이미 접근 목록의 멤버인 경우.
  • 접근 목록을 접근 요청에 적용할 수 있는 경우.
  • 접근 목록 소유자가 요청된 역할에 대한 요청을 검토할 수 있도록 허용된 경우.

단기 요청의 경우, 접근 목록의 멤버 권한에 요청된 역할 중 하나를 요청할 수 있는 역할이 포함되어 있으면 접근 목록이 적용 가능합니다.

장기 요청의 경우, 접근 목록이 요청된 역할 중 하나를 직접 부여하면 접근 목록이 적용 가능합니다.

리소스 요청의 경우, 이는 접근 목록이 요청된 리소스에 대한 접근을 부여하는 역할을 요청할 수 있는 역할을 부여함을 의미합니다.

두 경우 모두 이 소유자들은 여전히 그러한 접근 요청을 검토할 수 있도록 허용하는 적절한 Teleport 역할이 있어야 합니다.

이러한 사용 사례에 대한 자세한 내용은 접근 요청 검토 가이드에서 확인할 수 있습니다.

검토자가 접근을 부여할 수 있는 역할#

Teleport 사용자는 특정 역할에 대한 접근 요청을 검토할 권한이 있어야 합니다. 일부 Teleport 역할에 대한 접근 요청을 검토할 수 있도록 사용자의 Teleport 역할을 구성하고 다른 역할에 대한 요청 검토 능력을 거부할 수 있습니다.

특정 역할에 대한 검토 허용 및 거부#

특정 역할에 대한 요청은 검토할 수 있지만 다른 역할은 검토할 수 없도록 하려면 다음 역할 필드를 편집하세요:

  • allow.review_requests.roles
  • allow.review_requests.claims_to_roles
  • deny.review_requests.roles
  • deny.review_requests.claims_to_roles

Auth Service는 사용자의 트레잇으로 템플릿 표현식을 사용하여 claims_to_roles 필드를 평가합니다.

사용자가 특정 역할에 대한 접근 요청을 검토하려면 최소 하나의 허용 규칙이 사용자에게 해당 역할에 대한 요청 검토 접근을 부여해야 합니다. 해당 역할 검토 접근을 허용하지 않는 거부 규칙이 없어야 합니다.

where 표현식#

requests.roles 및 requests.claims_to_roles 필드와 달리, review_requests.roles 및 review_requests.claims_to_roles 필드를 사용하면 where 표현식에 따라 역할의 접근 요청을 검토하는 권한을 부여하거나 거부할 수 있습니다. 표현식이 접근 요청에 대해 성립하면 Teleport는 review_requests_claims_to_roles 및 review_requests.roles 필드에 대한 허용 또는 거부 규칙을 적용합니다.

예를 들어, 다음 구성은 역할이 contractor-prod이고 요청 이유가 비어 있지 않는 한 검토자가 모든 역할에 대한 요청을 검토할 수 있도록 허용합니다:

metadata:
  name: reviewer
# ...
allow:
  review_requests:
    roles: ['*']
deny:
  review_requests:
    roles: ['contractor-prod']
    where: 'request.reason == ""'

접근 요청 검토를 검증할 때 Teleport는 검토자의 모든 역할에 있는 각 where 표현식을 고려합니다. 하나의 where 표현식이 검토에 대해 성립하면 Teleport는 검토자가 해당 where 표현식과 동일한 Teleport 역할에 정의된 해당 역할에 대한 요청을 검토할 권한이 있는지 확인합니다.

예를 들어 사용자가 contractor-prod 역할을 요청하고 요청에 빈 이유를 남기면, 위에서 정의한 reviewer 역할을 가진 사용자는 요청을 검토할 수 없습니다.

where 표현식은 접근 요청과 관련된 다음 데이터를 활용할 수 있습니다:

필드 유형 설명
reviewer.roles []string 검토자의 Teleport 역할.
reviewer.traits map[string][]string 검토자의 Teleport 트레잇.
request.roles []string 접근 요청에서 요청된 역할.
request.reason string 요청 이유.
request.system_annotations map[string][]string 요청 주석.

다음 연산자와 함수를 포함하는 표현식에서 이러한 필드를 사용할 수 있습니다:

연산자/함수 설명
equals(val1,val2) val1이 val2와 같으면 true, 그렇지 않으면 false를 반환합니다.
contains(list, item) list에 item과 정확히 일치하는 항목이 포함되어 있으면 true를 반환합니다.
regexp.match(list, re) list에 re와 일치하는 항목이 포함되어 있으면 true를 반환합니다.
expr1 && expr2 expr1과 expr2 모두 true로 평가되면 true로 평가됩니다.
expr1 || expr2 expr1, expr2 또는 둘 다 true로 평가되면 true로 평가됩니다.
!expr expr의 반대로 평가됩니다.

위에서 list라는 인수는 값 목록(예: request.roles) 또는 단일 값(예: request.reason)을 허용할 수 있습니다.

regexp.match에 대한 re 인수는 글로브 스타일 와일드카드(* 문자)와 Go 스타일 정규 표현식을 모두 지원합니다. 표현식이 ^ 문자로 시작하고 $ 문자로 끝나면 Teleport는 이를 정규 표현식으로 평가합니다. 그렇지 않으면 와일드카드 표현식으로 평가합니다. 와일드카드는 0개 이상의 문자 시퀀스와 일치합니다.

요청된 리소스 검사#

Teleport 사용자는 리소스에 접근하지 않고 해당 리소스에 대한 정보를 볼 수 있습니다. 이는 다른 사용자의 접근 요청을 승인하여 사용자에게 접근을 부여하기 전에 리소스를 검사하는 데 유용합니다.

리소스에 접근하지 않고 Teleport 리소스를 나열하는 사용자 능력을 부여하거나 거부하려면 사용자의 역할에서 allow.review_requests.preview_as_roles 및 deny.review_requests.preview_as_roles 필드를 사용합니다:

kind: role
version: v7
metadata:
  name: reviewer
spec:
  allow:
    review_requests:
      roles:
        - access
      preview_as_roles:
        - access

사용자가 tsh ls 명령을 사용하는 등 Teleport 리소스를 나열하려고 할 때, Teleport Auth Service는 사용자의 preview_as_roles가 리소스를 나열하는 접근을 부여하는지 확인하고, 그렇다면 리소스를 나열합니다. 이는 배포 및 파드와 같이 Teleport로 보호된 Kubernetes 리소스를 나열하려는 사용자에게도 적용됩니다.

리소스를 미리 볼 수 없으면 검토자는 접근 요청에서 제공한 리소스의 UUID만 볼 수 있습니다.

요청 주석#

사용자가 접근 요청을 만들 때 Teleport Auth Service는 임의의 메타데이터를 요청에 쓸 수 있습니다. 접근 요청을 사용하는 Teleport 통합은 메타데이터를 읽어 동작을 지시할 수 있습니다.

주석은 단일 키가 값 목록에 해당하는 키-값 쌍입니다. 모든 값은 문자열입니다.

요청 주석을 지원하는 플러그인#

다음 Teleport 지원 접근 요청 플러그인은 요청 주석을 읽습니다:

통합 주석 키 주석 사용 방법
Pagerduty pagerduty_notify_service, pagerduty_services 사용자가 접근 요청을 제출할 때 pagerduty_notify_service에 명시된 서비스에서 인시던트를 엽니다. 사용자가 pagerduty_services에 명시된 서비스의 온콜 로테이션에 있으면 Teleport는 해당 사용자가 열린 접근 요청을 자동으로 승인합니다.
Opsgenie teleport.dev/notify-services, teleport.dev/schedules 통합은 사용자가 teleport.dev/schedules에 나열된 서비스 중 하나에 온콜인 경우 사용자의 접근 요청을 승인합니다. 또한 사용자가 접근 요청을 만들 때 teleport.dev/notify-services에 명시된 서비스에서 알림을 만듭니다.
ServiceNow teleport.dev/notify-services, teleport.dev/schedules 통합은 사용자가 teleport.dev/schedules에 나열된 서비스 중 하나에 온콜인 경우 사용자의 접근 요청을 승인합니다. 또한 사용자가 접근 요청을 만들 때 teleport.dev/notify-services에 명시된 서비스에서 알림을 만듭니다.

주석 허용 및 거부#

Teleport Auth Service는 다음 로직을 적용하여 사용자의 역할에서 접근 요청 주석을 평가합니다: 주어진 키가 있는 모든 허용된 주석 값에 대해, 동일한 키의 거부된 주석 값도 있는지 확인합니다. 있으면 건너뜁니다. 그렇지 않으면 주석을 접근 요청에 추가합니다.

예를 들어, 다음 필드가 있는 역할을 정의했다고 가정해 보겠습니다:

allow:
  request:
    annotations:
      pagerduty_services:
        - data-writer
        - data-reader

또한 다음 필드가 있는 역할을 정의했습니다:

deny:
  request:
    annotations:
      pagerduty_services:
        - data-reader

이 경우 사용자의 접근 요청에 대한 최종 주석 매핑에는 다음 주석이 포함됩니다:

pagerduty_services:
 - data-writer

커스텀 플러그인에서 주석 읽기#

자체 접근 요청 플러그인을 작성하는 경우, 프로그램은 다음과 유사한 함수를 사용하여 시스템 주석에 접근할 수 있습니다:

func getMyAnnotation(req types.AccessRequest) ([]string, error) {
	result, ok := req.GetSystemAnnotations()["my-annotation"]
	if !ok {
		return nil, trace.NotFound("annotation not found")
	}
	return result, nil
}

이 함수는 types.AccessRequest 유형의 GetSystemAnnotations 메서드를 사용하여 키 my-annotation이 있는 접근 요청의 모든 주석 값을 가져옵니다.

추가 읽기#

Teleport 역할 내의 구성 옵션에 대한 전체 설명은 접근 제어 레퍼런스를 참조하세요.