이 가이드는 Teleport 액세스 요청을 구성할 때 고려해야 할 사항을 설명합니다. 액세스 요청을 사용하면 Teleport 사용자가 동일한 Teleport 클러스터의 하나 이상의 사용자로부터 승인을 받아 권한을 상승시킬 수 있습니다.

액세스 요청은 역할별로 구성 가능합니다. 사용자가 Teleport에 인증하면 단일 사인온 공급자를 통해 인증하더라도 Teleport Auth 서비스는 해당 사용자의 모든 역할을 조정하여 해당 사용자의 액세스 요청 구성을 결정합니다. 그런 다음 Teleport는 사용자가 생성한 모든 액세스 요청에 이 구성을 적용합니다.

전체 액세스 요청 라이프사이클에 대한 예시는 다음의 가이드 중 하나를 따르십시오:

• 상업용 Teleport 에디션의 역할 요청
• 상업용 Teleport 에디션의 리소스 요청
• Teleport 커뮤니티 에디션의 역할 요청

사용자가 요청할 수 있는 액세스

기본적으로 Teleport 사용자는 권한 상승 요청을 할 수 없습니다. 사용자가 요청할 수 있는 상승된 액세스를 구성하려면 다음과 같은 Teleport 역할을 정의할 수 있습니다:

• 사용자가 요청할 수 있는 다른 Teleport 역할을 지정합니다.
• 사용자가 요청할 리소스를 검색하기 위해 사용할 수 있는 다른 Teleport 역할을 지정합니다. 예를 들어, 데이터베이스 또는 Kubernetes 클러스터와 같은 리소스입니다.

또한 Teleport 역할을 구성하여 사용자가 이러한 역할에 대한 액세스를 요청하는 것을 방지할 수 있습니다.

역할 요청 제한

사용자가 액세스 요청을 제출할 때 그들은 요청할 역할을 지정할 수 있습니다.

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

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

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

kind: 역할
version: v6
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 서비스는 사용자의 모든 역할에 대한 이러한 필드의 값을 두 개의 역할 일치 목록으로 결합합니다:

• 거부: 요청된 역할이 이 중 하나와 일치하면 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 역할과 일치할 수 있습니다.

claims_to_roles의 값을 역할 일치 목록에 추가하기 위해 Auth 서비스는 사용자의 특성을 사용하여 템플릿 표현식을 평가합니다. claims_to_roles 필드에서 사용자 특성으로 템플릿 표현식을 실행하는 방법에 대한 자세한 내용은 역할 템플릿을 참조하시기 바랍니다.

위의 employee 역할에서 사용자가 admins 그룹에 있는 경우(단일 사인온 공급자가 선언한 대로), 이 역할은 그들이 모든 역할에 대한 액세스를 요청하는 것을 허용합니다. 그들이 contractors 그룹에 있는 경우, 이 역할은 그들이 모든 역할 요청을 거부합니다.

리소스 요청 제한

사용자들은 또한 특정 Teleport 리소스에 대한 액세스 요청을 제출할 수 있습니다.

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

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

예를 들어, 다음 역할은 사용자가 k8s-viewer 역할이 허용하는 리소스를 검색할 수 있도록 합니다.

# requester.yaml
kind: 역할
version: v6
metadata:
  name: k8s-requester
spec:
  allow:
    request:
      search_as_roles:
        - k8s-viewer

역할 요청 구성와 대조적으로, request.search_as_roles 필드는 리터럴 역할 이름 목록만 포함하며, 와일드카드 또는 정규 표현식을 지원하지 않습니다.

Teleport Auth 서비스는 사용자의 모든 Teleport 역할에 대한 이러한 필드의 값을 결합하여 사용자의 액세스 요청을 검증합니다.

사용자가 Teleport 리소스를 나열하려고 할 때(예: 서버 및 데이터베이스) 또는 Kubernetes 리소스(예: 포드 및 배포)를 나열하려고 할 때, Auth 서비스는 사용자가 검색할 수 있는 역할을 검사합니다. 사용자의 Teleport 역할 또는 search_as_roles에 지정된 역할이 사용자가 리소스를 검색할 수 있도록 허용하는 경우, Teleport Auth 서비스는 리소스에 대한 정보를 반환합니다.

사용자가 리소스 ID에 대한 액세스를 요청할 때, Teleport Auth 서비스는 다음 작업을 수행합니다:

1. allow.request.search_as_roles에 명명된 모든 역할을 수집하고, deny.request.search_as_roles 또는 deny.request.roles에 지정된 역할을 제외합니다.
2. 나머지 역할 중 어떤 역할이 요청된 리소스에 액세스할 수 있는지를 결정합니다. 리소스 액세스 요청이 유효하기 위해서는 사용자의 search_as_roles 구성에 나열된 역할 중 하나가 요청된 리소스에 대한 액세스를 허용해야 합니다.

액세스 지속 시간

