Teleport 리소스 접근 요청을 통해 사용자는 기본적으로 사용되는 역할이나 RBAC 제어에 대한 지식 없이도 특정 리소스에 대한 접근을 요청할 수 있습니다.
Access Request API는 이러한 요청을 동적으로 승인하거나 거부하는 것을 쉽게 합니다.

적시 접근 요청은 Teleport Enterprise의 기능입니다.
Teleport Community Edition 사용자는 Teleport CLI를 통해 역할을 요청하여 Access Requests가 어떻게 작동하는지 미리 볼 수 있습니다. 리소스 접근 요청 및 직관적이고 검색 가능한 UI를 포함한 전체 Access Request 기능은 Teleport Enterprise에서 제공됩니다.

전제 조건

• 실행 중인 Teleport 클러스터. Teleport를 시작하려면 가입하여 무료 평가판을 이용해 보십시오.

• tctl 관리자 도구 및 tsh 클라이언트 도구.

  tctl 및 tsh 다운로드에 대한 지침은 설치 를 방문하십시오.

• 연결이 가능한지 확인하기 위해 tsh login 으로 로그인한 다음, 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어:

  tsh login --proxy=teleport.example.com --user=email@example.com
  tctl status
  클러스터  teleport.example.com
  버전  17.0.0-dev
  CA 핀   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678

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

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

내장된 requester 및 reviewer 역할은 각각 접근 요청을 개시하고 검토할 수 있는 권한을 가지고 있습니다. 기존 사용자에게 requester 및 reviewer 역할을 부여하거나 이 기능을 테스트하기 위해 새로운 사용자를 생성하세요. 요청자가 SSH 노드를 보고 접근할 수 있도록 유효한 login 을 가지고 있는지 확인하십시오.

tctl users add alice --roles requester --logins alice
tctl users add bob --roles reviewer

가이드의 나머지 부분에서는 requester 역할이 사용자 alice 에게 부여되었고, reviewer 역할이 사용자 bob 에게 부여된 것으로 가정하겠습니다.

2/6단계. 리소스 검색하기

먼저, alice 로 로그인합니다.

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

tsh ls 가 빈 목록을 반환하는 것을 확인하십시오. 이는 기본적으로 alice 가 어떤 리소스에도 접근할 수 없기 때문입니다.

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-af66a6675738bbb56211-7b54-4f9e-bee9-b68ea156be5f node        test=test    /teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f
이 리소스에 대한 접근을 요청하려면 다음을 실행하세요.> tsh request create --resource /teleport.example.com/node/b1168402-9340-421a-a344-af66a6675738 --resource /teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f \    --reason <요청 이유>

리소스 종류로 node , kube_cluster , db , app 및 windows_desktop 을 검색할 수 있습니다. Teleport는 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
이 리소스에 대한 접근을 요청하려면 다음을 실행하세요.> tsh request create --resource /teleport.example.com/node/b1168402-9340-421a-a344-af66a6675738 \    --reason <요청 이유>

3/6단계. 리소스에 대한 액세스 요청

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

tsh request create --resource /teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f \    --reason "사건 123에 대한 응답"
요청 생성 중...요청 ID: f406f5d8-3c2a-428f-8547-a1d091a4ddab사용자 이름:   alice역할:      access리소스:  ["/teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f"]이유:     "사건 123에 대한 응답"검토자:  [none] (제안됨)상태:     PENDING
힌트: 'tsh login --request-id=<request-id>'를 사용하여 승인된 요청으로 로그인합니다.
요청 승인 대기 중...

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

4/6단계. 액세스 요청 승인

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

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

그런 다음 액세스 요청을 나열하고 검토 및 승인합니다.

