Teleport 리소스 접근 요청을 사용하면 사용자는 내부적으로 사용되는 역할이나 RBAC 제어에 대해 아무것도 알 필요 없이 특정 리소스에 대한 접근을 요청할 수 있습니다. 사용자가 상승된 역할을 직접 요청하는 역할 접근 요청과 달리, 리소스 접근 요청을 사용하면 사용자가 필요한 개별 리소스를 식별하고 Teleport가 접근을 제공하기 위해 부여할 역할을 결정합니다.

접근 요청 API를 사용하면 이러한 요청을 동적으로 승인하거나 거부하기 쉽습니다. 리소스 접근 요청은 Teleport Web UI, Teleport Connect 또는 tsh CLI를 통해 생성할 수 있습니다.

Just-in-time 접근 요청은 Teleport Enterprise의 기능입니다. Teleport Community Edition 사용자는 Teleport CLI를 통해 역할을 요청하여 접근 요청 작동 방식을 미리 볼 수 있습니다. 리소스 접근 요청 및 직관적이고 검색 가능한 UI를 포함한 전체 접근 요청 기능은 Teleport Enterprise에서 사용 가능합니다.

전제 조건#

• 실행 중인 Teleport Enterprise 클러스터. Teleport를 시작하려면 무료 체험판에 가입하거나 데모 환경을 구성하세요.

• tctl and tsh clients.

  Installing `tctl` and `tsh` clients

  1. Teleport 클러스터의 버전을 확인합니다. tctl and tsh clients는 Teleport 클러스터 버전보다 최대 한 개의 메이저 버전까지만 뒤처질 수 있습니다. Proxy Service의 /v1/webapi/find로 GET 요청을 보내고 JSON 쿼리 도구를 사용하여 클러스터 버전을 확인합니다. teleport.example.com:443를 Teleport Proxy Service의 웹 주소로 바꿉니다:

     $ TELEPORT_DOMAIN=teleport.example.com:443
     $ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"
     

  2. 사용 중인 플랫폼에 대한 지침에 따라 tctl and tsh clients를 설치합니다:

Mac

     `tctl` and `tsh` clients가 포함된, 서명된 Teleport macOS .pkg 설치 프로그램을 다운로드합니다:
 
     ```code
     $ curl -O https://cdn.teleport.dev/teleport-${TELEPORT_VERSION?}.pkg
     ```

     Finder에서 `pkg` 파일을 더블 클릭하여 설치를 시작합니다.
 
     

       Homebrew를 사용하여 Teleport를 설치하는 것은 지원되지 않습니다. Homebrew의
       Teleport 패키지는 Teleport에서 유지 관리하지 않으므로 신뢰성이나 보안을
       보장할 수 없습니다.
     

Windows - Powershell

     ```code
     $ curl.exe -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-windows-amd64-bin.zip
     # Unzip the archive and move the `tctl` and `tsh` clients to your %PATH%
     # NOTE: Do not place the `tctl` and `tsh` clients in the System32 directory, as this can cause issues when using WinSCP.
     # Use %SystemRoot% (C:\Windows) or %USERPROFILE% (C:\Users\<username>) instead.
     ```
 
   

 
   

Linux

     Linux 설치판의 모든 Teleport 바이너리에는 `tctl` and `tsh` clients가 포함되어 있습니다.  RPM/DEB
     패키지 및 i386/ARM/ARM64용 다운로드를 포함한 더 많은 옵션은
     [설치 페이지](../installation/installation.mdx)를 참조하세요.
 
     ```code
     $ curl -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
     $ tar -xzf teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
     $ cd teleport
     $ sudo ./install
     # Teleport binaries have been copied to /usr/local/bin
     ```
   

 

Teleport cluster에 연결할 수 있는지 확인하려면 tsh login으로 로그인한 다음, 현재 자격 증명으로 tctl 명령을 실행할 수 있는지 확인합니다.

예를 들어, teleport.example.com에 cluster 내 Teleport Proxy Service의 도메인 이름을, email@example.com에 Teleport 사용자 이름을 지정하여 다음 명령을 실행합니다:

$ tsh login --proxy=teleport.example.com --user=email@example.com
$ tctl status
# Cluster  (=teleport.url=)
# Version  (=teleport.version=)
# CA pin   (=presets.ca_pin=)

