리소스 접근 요청 | Teleport 공식 기술 문서 한국판 by 인포그랩

리소스 접근 요청

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

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

사전 요구 사항

실행 중인 Teleport 클러스터. Teleport를 시작하려면 가입하기 무료 체험판을 이용해 보세요.
tctl 관리 도구 및 tsh 클라이언트 도구 버전 >= 16.2.0.

tctl 및 tsh 다운로드 방법에 대한 지침은 설치를 방문하세요.

당신의 Teleport 클러스터에 연결할 수 있는지 확인하려면, tsh login으로 로그인한 다음 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어:
```
tsh login --proxy=teleport.example.com --user=email@example.com
tctl status
클러스터  teleport.example.com
버전  16.2.0
CA 핀   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
```
클러스터에 연결하고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 작업대에서 후속 tctl 명령어를 실행할 수 있습니다. 자신의 Teleport 클러스터를 호스팅하는 경우, Teleport 인증 서비스를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.

Step 1/8. 요청자 역할 생성

Note

버전 13.1.2부터 Teleport는 여기에서 정의된 역할과 유사하게 정의된 기본 제공 reviewer 및 requester 역할을 포함하고 있습니다.
Access Requests를 빠르게 시도해보고 싶다면, 3단계로 건너뛰고 이러한 기본 제공 역할을 사용할 수 있습니다.
그러나 이전 버전의 Teleport를 사용하고 있거나 Access Requests를 위한 역할 생성에 대한 일반 가이드를 원하신다면, 1단계와 2단계는 여전히 유용합니다.

이 역할은 요청자가 access 역할 (기본적으로 모든 리소스)에 접근할 수 있는 리소스를 검색하고 요청하도록 허용합니다.

# requester.yaml
kind: role
version: v5
metadata:
  name: requester
spec:
  allow:
    request:
      search_as_roles:
        - access

tctl create requester.yaml

Step 2/8. 검토자 역할 생성

이 역할은 검토자가 access 역할에 대한 모든 요청을 승인할 수 있게 해줍니다.

# reviewer.yaml
kind: role
version: v5
metadata:
  name: reviewer
spec:
  allow:
    review_requests:
      roles:
        - access
      preview_as_roles:
        - access

tctl create reviewer.yaml

Step 3/8. 사용자에게 역할 부여

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

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

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

Step 4/8. 리소스 검색

먼저 alice로 로그인합니다.

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

tsh ls 명령어가 비어 있는 목록을 반환한다는 것을 알 수 있습니다.
이는 alice가 기본적으로 어떤 리소스에도 접근할 수 없기 때문입니다.

tsh ls
노드 이름 주소 라벨--------- ------- ------

그 후, 사용 가능한 모든 SSH 노드를 검색해 보세요.

tsh request search --kind node
이름                                 호스트 이름    라벨       리소스 ID------------------------------------ ----------- ------------ ------------------------------------------------------b1168402-9340-421a-a344-af66a6675738 iot         test=test    /teleport.example.com/node/b1168402-9340-421a-a344-af66a6675738bbb56211-7b54-4f9e-bee9-b68ea156be5f 노드        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 <request reason>

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

Teleport는 다음 Kubernetes 리소스에 대한 검색 및 접근 요청을 지원합니다:

Kubernetes 네임스페이스에 대한 리소스 접근 요청

Kubernetes 네임스페이스에 대한 접근 요청을 하면 해당 네임스페이스의 모든 리소스에 접근할 수 있으며, 아래에 나열된 지원되는 Kubernetes 리소스도 포함됩니다.
그러나 다른 네임스페이스에 속한 리소스에 대한 접근은 차단됩니다.

pod
secret
configmap
namespace
service
serviceaccount
kube_node
persistentvolume
persistentvolumeclaim
deployment
replicaset
statefulset
daemonset
clusterrole
kube_role
clusterrolebinding
rolebinding
cronjob
job
certificatesigningrequest
ingress

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

접근하고 싶은 특정 리소스에 대한 검색을 좁혀보세요.

tsh request search --kind node --search iot
이름                                 호스트 이름    라벨       리소스 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 <request reason>

Step 5/8. 리소스에 대한 접근 요청

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

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

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

Step 6/8. 접근 요청 승인

먼저 bob로 로그인합니다.

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

그 후, 접근 요청을 목록화하고 검토 및 승인합니다.

tsh request ls
ID                                   사용자  역할  리소스                   생성일시 (UTC)    상태  ------------------------------------ ----- ------ --------------------------- ------------------- -------  f406f5d8-3c2a-428f-8547-a1d091a4ddab alice access ["/teleport.example.... [+] 23 Jun 22 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
Request ID: f406f5d8-3c2a-428f-8547-a1d091a4ddab  사용자:   alice  역할:      access  리소스:  ["/teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f"]  이유:     "incident 123에 응답"  검토자:  [없음] (제안됨)  상태:     PENDING  
힌트: 'tsh login --request-id=<request-id>'를 사용하여 승인된 요청으로 로그인하세요.  tsh request review --approve f406f5d8-3c2a-428f-8547-a1d091a4ddab
성공적으로 검토가 제출되었습니다. 요청 상태: APPROVED

신속한 접근 요청에 대한 알림을 적절한 사람에게 보낼 수 있는
Access Request 통합을 확인하세요.

Step 7/8. 요청한 리소스 접근

alice의 tsh request create 명령어는 요청이 승인됨에 따라 이제 해결되어야 합니다.

tsh request create --resource /teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f \    --reason "incident 123에 응답"  
요청 생성 중...  Request ID: f406f5d8-3c2a-428f-8547-a1d091a4ddab  사용자:   alice  역할:      access  리소스:  ["/teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f"]  이유:     "incident 123에 응답"  검토자:  [없음] (제안됨)  상태:     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분]    확장 기능:         permit-agent-forwarding, permit-port-forwarding, permit-pty

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

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