tsh request ls
ID                                   사용자  역할  리소스                     생성 날짜 (UTC)    상태------------------------------------ ----- ------ --------------------------- ------------------- -------f406f5d8-3c2a-428f-8547-a1d091a4ddab alice access ["/teleport.example.... [+] 22년 6월 23일 18:25 UTC PENDING
[+] 요청된 리소스가 축약되었습니다. 전체 목록을 보려면 `tsh request show <request-id>`를 사용하십시오.
힌트: 'tsh request show <request-id>'를 사용하여 추가 세부정보를 확인합니다.      승인된 요청으로 로그인하려면 'tsh login --request-id=<request-id>'를 사용하십시오.
tsh request show f406f5d8-3c2a-428f-8547-a1d091a4ddab
요청 ID: f406f5d8-3c2a-428f-8547-a1d091a4ddab사용자 이름:   alice역할:      access리소스:  ["/teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f"]이유:     "사건 123에 대한 응답"검토자:  [none] (제안됨)상태:     PENDING
힌트: 'tsh login --request-id=<request-id>'를 사용하여 승인된 요청으로 로그인합니다.
tsh request review --approve f406f5d8-3c2a-428f-8547-a1d091a4ddab
검토가 성공적으로 제출되었습니다. 요청 상태: APPROVED

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

alice 의 tsh request create 명령은 이제 요청이 승인되었으므로 해결될 것입니다.

tsh request create --resource /teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f \    --reason "사건 123에 대한 응답"
요청 생성 중...요청 ID: f406f5d8-3c2a-428f-8547-a1d091a4ddab사용자 이름:   alice역할:      access리소스:  ["/teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f"]이유:     "사건 123에 대한 응답"검토자:  [none] (제안됨)상태:     PENDING
힌트: 'tsh login --request-id=<request-id>'를 사용하여 승인된 요청으로 로그인합니다.
요청 승인 대기 중...
승인 받음, 업데이트된 인증서 가져오는 중...
> 프로필 URL:        https://teleport.example.com  로그인 사용자:       alice  활성 요청:    f406f5d8-3c2a-428f-8547-a1d091a4ddab  클러스터:            teleport.example.com  역할:              access, requester  로그인:             alice  Kubernetes:         비활성화됨  허용된 리소스:  ["/teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f"]  유효 기간:        2022-06-23 22:46:22 -0700 PDT [11시간 16분 0초 유효]  확장:         permit-agent-forwarding, permit-port-forwarding, permit-pty

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

tsh ls
노드 이름 주소   레이블--------- --------- ---------iot       [::]:3022 test=test
tsh ssh alice@iot
iot:~ alice$

6/6단계. 정기적인 접근 재개

리소스 접근 요청으로 로그인한 상태에서는 다른 리소스에 대한 접근이 차단됩니다.
이는 그들의 인증서가 이제 상승된 역할을 포함하기 때문에,
특정 승인된 리소스에만 접근을 허용하도록 제한됩니다.
tsh request drop 명령어를 사용하여 요청을 "드롭"하고 정기적인 접근을 재개하십시오.

tsh request drop

다음 단계

SSH에 대한 접근 자동 요청

리소스 접근 요청을 설정한 후,
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
현재 alice@iot에 대한 접근 권한이 없습니다. 접근 요청을 시도하고 있습니다.
요청 사유 입력: please요청 생성 중...요청 ID: ab43fc70-e893-471b-872e-ae65eb24fd76사용자 이름:   alice역할:      access리소스:  ["/teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f"]사유:     "please"검토자:  [none] (제안됨)상태:     PENDING
힌트: 'tsh login --request-id=<request-id>'를 사용하여 승인된 요청으로 로그인하십시오.
요청 승인 대기 중...
승인 받음, 이유="okay"업데이트된 인증서 가져오는 중...
iot:~ alice$

사용자가 요청할 수 있는 리소스 제한하기

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

사용자가 검색할 수 있는 리소스에 대해 추가 제한을 가하려면,
search_as_roles 를 보다 제한된 역할로 할당해야 합니다.
아래에서는 사용자가 서로 다른 리소스를 검색할 수 있는 능력을 제한하는 데 필요한 권한을 보여드리겠습니다.

특정 리소스에 대한 접근을 제한하려면, 아래와 유사한 역할을 사용하여 사용자의 역할 중 하나를 편집하고,
search_as_roles 필드에 생성한 역할을 포함시킵니다.

RBAC 구성을 위해 Teleport 역할을 사용하는 방법에 대한 전체 세부정보는
Teleport 액세스 제어 참조를 참조하십시오.

node

node 리소스를 검색하는 접근을 제한하려면,
spec.allow 또는 spec.deny 필드의 node_labels 필드에 값을 할당할 수 있습니다.
다음 역할은 env:staging 라벨이 있는 SSH 서비스 인스턴스에 대한 접근을 허용합니다.

kind: role
version: v5
metadata:
  name: staging-access
spec:
  allow:
    node_labels:
      env: staging
    logins:
      - "{{internal.logins}}"
  options:
    # 요청자에게 이 역할을 요청 시점으로부터 1시간 동안만 사용을 허용합니다.
    max_session_ttl: 1h

kube_cluster

kube_cluster 리소스를 검색하는 접근을 제한하려면,
spec.allow 또는 spec.deny 필드의 kubernetes_labels 필드에 값을 할당해야 합니다.

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

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

Kubernetes 리소스

Kubernetes 리소스에 대한 액세스를 제한하려면 spec.allow 또는 spec.deny 필드의 kubernetes_resources 필드에 값을 할당하면 됩니다.

다음 역할은 모든 네임스페이스에서 이름이 nginx 인 Kubernetes 팟에 대한 액세스와 dev 네임스페이스의 모든 팟에 대한 액세스를 허용합니다:

kind: role
metadata:
  name: kube-access
version: v7
spec:
  allow:
    kubernetes_labels:
      '*':'*'
    kubernetes_resources:
      - kind: pod
        namespace: "*"
        name: "nginx*"
      - kind: pod
        namespace: "dev"
        name: "*"
    kubernetes_groups:
      - viewers
  deny: {}

의도치 않은 Kubernetes 리소스에 대한 액세스 방지

특정 Kubernetes 리소스에 대한 적시 액세스를 활성화하기 위해 Teleport 역할을 설정하는 경우, 역할의 kubernetes_groups 및 kubernetes_users 를 Teleport가 액세스를 제한할 수 있는 Kubernetes 리소스 이외의 액세스 권한이 없는 역할로 설정해야 합니다.

이는 사용자가 Kubernetes 팟에 대한 액세스를 요청하고 요청이 승인될 경우, Teleport Kubernetes 서비스가 역할의 kubernetes_groups 및 kubernetes_users 필드를 사용하여 사용자의 Kubernetes API 서버 요청에 임시 헤더를 추가하기 때문입니다. 이러한 조건에서 Teleport는 위에서 언급된 모든 Kubernetes 리소스 유형에 대한 액세스를 제한할 수 있지만 원하는 pod 는 예외입니다. Teleport는 네임스페이스 범위의 사용자 정의 리소스에 대한 액세스를 제한할 수 있지만 클러스터 범위의 사용자 정의 리소스 - 클러스터 범위의 CRD 리소스는 kubernetes_users 및 kubernetes_groups 필드의 주체가 액세스할 수 있는 경우 사용자가 액세스할 수 있게 됩니다.

Kubernetes 네임스페이스에 대한 액세스를 요청하면 해당 네임스페이스의 모든 리소스에 액세스할 수 있지만 클러스터의 다른 지원되는 리소스에는 액세스할 수 없습니다.

특정 Kubernetes 리소스 유형에 대한 액세스 요청 제한

request.kubernetes_resources 필드를 사용하면 사용자가 요청할 수 있는 Kubernetes 리소스 유형을 제한할 수 있습니다. 이 필드에 값을 구성하면 전체 Kubernetes 클러스터에 대한 액세스를 요청할 수 없게 됩니다.

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

다음 역할은 사용자가 Kubernetes 네임스페이스에 대한 액세스를 요청할 수 있도록 허용합니다. namespace 이외의 Kubernetes 리소스 요청은 허용되지 않습니다.

kind: role
metadata:
  name: requester-kube-access
version: v7
spec:
  allow:
    request:
      search_as_roles:
        - "kube-access"
      kubernetes_resources:
        - kind: "namespace"

다음 역할은 사용자가 Kubernetes 네임스페이스 및/또는 팟에 대해서만 액세스를 요청할 수 있도록 허용합니다.

kind: role
metadata:
  name: requester-kube-access
version: v7
spec:
  allow:
    request:
      search_as_roles:
        - "kube-access"
      kubernetes_resources:
        - kind: "namespace"
        - kind: "pod"

다음 역할은 사용자가 모든 특정 Kubernetes 리소스에 대한 액세스를 요청할 수 있도록 허용합니다.

kind: role
metadata:
  name: requester-kube-access
version: v7
spec:
  allow:
    request:
      search_as_roles:
        - "kube-access"
      kubernetes_resources:
        - kind: "*"

지원되는 kind 값 목록을 보려면 Kubernetes Resources 섹션을 참조하세요.

request.kubernetes_resources 필드는 허용되는 Kubernetes 리소스 요청의 kinds 를 제한할 뿐입니다. 이러한 리소스에 대한 Kubernetes 액세스를 제어하려면 의도치 않은 Kubernetes 리소스에 대한 액세스 방지 섹션을 참조하여 더 많은 세부 정보를 확인하세요.

db

db 리소스 검색에 대한 액세스를 제한하려면 spec.allow 또는 spec.deny 필드의 db_labels 필드에 값을 할당하십시오.

다음 역할은 environment:dev 또는 environment:stage 레이블이 있는 데이터베이스에 대한 액세스를 허용합니다:

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

    # 이 역할이 연결할 수 있는 데이터베이스 계정 이름입니다.
    db_users: ["viewer", "editor"]
    db_names: ["*"]

app

app 리소스 검색에 대한 액세스를 제한하려면 spec.allow 또는 spec.deny 필드의 app_labels 필드에 값을 할당하십시오.

다음 역할은 env:prod 에 있는 앱을 제외한 모든 애플리케이션에 대한 액세스를 허용합니다:

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

windows_desktop

windows_desktop 리소스 검색에 대한 액세스를 제한하려면 spec.allow 또는 spec.deny 필드의 windows_desktop_labels 필드에 값을 할당하십시오.

다음 역할은 environment:dev 또는 environment:stage 레이블이 있는 모든 Windows 데스크탑에 대한 액세스를 허용합니다:

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

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

Kubernetes 리소스에 대한 액세스 요청하기

Teleport 사용자는 다음 명령을 실행하여 Kubernetes 리소스에 대한 액세스를 요청할 수 있습니다:

tsh request create resource-id

네임스페이스 범위 리소스

Kubernetes 네임스페이스 리소스의 경우, resource-id 는 다음 형식입니다:

/TELEPORT_CLUSTER/NAMESPACED_KIND/KUBE_CLUSTER/NAMESPACE/RESOURCE_NAME

Teleport는 다음과 같은 네임스페이스 리소스를 지원합니다: pod , secret , configmap , service , serviceaccount , persistentvolumeclaim , deployment , replicaset , statefulset , daemonset , kube_role , rolebinding , cronjob , job , ingress .

예를 들어, development 네임스페이스의 nginx-1 이라는 포드에 대한 액세스를 요청하려면 다음 명령을 실행하십시오:

tsh request create --resources /teleport.example.com/pod/mycluster/development/nginx-1

NAMESPACE 및 RESOURCE_NAME 값의 경우, 와일드카드(*) 또는 정규 표현식을 제공하여 문자열 범위를 일치시킬 수 있습니다. 정규 표현식은 ^로 시작하고 $로 끝나야 합니다.

예를 들어, 정규 표현식 /^nginx-[a-z0-9-]+$/와 일치하는 모든 네임스페이스의 포드에 대한 액세스 요청을 생성하려면 다음 명령을 실행하십시오:

tsh request create --resources /teleport.example.com/pod/mycluster/*/^nginx-[a-z0-9-]+$

클러스터 범위 리소스

Kubernetes 클러스터 범위 리소스의 경우, resource-id 는 다음 형식입니다:

/TELEPORT_CLUSTER/CLUSTER_WIDE_KIND/KUBE_CLUSTER/RESOURCE_NAME

Teleport는 다음과 같은 클러스터 범위 리소스를 지원합니다: namespace , kube_node , clusterrole , clusterrolebinding , persistentvolume , certificatesigningrequest .

예를 들어, prod 라는 네임스페이스에 대한 액세스를 요청하려면 다음 명령을 실행하십시오:

tsh request create --resources /teleport.example.com/namespace/mycluster/prod

RESOURCE_NAME 값의 경우, 와일드카드(*) 또는 정규 표현식을 제공하여 문자열 범위를 일치시킬 수 있습니다. 정규 표현식은 ^로 시작하고 $로 끝나야 합니다.

예를 들어, dev 로 시작하는 모든 네임스페이스에 대한 액세스 요청을 생성하려면 정규 표현식 /^dev-[a-z0-9-]+$/와 일치하도록 다음 명령을 실행하십시오:

tsh request create --resources /teleport.example.com/namespace/mycluster/^dev-[a-z0-9-]+$

클러스터 범위 리소스 요청을 사용하려면, search_as_roles 아래의 역할이 클러스터 범위 리소스에 대한 올바른 권한을 가져야 합니다. 이는 네임스페이스 prod (및 해당 내 모든 리소스)에 대한 액세스를 요청하는 데 필요한 권한의 예입니다:

kind: role
spec:
  allow:
    kubernetes_resources:
      - kind: namespace
        name: prod
        verbs:
          - "*"

Kubernetes 리소스 검색

사용자가 Kubernetes 클러스터에 대한 액세스 권한이 없는 경우, 다음 명령을 실행하여 클러스터의 리소스 목록을 검색할 수 있습니다:

tsh request search --kind=<kind> --kube-cluster=kube-cluster \[--kube-namespace=namespace|--all-kube-namespaces]
Name               Namespace Labels    Resource ID-----------------  --------- --------- ----------------------------------------------------------nginx-deployment-0 default   app=nginx /teleport.example.com/pod/local/default/nginx-deployment-0nginx-deployment-1 default   app=nginx /teleport.example.com/pod/local/default/nginx-deployment-1
이 리소스에 대한 액세스를 요청하려면 다음을 실행하십시오> tsh request create --resource /teleport.example.com/pod/local/default/nginx-deployment-0 --resource /teleport.example.com/pod/local/default/nginx-deployment-1 \    --reason <request reason>

반환된 목록에는 리소스의 이름, 해당 리소스가 포함된 네임스페이스(해당하는 경우), 레이블 및 리소스 ID가 포함됩니다. 목록에 포함된 리소스는 사용자의 search_as_roles 의 kubernetes_resources 필드와 일치하는 리소스입니다. 사용자는 다음을 수행할 수 있습니다:

• tsh request search 명령에서 제공된 명령을 실행하여 리소스에 대한 액세스를 요청합니다.
• 리소스의 하위 집합에 대한 액세스를 요청하기 위해 명령을 편집합니다.
• 와일드카드 또는 정규 표현식을 사용하여 사용자 정의 요청을 생성합니다.

tsh request search --kind=<kind>는 사용자가 원하는 Kubernetes 클러스터와 상호 작용할 권한이 없더라도 작동하지만, 사용자의 search_as_roles 값은 클러스터에 대한 액세스를 허용해야 합니다. 사용자가 클러스터의 이름이 확실하지 않은 경우, 다음 명령을 실행하여 검색할 수 있습니다:

tsh request search --kind=kube_cluster
Name  Hostname Labels Resource ID----- -------- ------ ----------------------------------------local                 /teleport.example.com/kube_cluster/local

외부 도구와 통합

Teleport의 액세스 요청 플러그인을 사용하면 사용자가 조직의 기존 메시징 및 프로젝트 관리 솔루션 내에서 액세스 요청을 관리할 수 있습니다.

다음 단계

• 액세스 목록에 대해 자세히 알아보기