cluster에 연결하여 tctl status 명령을 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 이후의 tctl 명령을 실행할 수 있습니다. 자체 Teleport cluster를 호스팅하는 경우, 전체 권한을 얻기 위해 Teleport Auth Service를 호스팅하는 컴퓨터에서 tctl 명령을 실행할 수도 있습니다.

리소스 제약#

리소스 접근 요청은 선택적으로 **리소스 제약(Resource Constraints)**을 포함할 수 있습니다. 리소스 제약은 승인된 접근 요청을 사용할 때 사용자가 리소스에서 맡을 수 있는 주체(AWS 역할 ARN, SSH 로그인, 데이터베이스 사용자 등)를 좁힙니다. 요청자는 Web UI 또는 Teleport Connect를 사용하여 요청을 생성할 때 필요한 특정 주체를 선택하며, 이 제약은 결과로 생성되는 단기 인증서에 인코딩되고 이후의 역할 변경과 무관하게 인증 시점에 적용됩니다.

리소스 제약은 아래의 사용자가 접근을 요청할 수 있는 리소스 제한에서 설명하는 역할 기반 제한과는 다릅니다. 해당 제어는 어떤 리소스를 검색하고 요청할 수 있는지를 관리합니다. 리소스 제약은 요청이 승인된 후 사용자가 특정 리소스에서 사용할 수 있도록 승인된 주체를 관리합니다.

예를 들어, 여러 ARN을 가진 AWS Console 애플리케이션에 대한 접근을 부여하는 aws-full-access 역할을 고려해 보겠습니다:

kind: role
version: v7
metadata:
  name: aws-full-access
spec:
  allow:
    app_labels:
      env: production
    aws_role_arns:
      - 'arn:aws:iam::123456789012:role/ReadOnly'
      - 'arn:aws:iam::123456789012:role/Admin'

리소스 제약 없이는 이 역할을 통해 AWS Console 애플리케이션에 대한 접근을 요청하고 승인받은 사용자가 두 ARN을 모두 받습니다. 리소스 제약을 사용하면 사용자는 요청 생성 시 ReadOnly만 선택할 수 있으며, 승인된 인증서는 해당 단일 ARN으로 범위가 제한됩니다.

리소스 제약은 현재 AWS Console 애플리케이션 리소스에 대해 지원됩니다. 추가 리소스 유형(SSH, Windows 데스크톱, 데이터베이스, Kubernetes 등)에 대한 지원이 계획되어 있습니다.

가용성#

제약된 리소스 요청은 Teleport Web UI 및 Teleport Connect를 통해서만 생성할 수 있습니다. Teleport CLI(tsh)는 이러한 요청을 검토하고 수락하는 것은 지원하지만 아직 생성은 지원하지 않습니다.

요청 경로의 모든 Teleport 구성 요소(Auth Service, Proxy Service 및 관련 애플리케이션 서버)가 리소스 제약을 지원해야 합니다. 혼합 버전 클러스터에서는 제약을 인식하지 못하는 구성 요소가 제약된 리소스 요청 생성을 방지하고 기존 리소스 접근 요청에서 제약된 리소스에 대한 접근을 거부합니다.

1/6단계. 사용자에게 역할 부여#

기본 제공 requester 및 reviewer 역할은 각각 접근 요청을 열고 검토할 수 있는 권한을 가지고 있습니다. 기존 사용자에게 requester 및 reviewer 역할을 부여하거나 이 기능을 테스트하기 위한 새 사용자를 만듭니다. 요청자가 SSH 노드를 보고 접근할 수 있도록 유효한 login이 있는지 확인합니다.

이 가이드의 나머지 부분에서는 requester 역할이 alice라는 사용자에게 부여되었고 reviewer 역할이 bob이라는 사용자에게 부여되었다고 가정합니다.

1. alice라는 사용자에게 requester 역할을 할당합니다:

인증 공급자에 맞는 적절한 명령을 실행하여 requester 역할을 `alice`에게 할당하십시오:

Local User

1. 로컬 사용자의 역할을 쉼표로 구분된 목록으로 가져옵니다:

   $ ROLES=$(tsh status -f json | jq -r '.active.roles | join(",")')
   

2. 로컬 사용자를 편집하여 새 역할을 추가합니다:

   $ tctl users update $(tsh status -f json | jq -r '.active.username') \
     --set-roles "${ROLES?},requester"
   

