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

액세스 요청은 역할별로 구성 가능합니다. 사용자가 Teleport에 인증하면, 단일 SSO 공급자를 통해 인증된 경우에도 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: role
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 필드에서 Teleport가 사용자의 특성을 사용하여 템플릿 표현식을 실행하는 방법에 대한 자세한 내용은 역할 템플릿을 참조하세요.

위의 employee 역할에서 사용자가 admins 그룹에 속해 있다면(SSO 공급자가 선언한 대로), 이 역할은 그들이 모든 역할에 대한 액세스를 요청할 수 있도록 허용합니다. 만약 그들이 contractors 그룹에 속해 있다면, 이 역할은 그들이 어떤 역할도 요청할 수 없도록 거부합니다.

리소스 요청 제한

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

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

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

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

# requester.yaml
kind: role
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는 사용자가 승인된 접근 요청에 대해 상승된 권한을 부여받는 기간을 구성할 수 있습니다.

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

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: v6
metadata:
  name: temp-dba
spec:
  allow:
    request:
      # 최대 4일 동안 `dba` 역할에 대한 액세스를 허용합니다.
      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: role
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: role
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. 세 명의 사용자가 요청을 승인해야 하며, 두 명의 사용자가 거부해야 하며, 이 사용자들은 team 특성이 dev 값을 가져서는 안 됩니다.
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: role
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

인증 서비스는 사용자의 특성을 사용하여 claims_to_roles 필드를 템플릿 표현을 사용하여 평가합니다. Teleport가 사용자의 특성으로 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 표현식은 액세스 요청과 관련된 다음 데이터를 활용할 수 있습니다:

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

위의 경우, 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: v6
metadata:
  name: reviewer
spec:
  allow:
    review_requests:
      roles:
        - access
      preview_as_roles:
        - access

사용자가 tsh ls 명령어를 사용하여 Teleport 리소스를 나열하려고 할 때, Teleport Auth 서비스는 사용자의 preview_as_roles 가 리소스를 나열할 수 있는지 확인하고, 그렇다면 리소스를 나열합니다. 이는 Kubernetes 리소스를 나열하려고 시도하는 사용자에게도 적용되며, 여기에는 Teleport로 보호된 배포 및 파드가 포함됩니다.

리소스를 미리 볼 수 있는 권한이 없으면, 리뷰어는 접근 요청에서 제공된 리소스의 UUID만 볼 수 있습니다.

요청 주석

사용자가 접근 요청을 생성하면, 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

사용자 정의 플러그인에서 주석 읽기

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

func getMyAnnotation(req types.AccessRequest) ([]string, error) {
	result, ok := req.GetSystemAnnotations()["my-annotation"]
	if !ok {
		return nil, trace.NotFound("주석을 찾을 수 없음")
	}
	return result, nil
}

이 함수는 types.AccessRequest 타입의 GetSystemAnnotations 메서드를 사용하여 my-annotation 키를 가진 Access Requests의 모든 주석 값을 가져옵니다.

추가 자료

Teleport 역할 내 구성 옵션에 대한 전체 설명은 Access Controls Reference를 참조하십시오.