Teleport는 HTTP 및 TCP 애플리케이션에 대한 접근을 보호하고 제어합니다. Machine & Workload Identity를 사용하면 머신에 이러한 애플리케이션에 대한 안전하고 단명(short-lived)하는 접근 권한을 부여할 수 있습니다.

이 가이드에서는 Machine & Workload Identity의 에이전트인 tbot을 구성하여, Teleport 클러스터에 등록된 애플리케이션에 접근하는 데 사용할 수 있는 자격 증명을 생성하는 방법을 설명합니다.

사전 요구 사항#

• 실행 중인 Teleport 클러스터. 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에 연결하지 않았다면 Teleport로 웹 애플리케이션 보호하기 가이드를 따르세요.

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 명령을 실행할 수도 있습니다.

• 애플리케이션에 접근할 머신에 tbot이 이미 설치 및 구성되어 있어야 합니다. 자세한 내용은 배포 가이드를 참조하세요.

Step 1/3. RBAC 구성#

먼저 tbot이 생성한 자격 증명으로 애플리케이션에 연결할 수 있도록 Teleport를 구성해야 합니다. 이는 필요한 권한을 부여하는 역할을 생성한 다음 이 역할을 Bot에 할당하여 수행합니다.

다음 내용으로 role.yaml 파일을 생성합니다:

kind: role
version: v6
metadata:
  name: example-role
spec:
  allow:
    # 모든 애플리케이션에 대한 접근 권한을 부여합니다.
    app_labels:
      '*': '*'

example-role을 사용 사례와 관련된 설명적인 이름으로 바꾸세요.

이렇게 하면 모든 애플리케이션에 대한 접근 권한이 부여됩니다. 운영 환경에서는 머신이 접근해야 하는 애플리케이션에만 접근 권한을 부여하도록 이 라벨을 수정해야 합니다.

tctl create -f ./role.yaml을 사용하여 역할을 생성하세요.

이제 tctl bots update를 사용하여 Bot에 역할을 추가합니다. example은 배포 가이드에서 생성한 Bot의 이름으로, example-role은 방금 생성한 역할의 이름으로 바꾸세요:

$ tctl bots update example --add-roles example-role

Step 2/3. tbot 구성#

tbot을 사용하여 클라이언트에 애플리케이션 접근 권한을 부여할 때 사용할 수 있는 두 가지 구현 옵션이 있습니다. 선택할 옵션은 구체적인 요구 사항에 따라 달라집니다.

첫 번째 옵션은 application-tunnel 서비스입니다. 이 서비스는 클라이언트가 연결할 수 있는 로컬 프록시를 운영합니다. 이 서비스는 연결에 자격 증명을 자동으로 첨부하므로 클라이언트가 클라이언트 인증서를 지원할 필요가 없습니다. 다만 클라이언트가 애플리케이션에 접근하려면 tbot 프로세스가 실행 중이어야 합니다.

두 번째 옵션은 application 출력 서비스입니다. 이 서비스는 TLS 자격 증명을 클라이언트가 읽을 수 있는 대상 위치에 기록합니다. 클라이언트는 클라이언트 인증서를 지원해야 하며, 인증서가 갱신될 때 디스크에서 다시 불러올 수 있어야 합니다. 또한 이 옵션은 클라이언트와 Teleport Proxy 서비스 사이에 있는 TLS 종료(TLS-terminating) 로드 밸런서와 호환되지 않습니다. application-tunnel과 달리, 클라이언트가 애플리케이션에 접근하기 위해 tbot 프로세스가 실행 중일 필요는 없으며, 이는 CI/CD 파이프라인에 이상적일 수 있습니다.

어느 것을 사용해야 할지 확실하지 않다면, 더 많은 클라이언트와 호환되는 application-tunnel 서비스로 시작하는 것을 권장합니다.

services:
- type: application-tunnel
  app_name: dumper
  listen: tcp://127.0.0.1:1234

services:
- type: application
  # 자격 증명이 접근 권한을 부여하기를 원하는 애플리케이션의 이름을
  # 지정합니다.
  app_name: dumper
  destination:
    type: directory
    # 이 가이드에서는 /opt/machine-id를 대상 디렉터리로 사용합니다.
    # 이를 원하는 대로 커스터마이즈할 수 있습니다. 여러 출력 서비스가 동일한
    # 대상을 공유할 수는 없습니다.
    path: /opt/machine-id

Step 3/3. 웹 애플리케이션에 연결#

$ curl http://127.0.0.1:1234/

$ curl \
--cert /opt/machine-id/tlscert \
--key /opt/machine-id/key \
https://dumper.example.teleport.sh/

문제 해결#

클라이언트 애플리케이션에 표준 확장자를 가진 인증서가 필요한 경우#

자동화된 서비스에 특정 파일 확장자를 가진 TLS 인증서가 필요한 경우, 출력 서비스에서 specific_tls_naming 옵션을 활성화할 수도 있습니다:

services:
- type: application
  destination:
    type: directory
    path: /opt/machine-id
  app_name: grafana-example
  specific_tls_naming: true

이렇게 하면 위에 나열된 인증서 파일과 동일한 내용을 가진 tls.crt 및 tls.key가 /opt/machine-id 안에 생성됩니다.

클라이언트가 Teleport 로그인 페이지로 리디렉션되는 경우#

일반 사용자와 마찬가지로, 스크립트로 작성된 클라이언트도 유효한 자격 증명 없이 Teleport Proxy 서비스를 통해 앱에 접근을 시도하면 Teleport 로그인 페이지로 리디렉션됩니다.

Bot의 인증서가 만료되지 않았는지, 클라이언트 애플리케이션이 클라이언트 인증서와 키를 모두 사용하도록 구성되어 있는지 확인하세요.

다음 단계#

• Bot이 접근할 수 있는 애플리케이션 및 기타 Teleport 리소스를 제한하는 방법을 알아보려면 접근 제어 참조를 살펴보세요.
• 애플리케이션에 대한 추가 로그인 자격 증명의 필요성을 없애려면 JWT를 구성하세요.
• 사용 가능한 모든 구성 옵션을 살펴보려면 구성 참조를 읽어보세요.