Step 8/8. 일반 접근 복원

리소스 접근 요청으로 로그인 중에는 사용자가 다른 리소스에 접근하는 것이 차단됩니다.
이는 해당 사용자의 인증서가 승격된 역할을 포함하고 있으므로
특정적으로 승인된 리소스에 대한 접근만 허용해야 하기 때문입니다.
tsh request drop 명령어를 사용하여 요청을 "드롭"하고 일반 접근을 복원합니다.

tsh request drop

다음 단계

SSH에 대한 자동 접근 요청

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

tsh ssh alice@iot
ERROR: acceso denegado a alice conectándose a iot en el clúster teleport.example.com  
현재 alice@iot에 대한 접근 권한이 없으므로 접근을 요청하려고 합니다.  
요청 이유를 입력하세요: please  요청 생성 중...  Request ID: ab43fc70-e893-471b-872e-ae65eb24fd76  사용자:   alice  역할:      access  리소스:  ["/teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f"]  이유:     "please"  검토자:  [없음] (제안됨)  상태:     PENDING  
힌트: 'tsh login --request-id=<request-id>'를 사용하여 승인된 요청으로 로그인하세요.  
요청 승인 대기 중...
승인 수신, 이유="okay"  업데이트된 인증서를 가져오고 있습니다...
iot:~ alice$

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

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

사용자가 요청할 수 있는 리소스를 검색하는 데 더 많은 제약을 부과할 수 있습니다.
search_as_roles를 더 제한된 역할로 할당하여 특정 리소스에 대한 접근을 제한할 수 있습니다.
아래에서는 사용자의 검색 능력을 제한하기 위해 설정해야 할 권한을 보여줍니다.

특정 리소스에 대한 접근을 제한하기 위해 아래와 유사한 역할을 사용하는 경우 사용자의 역할 중 하나를 수정하여
search_as_roles 필드에 생성한 역할을 포함시키면 됩니다.

Teleport 역할을 사용하여 RBAC을 구성하는 방법에 대한 전체 세부정보는
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 Pods에 대한 접근을 허용하며, dev 네임스페이스의 모든 Pods에 대한 접근도 허용합니다.

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를 접근이 제한된 Kubernetes 리소스 외에 하나임을 확인해야 합니다.

이는 사용자가 Kubernetes Pod에 대한 접근을 요청하고 요청이 승인되면,
Teleport Kubernetes 서비스는 역할 내의 kubernetes_groups 및 kubernetes_users 필드를 사용하여
사용자의 요청에 대한 조작 헤더를 Kubernetes API 서버에 추가합니다.
이러한 조건에서 Teleport는 위에 언급된 모든 Kubernetes 리소스 종류에 대한 접근을 제한할 수 있지만
원하는 pod에 대한 접근은 제외됩니다.
Teleport는 네임스페이스 범위의 사용자 정의 자원에 대한 접근을 제한할 수 있지만 클러스터 범위의 사용자 정의 자원은 제한할 수 없습니다.

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 네임스페이스가 있는 리소스의 형식은 다음과 같습니다.

/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이라는 이름의 Pod에 대한 접근을 요청하려면 다음을 실행합니다.

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

NAMESPACE 및 RESOURCE_NAME 값에 대해서는 와일드카드(*) 또는 정규 표현식 사용으로 특정 문자열 범위를 일치시킬 수 있습니다.
정규 표현식은 ^로 시작하고 $로 끝나야 합니다.

예를 들어, 모든 네임스페이스에 있는 nginx라는 이름의 모든 Pod에 접근하기 위해 아래와 같이 명령어를 실행할 수 있습니다.

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

클러스터 범위 리소스

Kubernetes 클러스터 범위 리소스의 형식은 다음과 같습니다.

/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로 시작하는 모든 네임스페이스에 대한 접근을 요청하려면 아래 명령어를 실행할 수 있습니다.

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]
이름               네임스페이스 라벨    리소스 ID  -----------------  --------- --------- ----------------------------------------------------------nginx-deployment-0 default   app=nginx /teleport.example.com/pod/local/default/nginx-deployment-0  nginx-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
이름  호스트 이름 라벨 리소스 ID  ----- -------- ------ ----------------------------------------  local                 /teleport.example.com/kube_cluster/local

외부 도구와 통합하기

Teleport의 접근 요청 플러그인을 통해 사용자는 조직의 기존 메시징 및 프로젝트 관리 솔루션 내에서 접근 요청을 관리할 수 있습니다.

통합	유형	설정 지침
Slack	메시징	Slack 설정하기
Mattermost	메시징	Mattermost 설정하기
Microsoft Teams	메시징	Microsoft Teams 설정하기
Jira	프로젝트 보드	Jira 설정하기
PagerDuty	일정	PagerDuty 설정하기
이메일	메시징	이메일 설정하기
Discord	메시징	Discord 설정하기
OpsGenie	사고 관리	OpsGenie 설정하기
ServiceNow	워크플로우	ServiceNow 설정하기

다음 단계

접근 목록에 대해 더 알아보세요.

Teleport 원문 보기