사용자가 승인된 액세스 요청에 대한 상승된 권한을 유지하는 시간을 구성할 수 있습니다.

상승된 권한의 지속 기간 계산

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: 역할
version: v6
metadata:
  name: temp-dba
spec:
  allow:
    request:
      # `dba` 역할에 최대 4일 동안 액세스를 허용합니다.
      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 설정은 액세스 요청을 생성할 전략을 지정합니다. 다음 값 중 하나를 포함할 수 있습니다:

역할에 reason 전략이 포함된 경우, 사용자가 이유 없이 액세스 요청을 생성하려고 할 때 이유를 제공하라는 프롬프트를 지정할 수 있습니다. 역할에서 options.request_prompt 옵션을 설정하여 이를 수행합니다.

예를 들어, 다음 역할은 사용자에게 "티켓 ID를 제공해주세요"라는 텍스트로 프롬프트를 표시합니다:

kind: 역할
version: v6
metadata:
  name: employee
spec:
  allow:
    request:
      roles:
        - 'dba'
  options:
    request_access: reason
    request_prompt: "티켓 ID를 제공해주세요"

Teleport Auth 서비스는 사용자의 여러 역할의 request_access 필드에 지정된 전략을 결합하는 다음 논리를 사용합니다:

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

검토 기준

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

allow.request.thresholds 필드

다음은 요청 가능한 역할에 대한 검토 기준을 지정하는 역할의 예입니다:

kind: 역할
version: v6
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는 이를 포함하는 역할을 거부합니다.

각 기준은 다음 필드를 포함합니다:

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

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

기준 필터

Teleport는 특정 역할에 대한 액세스 요청을 처리할 때 요청이 해당 역할과 연관된 allow.request.thresholds의 기준 중 하나에서 지정된 기준을 충족했는지를 확인합니다.

filter의 값은 Teleport 프레디케이트 언어를 사용하는 표현식입니다.

예를 들어, 다음 구성은 네 개의 기준을 포함하며, 그 중 세 개는 필터가 있습니다:

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]+.*$와 일치하면, 어떤 검토자가 비어 있지 않은 이유를 제공하는 한, 단 하나의 승인이 필요합니다.

필터 표현식은 다음과 같은 데이터에 접근할 수 있습니다

표현식에는 다음 연산자 및 함수가 포함될 수 있습니다:

위의 섹션에서 list라는 인수는 request.roles와 같은 값 목록이나 request.reason과 같은 단일 값을 수용할 수 있습니다.

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

제안된 검토자

Teleport 역할을 구성하여 액세스 요청에 대한 제안된 검토자를 제안할 수 있습니다.

Teleport는 사용자의 역할의 allow.request.suggested_reviewers 필드에 나열된 모든 검토자를 결합합니다. 액세스 요청에 제안된 검토자가 없는 경우, Teleport는 사용자의 제안된 검토자를 요청에 추가합니다.

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

kind: 역할
version: v6
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 역할에 대한 요청을 검토하도록 허용하고 다른 역할에 대한 요청을 검토할 수 있는 권한을 거부할 수 있습니다.

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

특정 역할에 대한 요청을 검토할 수 있도록 사용자를 허용하지만 다른 역할에 대해서는 허용하지 않으려면, 다음 역할 필드를 편집하세요:

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

Auth 서비스는 사용자의 특성으로 템플릿 표현식을 사용하여 claims_to_roles 필드를 평가합니다. 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 역할을 요청하고 요청에 빈 이유를 남기는 경우, 위에서 정의한 사용자는 요청을 검토할 수 없습니다.

where 표현식은 액세스 요청과 관련된 다음 데이터에 접근할 수 있습니다:

이러한 필드를 사용하여 다음과 같은 연산자 및 함수를 포함하는 표현식을 작성할 수 있습니다:

위의 섹션에서 list라는 인수는 request.roles와 같은 값 목록이나 request.reason과 같은 단일 값을 수용할 수 있습니다.

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

요청 주석

사용자가 액세스 요청을 생성할 때 Teleport Auth 서비스는 요청에 임의의 메타데이터를 기록할 수 있습니다. 액세스 요청을 사용하는 Teleport 통합은 메타데이터를 읽어 따라 행동할 수 있습니다.

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

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

다음은 요청 주석을 읽는 Teleport 지원 액세스 요청 플러그인입니다:

주석 허용 및 거부

Teleport Auth 서비스는 사용자의 역할에서 액세스 요청 주석을 평가할 때 다음 논리를 적용합니다: 주어진 키에 대한 모든 허용된 주석 값을 확인하고, 동일한 키에 대한 거부된 주석 값이 있는 경우 이를 건너뜁니다. 그렇지 않으면 주석을 액세스 요청에 추가합니다.

예를 들어, 다음 필드가 정의된 역할이 있다고 가정합니다:

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 메서드를 사용합니다.

추가 참고 자료

Teleport 역할의 구성 옵션에 대한 전체 설명은 액세스 제어 참조를 참조하십시오.