3. Teleport 클러스터에서 로그아웃한 다음 다시 로그인하여 새 역할을 적용합니다.

GitHub

1. 텍스트 편집기에서 github 인증 커넥터를 엽니다:

   $ tctl edit github/github
   

2. github 커넥터를 편집하여 teams_to_roles 섹션에 requester을 추가합니다.

   이 역할에 매핑해야 할 팀은 조직의 역할 기반 액세스 제어(RBAC)를 어떻게 설계했는지에 따라 달라집니다. 다만, 해당 팀은 여러분의 사용자 계정을 포함해야 하며 조직 내에서 가능한 한 가장 작은 팀이어야 합니다.

   다음은 예시입니다:

     teams_to_roles:
       - organization: octocats
         team: admins
         roles:
           - access
   +       - requester
   

3. 편집기에서 파일을 저장하고 닫아 변경 사항을 적용합니다.

4. Teleport 클러스터에서 로그아웃한 다음 다시 로그인하여 새 역할을 적용합니다.

SAML

1. saml 구성 리소스를 가져옵니다:

   $ tctl get --with-secrets saml/mysaml > saml.yaml
   

   --with-secrets 플래그는 spec.signing_key_pair.private_key 값을 saml.yaml 파일에 추가한다는 점에 유의하십시오. 이 키에는 민감한 값이 포함되어 있으므로, 리소스를 업데이트한 직후 saml.yaml 파일을 삭제해야 합니다.

2. saml.yaml을 편집하여 attributes_to_roles 섹션에 requester을 추가합니다.

   이 역할에 매핑해야 할 속성은 조직의 역할 기반 액세스 제어(RBAC)를 어떻게 설계했는지에 따라 달라집니다. 다만, 해당 그룹은 여러분의 사용자 계정을 포함해야 하며 조직 내에서 가능한 한 가장 작은 그룹이어야 합니다.

   다음은 예시입니다:

     attributes_to_roles:
       - name: "groups"
         value: "my-group"
         roles:
           - access
   +       - requester
   

3. 변경 사항을 적용합니다:

   $ tctl create -f saml.yaml
   

4. Teleport 클러스터에서 로그아웃한 다음 다시 로그인하여 새 역할을 적용합니다.

OIDC

1. oidc 구성 리소스를 가져옵니다:

   $ tctl get oidc/myoidc --with-secrets > oidc.yaml
   

   --with-secrets 플래그는 spec.signing_key_pair.private_key 값을 oidc.yaml 파일에 추가한다는 점에 유의하십시오. 이 키에는 민감한 값이 포함되어 있으므로, 리소스를 업데이트한 직후 oidc.yaml 파일을 삭제해야 합니다.

2. oidc.yaml을 편집하여 claims_to_roles 섹션에 requester을 추가합니다.

   이 역할에 매핑해야 할 클레임은 조직의 역할 기반 액세스 제어(RBAC)를 어떻게 설계했는지에 따라 달라집니다. 다만, 해당 그룹은 여러분의 사용자 계정을 포함해야 하며 조직 내에서 가능한 한 가장 작은 그룹이어야 합니다.

   다음은 예시입니다:

     claims_to_roles:
       - name: "groups"
         value: "my-group"
         roles:
           - access
   +       - requester
   

3. 변경 사항을 적용합니다:

   $ tctl create -f oidc.yaml
   

4. Teleport 클러스터에서 로그아웃한 다음 다시 로그인하여 새 역할을 적용합니다.

5. 이 단계를 반복하여 bob이라는 사용자에게 reviewer 역할을 할당합니다.

2/6단계. 리소스 검색#

먼저 alice로 로그인합니다.

$ tsh login --proxy teleport.example.com --user alice

alice는 기본적으로 어떤 리소스에도 접근할 수 없으므로 tsh ls는 빈 목록을 반환합니다.

$ tsh ls
Node Name Address Labels
--------- ------- ------

그런 다음 사용 가능한 모든 ssh 노드를 검색해봅니다.

$ tsh request search --kind node
Name                                 Hostname    Labels       Resource ID
------------------------------------ ----------- ------------ ------------------------------------------------------
b1168402-9340-421a-a344-af66a6675738 iot         test=test    /teleport.example.com/node/b1168402-9340-421a-a344-af66a6675738
bbb56211-7b54-4f9e-bee9-b68ea156be5f node        test=test    /teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f

