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

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

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

전제 조건#

• A running Teleport Enterprise cluster. If you want to get started with Teleport, sign up for a free trial or set up a demo environment.

• The tctl and tsh clients.

  Installing `tctl` and `tsh` clients

  1. Determine the version of your Teleport cluster. The tctl and tsh clients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at /v1/webapi/find and use a JSON query tool to obtain your cluster version. Replace with the web address of your Teleport Proxy Service:

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

  2. Follow the instructions for your platform to install tctl and tsh clients:

To check that you can connect to your Teleport cluster, sign in with tsh login, then verify that you can run tctl commands using your current credentials.

For example, run the following command, assigning to the domain name of the Teleport Proxy Service in your cluster and to your Teleport username:

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

If you can connect to the cluster and run the tctl status command, you can use your current credentials to run subsequent tctl commands from your workstation. If you host your own Teleport cluster, you can also run tctl commands on the computer that hosts the Teleport Auth Service for full permissions.

리소스 제약#

리소스 접근 요청은 선택적으로 **리소스 제약(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 역할을 할당합니다:

Assign the requester role to `alice` by running the appropriate commands for your authentication provider:

1. 이 단계를 반복하여 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 사용자 목록에 상승된 권한을 할당할 수 있는 접근 목록에 대해 알아보세요.