Teleport는 HTTP 및 TCP 애플리케이션에 대한 접근을 보호하고 제어합니다. 머신 ID는 이러한 애플리케이션에 대해 안전하고 짧은 기간 동안의 접근 권한을 부여하는 데 사용될 수 있습니다.

이 가이드에서는 tbot을 구성하여 Teleport 클러스터에 등록된 애플리케이션에 접근하는 데 사용할 수 있는 자격 증명을 생성할 것입니다.

필수조건

• 실행 중인 Teleport 클러스터 버전 이상. Teleport를 시작하려면, 가입하기 위해 무료 평가판에 등록하거나 데모 환경 설정하기를 참조하세요.

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

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

• 아직 애플리케이션을 Teleport에 연결하지 않았다면, 애플리케이션 접근 시작하기 가이드를 따르세요.
• 당신의 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 명령어를 실행할 수도 있습니다.
• tbot은 애플리케이션에 접근할 머신에 이미 설치되고 구성되어 있어야 합니다. 자세한 내용은 배포 가이드를 참조하세요.

1단계/3단계. RBAC 구성

먼저, tbot에서 생성된 자격 증명이 애플리케이션에 연결하는 데 사용될 수 있도록 Teleport를 구성해야 합니다. 이는 필요한 권한을 부여하는 역할을 생성하고, 이 역할을 봇에 할당함으로써 수행됩니다.

다음 내용을 포함한 role.yaml이라는 파일을 생성하세요:

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

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

이것은 모든 애플리케이션에 접근 권한을 부여합니다. 생산 환경에서는 머신이 접근해야 하는 애플리케이션만 허용하도록 이러한 레이블을 수정해야 합니다.

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

이제 tctl bots update를 사용하여 봇에 역할을 추가하세요. example을 배포 가이드에서 생성한 봇의 이름으로, example-role을 방금 생성한 역할의 이름으로 교체하세요:

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

2단계/3단계. tbot 구성

클라이언트가 애플리케이션에 접근을 허용하기 위해 tbot을 사용할 때 두 가지 구현 옵션이 있습니다. 선택한 옵션은 특정 요구 사항에 따라 달라집니다.

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

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

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

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

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

3단계/3단계. 머신 ID 신원을 사용하여 웹 애플리케이션에 연결

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 옵션을 활성화할 수도 있습니다:

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

이는 /opt/machine-id 내부에 tls.crt 및 tls.key를 생성하여 위의 인증서 파일과 동일한 내용으로 생성합니다.

클라이언트가 Teleport 로그인 페이지로 리디렉션됨

인간 사용자와 마찬가지로 스크립트 클라이언트는 유효한 자격 증명 없이 Teleport 프록시 서비스를 통해 애플리케이션에 접근하려 할 때 Teleport 로그인 페이지로 리디렉션됩니다.

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

다음 단계

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