To request access to these resources, run
> tsh request create --resource /teleport.example.com/node/b1168402-9340-421a-a344-af66a6675738 --resource /teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f \
    --reason <request reason>

node, kube_cluster, db, app, windows_desktop 종류의 리소스를 검색할 수 있습니다. Teleport는 또한 kube_resource 종류로 Kubernetes 클러스터 내의 리소스 검색 및 접근 요청을 지원합니다.

고급 필터 및 쿼리가 지원됩니다. 자세한 내용은 필터링 참조를 참조하세요.

접근하려는 특정 리소스로 검색을 좁혀봅니다.

$ tsh request search --kind node --search iot
Name                                 Hostname    Labels       Resource ID
------------------------------------ ----------- ------------ ------------------------------------------------------
b1168402-9340-421a-a344-af66a6675738 iot         test=test    /teleport.example.com/node/b1168402-9340-421a-a344-af66a6675738

To request access to these resources, run
> tsh request create --resource /teleport.example.com/node/b1168402-9340-421a-a344-af66a6675738 \
    --reason <request reason>

3/6단계. 리소스 접근 요청#

이전 단계에서 tsh request search가 출력한 명령을 복사하고 선택적으로 요청 이유를 채웁니다.

$ tsh request create --resource /teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f \
    --reason "responding to incident 123"
Creating request...
Request ID: f406f5d8-3c2a-428f-8547-a1d091a4ddab
Username:   alice
Roles:      access
Resources:  ["/teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f"]
Reason:     "responding to incident 123"
Reviewers:  [none] (suggested)
Status:     PENDING

hint: use 'tsh login --request-id=<request-id>' to login with an approved request

Waiting for request approval...

명령은 요청이 승인될 때까지 자동으로 대기합니다.

4/6단계. 접근 요청 승인#

먼저 bob으로 로그인합니다.

$ tsh login --proxy teleport.example.com --user bob

그런 다음 접근 요청을 나열하고 검토하고 승인합니다.

$ tsh request ls
ID                                   User  Roles  Resources                   Created At (UTC)    Status
------------------------------------ ----- ------ --------------------------- ------------------- -------
f406f5d8-3c2a-428f-8547-a1d091a4ddab alice access ["/teleport.example.... [+] 23 Jun 22 18:25 UTC PENDING

[+] Requested resources truncated, use `tsh request show <request-id>` to view the full list

hint: use 'tsh request show <request-id>' for additional details
      use 'tsh login --request-id=<request-id>' to login with an approved request
$ tsh request show f406f5d8-3c2a-428f-8547-a1d091a4ddab
Request ID: f406f5d8-3c2a-428f-8547-a1d091a4ddab
Username:   alice
Roles:      access
Resources:  ["/teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f"]
Reason:     "responding to incident 123"
Reviewers:  [none] (suggested)
Status:     PENDING

hint: use 'tsh login --request-id=<request-id>' to login with an approved request
$ tsh request review --approve f406f5d8-3c2a-428f-8547-a1d091a4ddab
Successfully submitted review.  Request state: APPROVED

5/6단계. 요청된 리소스 접근#

요청이 승인되었으므로 alice의 tsh request create 명령이 이제 완료됩니다.

$ tsh request create --resource /teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f \
    --reason "responding to incident 123"
Creating request...
Request ID: f406f5d8-3c2a-428f-8547-a1d091a4ddab
Username:   alice
Roles:      access
Resources:  ["/teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f"]
Reason:     "responding to incident 123"
Reviewers:  [none] (suggested)
Status:     PENDING

hint: use 'tsh login --request-id=<request-id>' to login with an approved request

Waiting for request approval...

Approval received, getting updated certificates...

> Profile URL:        https://teleport.example.com
  Logged in as:       alice
  Active requests:    f406f5d8-3c2a-428f-8547-a1d091a4ddab
  Cluster:            teleport.example.com
  Roles:              access, requester
  Logins:             alice
  Kubernetes:         disabled
  Allowed Resources:  ["/teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f"]
  Valid until:        2022-06-23 22:46:22 -0700 PDT [valid for 11h16m0s]
  Extensions:         permit-agent-forwarding, permit-port-forwarding, permit-pty

이제 alice는 노드를 보고 접근할 수 있습니다.

$ tsh ls
Node Name Address   Labels
--------- --------- ---------
iot       [::]:3022 test=test

$ tsh ssh alice@iot
iot:~ alice$

6/6단계. 일반 접근 재개#

리소스 접근 요청으로 로그인하는 동안 사용자는 다른 리소스에 대한 접근이 차단됩니다. 인증서에 이제 상승된 역할이 포함되어 있어 승인받은 리소스에만 접근이 제한되기 때문에 필요합니다. tsh request drop 명령을 사용하여 요청을 "드롭"하고 일반 접근을 재개합니다.

$ tsh request drop

리소스 접근 요청을 구성한 후 tsh ssh는 접근이 거부될 때 자동으로 리소스 접근 요청을 만들 수 있어 tsh request search 및 tsh request create 단계를 건너뛸 수 있습니다.

$ tsh ssh alice@iot
ERROR: access denied to alice connecting to iot on cluster teleport.example.com

You do not currently have access to alice@iot, attempting to request access.

Enter request reason: please
Creating request...
Request ID: ab43fc70-e893-471b-872e-ae65eb24fd76
Username:   alice
Roles:      access
Resources:  ["/teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f"]
Reason:     "please"
Reviewers:  [none] (suggested)
Status:     PENDING

hint: use 'tsh login --request-id=<request-id>' to login with an approved request

Waiting for request approval...

Approval received, reason="okay"
Getting updated certificates...

iot:~ alice$

사용자가 접근을 요청할 수 있는 리소스 제한#

이 가이드에서는 사용자가 접근을 요청할 리소스를 검색할 수 있도록 활성화하는 방법을 보여주었습니다. 이를 위해 사용자에게 search_as_roles 필드가 프리셋 access 역할로 설정된 Teleport 역할을 할당했습니다.

더 제한된 역할에 search_as_roles를 할당하여 사용자가 검색할 수 있는 리소스에 추가 제한을 부과할 수 있습니다. 아래에서는 다른 리소스 검색에 대한 사용자의 능력을 제한하기 위해 설정해야 하는 권한을 보여줍니다.

아래와 유사한 역할을 사용하여 특정 리소스에 대한 접근을 제한하려면 search_as_roles 필드에 만든 역할이 포함되도록 사용자의 역할 중 하나를 편집합니다.

Teleport 역할을 사용하여 RBAC를 구성하는 방법에 대한 자세한 내용은 접근 제어 참조를 참조하세요.

node#

spec.allow 또는 spec.deny 필드에서 node_labels 필드에 값을 할당하여 node 리소스 검색에 대한 접근을 제한할 수 있습니다. 다음 역할은 env:staging 레이블이 있는 SSH Service 인스턴스에 대한 접근을 허용합니다.

kind: role
version: v5
metadata:
  name: staging-access
spec:
  allow:
    node_labels:
      env: staging
    logins:
      - '{{internal.logins}}'
  options:
    # Only allows the requester to use this role for 1 hour from time of request.
    max_session_ttl: 1h

kube_cluster#

spec.allow 또는 spec.deny 필드에서 kubernetes_labels 필드에 값을 할당하여 kube_cluster 리소스 검색에 대한 접근을 제한할 수 있습니다.

다음 역할은 env:staging 레이블이 있는 Kubernetes 클러스터에 대한 접근을 허용합니다:

kind: role
metadata:
  name: kube-access
version: v8
spec:
  allow:
    kubernetes_labels:
      env: staging
    kubernetes_resources:
      - kind: '*'
        namespace: '*'
        name: '*'
        api_group: '*'
  deny: {}

Kubernetes 리소스#

spec.allow 또는 spec.deny 필드에서 kubernetes_resources 필드에 값을 할당하여 Kubernetes 리소스에 대한 접근을 제한할 수 있습니다.

다음 역할은 모든 네임스페이스에서 이름이 nginx인 Kubernetes 파드와 dev 네임스페이스의 모든 파드에 대한 접근을 허용합니다:

kind: role
metadata:
  name: kube-access
version: v8
spec:
  allow:
    kubernetes_labels:
      '*': '*'
    kubernetes_resources:
      - kind: pods
        namespace: '*'
        name: 'nginx*'
        api_group: ''
      - kind: pods
        namespace: dev
        name: '*'
        api_group: ''
    kubernetes_groups:
      - viewers
  deny: {}

request.kubernetes_resources 필드를 사용하면 사용자가 어떤 종류의 Kubernetes 리소스 요청을 할 수 있는지 제한할 수 있습니다. 이 필드를 임의의 값으로 구성하면 전체 Kubernetes 클러스터에 대한 접근 요청이 허용되지 않습니다.

request.kubernetes_resources 필드가 구성되지 않은 경우 사용자는 전체 Kubernetes 클러스터를 포함한 모든 Kubernetes 리소스에 대한 접근을 요청할 수 있습니다.

다음 역할을 사용하면 사용자가 Kubernetes 네임스페이스에 대한 접근을 요청할 수 있습니다. pods 이외의 Kubernetes 리소스 요청은 허용되지 않습니다.

kind: role
metadata:
  name: requester-kube-access
version: v8
spec:
  allow:
    request:
      search_as_roles:
        - kube-access
      kubernetes_resources:
        - kind: pods
          api_group: ''

다음 역할을 사용하면 사용자가 Kubernetes 배포 및/또는 파드에만 대한 접근을 요청할 수 있습니다.

kind: role
metadata:
  name: requester-kube-access
version: v8
spec:
  allow:
    request:
      search_as_roles:
        - kube-access
      kubernetes_resources:
        - kind: deployments
          api_group: apps
        - kind: pods
          api_group: ''

다음 역할을 사용하면 사용자가 특정 Kubernetes 리소스에 대한 접근을 요청할 수 있습니다.

kind: role
metadata:
  name: requester-kube-access
version: v8
spec:
  allow:
    request:
      search_as_roles:
        - kube-access
      kubernetes_resources:
        - kind: '*'
          api_group: '*'

request.kubernetes_resources 필드는 어떤 kind / api_group의 Kubernetes 리소스 요청이 허용되는지만 제한합니다. 이러한 리소스에 대한 Kubernetes 접근을 제어하려면 자세한 내용은 Kubernetes 리소스 섹션을 참조하세요.

db#

spec.allow 또는 spec.deny 필드에서 db_labels 필드에 값을 할당하여 db 리소스 검색에 대한 접근을 제한할 수 있습니다.

다음 역할은 env:dev 또는 env:staging 레이블이 있는 데이터베이스에 대한 접근을 허용합니다:

kind: role
version: v5
metadata:
  name: developer
spec:
  allow:
    db_labels:
      env: ["dev", "staging"]

    # Database account names this role can connect as.
    db_users: ["viewer", "editor"]
    db_names: ["*"]

app#

spec.allow 또는 spec.deny 필드에서 app_labels 필드에 값을 할당하여 app 리소스 검색에 대한 접근을 제한할 수 있습니다.

다음 역할은 env:prod에 있는 것을 제외한 모든 애플리케이션에 대한 접근을 허용합니다:

kind: role
version: v5
metadata:
  name: dev
spec:
  allow:
    app_labels:
      "*": "*"
  deny:
    app_labels:
      env: "prod"

windows_desktop#

spec.allow 또는 spec.deny 필드에서 windows_desktop_labels 필드에 값을 할당하여 windows_desktop 리소스 검색에 대한 접근을 제한할 수 있습니다.

다음 역할은 env:dev 또는 env:staging 레이블이 있는 모든 Windows 데스크톱에 대한 접근을 허용합니다.

kind: role
version: v4
metadata:
  name: developer
spec:
  allow:
    windows_desktop_labels:
      env: ["dev", "staging"]

    windows_desktop_logins: ["{{internal.windows_logins}}"]

다음 단계#

• 접근 요청 구성 가이드에서 접근 요청을 구성하는 모든 방법에 대해 읽어보세요. 예를 들어 사용자가 접근을 요청하기 위해 나열할 수 있는 리소스를 제한하도록 사용자 역할의 search_as_roles 필드를 구성할 수 있습니다.
• Teleport의 접근 요청 플러그인을 사용하면 사용자가 조직의 기존 메시징 및 프로젝트 관리 솔루션에서 접근 요청을 관리할 수 있습니다. 접근 요청 플러그인에 대한 문서를 읽어보세요.
• 최종 사용자로서 접근 요청을 만들고 관리하는 방법에 대한 자세한 내용은 역할 및 리소스에 대한 접근 요청을 읽어보세요.
• 제한된 시간 동안 Teleport 사용자 목록에 상승된 권한을 할당할 수 있는 접근 목록에 대해 알아보세요.