InfoGrab Docs

Docker에 Teleport 설치

요약

Docker는 컨테이너화된 환경에 Teleport를 배포하는 편리한 방법을 제공하며, 플랫폼 전반에 걸쳐 일관된 배포와 간소화된 종속성 관리를 제공합니다. 이 설치 가이드에서는 올바른 이미지를 선택하고, 컨테이너를 구성하고, Docker로 Teleport 서비스를 실행하는 방법을 배웁니다.

Docker는 컨테이너화된 환경에 Teleport를 배포하는 편리한 방법을 제공하며, 플랫폼 전반에 걸쳐 일관된 배포와 간소화된 종속성 관리를 제공합니다. Teleport의 사전 빌드된 Docker 이미지는 프로덕션 배포부터 개발 및 문제 해결 시나리오까지 다양한 사용 사례에 최적화되어 있습니다.

이 설치 가이드에서는 올바른 이미지를 선택하고, 컨테이너를 구성하고, Docker로 Teleport 서비스를 실행하는 방법을 배웁니다.

이미지#

모든 Teleport 버전에 대한 사전 빌드된 Docker 이미지를 제공합니다. 이 섹션에서는 사용 가능한 Docker 이미지를 설명합니다.

이 이미지는 Amazon ECR Public에서 호스팅됩니다.

이미지 접미사#

이 섹션에 나열된 각 이미지 이름에 대해 저장소 이름 또는 태그에 접미사를 추가하여 이미지의 속성을 지정할 수 있습니다.

저장소 이름에 -distroless 접미사가 있는 이미지는 teleport 바이너리와 런타임 종속성만 포함하며 쉘이나 유틸리티 애플리케이션은 없습니다. 예를 들어 Teleport Community Edition의 경우 public.ecr.aws/gravitational/teleport-distroless입니다.

저장소 이름에 *-distroless-debug 접미사가 있는 이미지는 Teleport 외에 Busybox 쉘 및 도구 모음을 포함하며 배포 문제 해결 전용입니다. 프로덕션 사용을 위한 것이 아닙니다. 예를 들어 public.ecr.aws/gravitational/teleport-distroless-debug입니다.

*-distroless*-distroless-debug 이미지는 여러 아키텍처를 기본적으로 지원하며 이미지 접미사가 필요하지 않습니다(또는 지원하지 않습니다). docker pull--platform 플래그를 사용하여 이미지의 arm, arm64 또는 amd64 버전을 가져올 수 있습니다.

버전 태그#

이미지는 정적 버전의 Teleport를 가리킵니다. 이미지 태그를 사용하여 다음 중 하나를 지정합니다:

  • 주, 부, 패치 버전 (예: Teleport Community Edition의 최신 버전은 <code>[teleport.version]</code>).
  • 주 버전만 지정하면 해당 주 버전의 최신 부 및 패치 번호를 의미합니다. 예를 들어 <code>[teleport.major_version]</code><code>[teleport.version]</code>을 의미합니다.
이미지 이름 문제 해결 도구 포함 이미지 베이스
public.ecr.aws/gravitational/teleport-ent-distroless:<code>[cloud.version]</code> No Distroless Debian 12
public.ecr.aws/gravitational/teleport-ent-distroless-debug:<code>[cloud.version]</code> Yes Distroless Debian 12

테스트를 위해 항상 최신 Cloud 릴리즈 버전인 public.ecr.aws/gravitational/teleport-ent-distroless:<code>[cloud.version]</code>을 사용하는 것을 권장합니다.

이미지 이름 문제 해결 도구 포함 이미지 베이스
<code>[teleport.latest_ent_docker_image]</code> No Distroless Debian 12
<code>[teleport.latest_ent_debug_docker_image]</code> Yes Distroless Debian 12

Teleport Enterprise의 FIPS 빌드를 위한 다음 이미지도 제공합니다:

이미지 이름 문제 해결 도구 포함 이미지 베이스
public.ecr.aws/gravitational/teleport-ent-fips-distroless:<code>[teleport.version]</code> No Distroless Debian 12
public.ecr.aws/gravitational/teleport-ent-fips-distroless-debug:<code>[teleport.version]</code> Yes Distroless Debian 12

테스트를 위해 항상 최신 릴리즈 버전인 <code>[teleport.latest_ent_docker_image]</code>을 사용하는 것을 권장합니다.

이미지 이름 문제 해결 도구? 이미지 베이스
<code>[teleport.latest_oss_docker_image]</code> No Distroless Debian 12
<code>[teleport.latest_oss_debug_docker_image]</code> Yes Distroless Debian 12

테스트를 위해 항상 최신 릴리즈 버전인 <code>[teleport.latest_oss_docker_image]</code>을 사용하는 것을 권장합니다.

distroless 이미지와 상호 작용#

Teleport 이미지는 Google의 Distroless 이미지를 기반으로 합니다. 이 이미지에는 쉘이 없습니다.

이 이미지를 기반으로 하는 컨테이너에서 Teleport 명령을 실행하려면 다음과 유사한 명령을 실행합니다:

# in docker
$ docker run -i my-container tctl status

# in Kubernetes
$ kubectl exec -i my-pod -- tctl status

# sending local files via stdin
$ kubectl exec -i my-pod -- tctl create -f < my-local-file.yaml

# retrieving the teleport service config file from the configmap
$ kubectl get configmap teleport-cluster-auth -o jsonpath="{.data['teleport\.yaml']}"

# retrieving output via stdout and tar
$ kubectl exec -i my-pod -- tctl auth sign --user admin --format tls --ttl 10m --tar -o admin| tar xv -C local
$ ls -l local
total 24
-rw-------  1 trent  staff  1318 Jul 24 15:52 admin.cas
-rw-------  1 trent  staff  1895 Jul 24 15:52 admin.crt
-rw-------  1 trent  staff  1679 Jul 24 15:52 admin.key

또는 busyboxbusybox sh를 통해 호출 가능한 최소 쉘이 포함된 이미지의 디버그 변형을 사용할 수 있습니다:

$ docker run -it --entrypoint="" (=teleport.latest_oss_debug_docker_image=) busybox sh

머신 및 워크로드 아이덴티티 (tbot)#

Teleport 머신 및 워크로드 아이덴티티에 사용하기 위해 tbot 바이너리만 포함하는 슬림다운된 distroless 이미지도 제공합니다.

이미지 이름 FIPS 지원 이미지 베이스
public.ecr.aws/gravitational/tbot-distroless:<code>[teleport.version]</code> No Distroless Debian 12
public.ecr.aws/gravitational/tbot-fips-distroless:<code>[teleport.version]</code> Yes Distroless Debian 12

버전 태그는 주 teleport-distroless 이미지와 동일한 패턴을 따릅니다.

teleport-distroless 이미지도 tbot을 포함하지만 머신 및 워크로드 아이덴티티 배포에는 tbot 전용 이미지를 사용하는 것이 선호됩니다. 이 이미지는 더 작아 pull 시간이 개선되며 공격 면이 더 작습니다. 또한 컨테이너 환경에서 tbot을 실행하는 경험을 개선하기 위해 이미지가 커스터마이즈되어 있습니다.

자세한 내용은 Kubernetes에서 머신 및 워크로드 아이덴티티 배포 가이드를 읽어보세요.

Docker에서 Teleport 실행#

위에 나열된 이미지 중 하나에서 컨테이너를 실행할 때 컨테이너는 teleport 바이너리 실행과 동일합니다. Teleport 컨테이너는 파일 시스템과 네트워크 포트에 대한 접근이 필요합니다.

구성#

Teleport 프로세스는 로컬 파일 경로에서 구성을 읽으며 기본값은 /etc/teleport.yaml입니다. 이 파일 경로가 Teleport 컨테이너에 마운트되어 있는지 확인합니다.

데이터 디렉터리#

모든 Teleport 프로세스는 데이터 디렉터리를 읽고 씁니다. 기본값은 /var/lib/teleport입니다. 데이터 디렉터리가 Teleport 컨테이너에 마운트되어 있는지 확인합니다.

라이선스 파일#

Teleport Enterprise 컨테이너가 Auth Service를 실행하는 경우 구성에 명명된 경로의 라이선스 파일에 접근할 수 있어야 하며 기본값은 /var/lib/teleport/license.pem입니다. Teleport 컨테이너의 데이터 디렉터리에 이 위치에 라이선스가 있는지 확인합니다.

기타 파일 경로#

Teleport 컨테이너에 할당하는 구성 설정에 따라 명명하는 파일 경로가 컨테이너에 마운트되어 있는지 확인해야 합니다.

예를 들어 컨테이너에서 Teleport Proxy Service를 실행하는 경우 TLS 자격 증명이 포함된 디렉터리를 Teleport 컨테이너에 마운트한 다음 컨테이너의 구성 파일에서 다음 필드를 적절한 경로로 할당해야 합니다:

proxy_service:
  https_keypairs:
  - key_file: /my/path/key.pem
    cert_file: /my/path/cert.pem

할당하려는 필드에 파일 경로가 필요한지 여부는 Teleport 구성 레퍼런스를 참조하세요.

포트#

단일 Teleport 프로세스는 여러 서비스를 실행할 수 있으며 각 서비스는 구성에 따라 특정 포트 세트에서 수신 대기합니다. Teleport 컨테이너에서 노출할 포트는 네트워킹 레퍼런스를 참조하세요.

distroless 이미지에서 인증서 추출#

distroless 이미지를 실행하는 컨테이너에서 tctl auth sign으로 생성된 인증서를 추출하는 것은 쉘 및 기타 OS 도구의 부재로 인해 까다로울 수 있습니다.

가능한 경우 tsh를 사용하여 Teleport 클러스터에 로그인하고 로컬에서 tctl auth sign을 사용하여 인증서를 생성해야 합니다. 이 방법으로 작업이 Teleport 사용자에 대해 기록되고 클러스터의 모든 일반적인 Teleport RBAC 정책이 적용됩니다.

가능하지 않은 경우 tctl auth sign --tar를 사용하여 tctl auth sign으로 생성된 모든 파일을 tar 아카이브로 수집하고 이를 stdout으로 직접 스트리밍합니다. 결과 인증서는 컨테이너 파일 시스템에 저장되지 않습니다. 이 출력을 직접 tar에 파이프하거나 나중에 사용할 로컬 파일로 리디렉션할 수 있습니다.

예를 들어:

$ docker exec ${TELEPORT_CONTAINER} \
  tctl auth sign --user alice --format tls -o alice.local --tar | tar xv
x alice.local.crt
x alice.local.key
x alice.local.cas

Teleport 컨테이너 실행 예시#

이 예시에서는 Teleport Community Edition을 사용하여 로컬 Docker 컨테이너에서 Teleport Auth Service 및 Proxy Service를 실행하는 방법을 보여줍니다.

이 컨테이너는 자체 서명 인증서를 사용하므로 워크스테이션 외부의 인프라를 보호하기 위해 이 구성을 사용하는 것은 권장하지 않습니다. 그러나 토큰 방법을 사용하여 다른 로컬 Docker 컨테이너를 여기에 조인할 수 있습니다.

먼저 컨테이너에 마운트할 홈 디렉터리에 디렉터리를 생성합니다. Teleport 컨테이너는 구성 및 데이터를 이 디렉터리에 씁니다:

$ mkdir -p ~/teleport/config ~/teleport/data

Teleport 컨테이너에서 teleport configure를 실행하여 구성 파일을 생성합니다. 이렇게 하면 컨테이너 이름이 localhost로 설정되어 브라우저가 Proxy Service의 자체 서명 TLS 인증서를 신뢰할 수 있습니다:

$ docker run --hostname localhost --rm \
  --entrypoint=/usr/local/bin/teleport \
   configure --roles=proxy,auth > ~/teleport/config/teleport.yaml

컨테이너에서 Teleport를 시작합니다:

$ docker run --hostname localhost --name teleport \
  -v ~/teleport/config:/etc/teleport \
  -v ~/teleport/data:/var/lib/teleport \
  -p 3025:3025 -p 3080:3080 \
  

그 후 다른 터미널을 열고 Teleport 컨테이너의 웹 API가 의도한 대로 작동하는지 확인합니다:

$ curl --insecure https://localhost:3080/webapi/ping | jq

다음과 유사한 JSON 출력이 표시되어야 합니다:

{
  "auth": {
    "type": "local",
    "second_factor": "otp",
    "preferred_local_mfa": "otp",
    "local": {
      "name": ""
    },
    "private_key_policy": "none",
    "device_trust_disabled": true,
    "has_motd": false
  },
  "proxy": {
    "kube": {
      "enabled": true,
      "listen_addr": "0.0.0.0:3080"
    },
    "ssh": {
      "listen_addr": "0.0.0.0:3080",
      "tunnel_listen_addr": "0.0.0.0:3080",
      "web_listen_addr": "0.0.0.0:3080"
    },
    "db": {
      "postgres_listen_addr": "0.0.0.0:3080",
      "mysql_listen_addr": "0.0.0.0:3080"
    },
    "tls_routing_enabled": true
  },
  "server_version": "12.1.5",
  "min_client_version": "11.0.0",
  "cluster_name": "localhost",
  "automatic_upgrades": false
}

--insecure 플래그를 사용하여 Teleport의 자체 서명 인증서를 신뢰합니다. 프로덕션에서는 Let's Encrypt 등 신뢰할 수 있는 CA에서 Proxy Service에 TLS 자격 증명을 프로비저닝하는 것이 좋습니다.

Docker에서 Teleport 업그레이드#

Docker에서 실행 중인 Teleport 컨테이너를 업그레이드하려면:

  1. 컨테이너의 데이터 디렉터리를 그대로 둡니다.
  2. 컨테이너를 중지합니다.
  3. 초기에 컨테이너를 실행할 때처럼 데이터 디렉터리를 마운트하여 최신 Teleport 버전 기반의 이미지로 새 컨테이너를 실행합니다. 데이터 디렉터리에 업그레이드 전과 동일한 내용이 있는 한 Teleport 컨테이너는 클러스터에 다시 조인할 필요가 없습니다.

Docker에 Teleport 설치

원문 보기
요약

Docker는 컨테이너화된 환경에 Teleport를 배포하는 편리한 방법을 제공하며, 플랫폼 전반에 걸쳐 일관된 배포와 간소화된 종속성 관리를 제공합니다. 이 설치 가이드에서는 올바른 이미지를 선택하고, 컨테이너를 구성하고, Docker로 Teleport 서비스를 실행하는 방법을 배웁니다.

Docker는 컨테이너화된 환경에 Teleport를 배포하는 편리한 방법을 제공하며, 플랫폼 전반에 걸쳐 일관된 배포와 간소화된 종속성 관리를 제공합니다. Teleport의 사전 빌드된 Docker 이미지는 프로덕션 배포부터 개발 및 문제 해결 시나리오까지 다양한 사용 사례에 최적화되어 있습니다.

이 설치 가이드에서는 올바른 이미지를 선택하고, 컨테이너를 구성하고, Docker로 Teleport 서비스를 실행하는 방법을 배웁니다.

이미지#

모든 Teleport 버전에 대한 사전 빌드된 Docker 이미지를 제공합니다. 이 섹션에서는 사용 가능한 Docker 이미지를 설명합니다.

이 이미지는 Amazon ECR Public에서 호스팅됩니다.

이미지 접미사#

이 섹션에 나열된 각 이미지 이름에 대해 저장소 이름 또는 태그에 접미사를 추가하여 이미지의 속성을 지정할 수 있습니다.

저장소 이름에 -distroless 접미사가 있는 이미지는 teleport 바이너리와 런타임 종속성만 포함하며 쉘이나 유틸리티 애플리케이션은 없습니다. 예를 들어 Teleport Community Edition의 경우 public.ecr.aws/gravitational/teleport-distroless입니다.

저장소 이름에 *-distroless-debug 접미사가 있는 이미지는 Teleport 외에 Busybox 쉘 및 도구 모음을 포함하며 배포 문제 해결 전용입니다. 프로덕션 사용을 위한 것이 아닙니다. 예를 들어 public.ecr.aws/gravitational/teleport-distroless-debug입니다.

*-distroless*-distroless-debug 이미지는 여러 아키텍처를 기본적으로 지원하며 이미지 접미사가 필요하지 않습니다(또는 지원하지 않습니다). docker pull--platform 플래그를 사용하여 이미지의 arm, arm64 또는 amd64 버전을 가져올 수 있습니다.

버전 태그#

이미지는 정적 버전의 Teleport를 가리킵니다. 이미지 태그를 사용하여 다음 중 하나를 지정합니다:

  • 주, 부, 패치 버전 (예: Teleport Community Edition의 최신 버전은 <code>[teleport.version]</code>).
  • 주 버전만 지정하면 해당 주 버전의 최신 부 및 패치 번호를 의미합니다. 예를 들어 <code>[teleport.major_version]</code><code>[teleport.version]</code>을 의미합니다.
이미지 이름 문제 해결 도구 포함 이미지 베이스
public.ecr.aws/gravitational/teleport-ent-distroless:<code>[cloud.version]</code> No Distroless Debian 12
public.ecr.aws/gravitational/teleport-ent-distroless-debug:<code>[cloud.version]</code> Yes Distroless Debian 12

테스트를 위해 항상 최신 Cloud 릴리즈 버전인 public.ecr.aws/gravitational/teleport-ent-distroless:<code>[cloud.version]</code>을 사용하는 것을 권장합니다.

이미지 이름 문제 해결 도구 포함 이미지 베이스
<code>[teleport.latest_ent_docker_image]</code> No Distroless Debian 12
<code>[teleport.latest_ent_debug_docker_image]</code> Yes Distroless Debian 12

Teleport Enterprise의 FIPS 빌드를 위한 다음 이미지도 제공합니다:

이미지 이름 문제 해결 도구 포함 이미지 베이스
public.ecr.aws/gravitational/teleport-ent-fips-distroless:<code>[teleport.version]</code> No Distroless Debian 12
public.ecr.aws/gravitational/teleport-ent-fips-distroless-debug:<code>[teleport.version]</code> Yes Distroless Debian 12

테스트를 위해 항상 최신 릴리즈 버전인 <code>[teleport.latest_ent_docker_image]</code>을 사용하는 것을 권장합니다.

이미지 이름 문제 해결 도구? 이미지 베이스
<code>[teleport.latest_oss_docker_image]</code> No Distroless Debian 12
<code>[teleport.latest_oss_debug_docker_image]</code> Yes Distroless Debian 12

테스트를 위해 항상 최신 릴리즈 버전인 <code>[teleport.latest_oss_docker_image]</code>을 사용하는 것을 권장합니다.

distroless 이미지와 상호 작용#

Teleport 이미지는 Google의 Distroless 이미지를 기반으로 합니다. 이 이미지에는 쉘이 없습니다.

이 이미지를 기반으로 하는 컨테이너에서 Teleport 명령을 실행하려면 다음과 유사한 명령을 실행합니다:

# in docker
$ docker run -i my-container tctl status

# in Kubernetes
$ kubectl exec -i my-pod -- tctl status

# sending local files via stdin
$ kubectl exec -i my-pod -- tctl create -f < my-local-file.yaml

# retrieving the teleport service config file from the configmap
$ kubectl get configmap teleport-cluster-auth -o jsonpath="{.data['teleport\.yaml']}"

# retrieving output via stdout and tar
$ kubectl exec -i my-pod -- tctl auth sign --user admin --format tls --ttl 10m --tar -o admin| tar xv -C local
$ ls -l local
total 24
-rw-------  1 trent  staff  1318 Jul 24 15:52 admin.cas
-rw-------  1 trent  staff  1895 Jul 24 15:52 admin.crt
-rw-------  1 trent  staff  1679 Jul 24 15:52 admin.key

또는 busyboxbusybox sh를 통해 호출 가능한 최소 쉘이 포함된 이미지의 디버그 변형을 사용할 수 있습니다:

$ docker run -it --entrypoint="" (=teleport.latest_oss_debug_docker_image=) busybox sh

머신 및 워크로드 아이덴티티 (tbot)#

Teleport 머신 및 워크로드 아이덴티티에 사용하기 위해 tbot 바이너리만 포함하는 슬림다운된 distroless 이미지도 제공합니다.

이미지 이름 FIPS 지원 이미지 베이스
public.ecr.aws/gravitational/tbot-distroless:<code>[teleport.version]</code> No Distroless Debian 12
public.ecr.aws/gravitational/tbot-fips-distroless:<code>[teleport.version]</code> Yes Distroless Debian 12

버전 태그는 주 teleport-distroless 이미지와 동일한 패턴을 따릅니다.

teleport-distroless 이미지도 tbot을 포함하지만 머신 및 워크로드 아이덴티티 배포에는 tbot 전용 이미지를 사용하는 것이 선호됩니다. 이 이미지는 더 작아 pull 시간이 개선되며 공격 면이 더 작습니다. 또한 컨테이너 환경에서 tbot을 실행하는 경험을 개선하기 위해 이미지가 커스터마이즈되어 있습니다.

자세한 내용은 Kubernetes에서 머신 및 워크로드 아이덴티티 배포 가이드를 읽어보세요.

Docker에서 Teleport 실행#

위에 나열된 이미지 중 하나에서 컨테이너를 실행할 때 컨테이너는 teleport 바이너리 실행과 동일합니다. Teleport 컨테이너는 파일 시스템과 네트워크 포트에 대한 접근이 필요합니다.

구성#

Teleport 프로세스는 로컬 파일 경로에서 구성을 읽으며 기본값은 /etc/teleport.yaml입니다. 이 파일 경로가 Teleport 컨테이너에 마운트되어 있는지 확인합니다.

데이터 디렉터리#

모든 Teleport 프로세스는 데이터 디렉터리를 읽고 씁니다. 기본값은 /var/lib/teleport입니다. 데이터 디렉터리가 Teleport 컨테이너에 마운트되어 있는지 확인합니다.

라이선스 파일#

Teleport Enterprise 컨테이너가 Auth Service를 실행하는 경우 구성에 명명된 경로의 라이선스 파일에 접근할 수 있어야 하며 기본값은 /var/lib/teleport/license.pem입니다. Teleport 컨테이너의 데이터 디렉터리에 이 위치에 라이선스가 있는지 확인합니다.

기타 파일 경로#

Teleport 컨테이너에 할당하는 구성 설정에 따라 명명하는 파일 경로가 컨테이너에 마운트되어 있는지 확인해야 합니다.

예를 들어 컨테이너에서 Teleport Proxy Service를 실행하는 경우 TLS 자격 증명이 포함된 디렉터리를 Teleport 컨테이너에 마운트한 다음 컨테이너의 구성 파일에서 다음 필드를 적절한 경로로 할당해야 합니다:

proxy_service:
  https_keypairs:
  - key_file: /my/path/key.pem
    cert_file: /my/path/cert.pem

할당하려는 필드에 파일 경로가 필요한지 여부는 Teleport 구성 레퍼런스를 참조하세요.

포트#

단일 Teleport 프로세스는 여러 서비스를 실행할 수 있으며 각 서비스는 구성에 따라 특정 포트 세트에서 수신 대기합니다. Teleport 컨테이너에서 노출할 포트는 네트워킹 레퍼런스를 참조하세요.

distroless 이미지에서 인증서 추출#

distroless 이미지를 실행하는 컨테이너에서 tctl auth sign으로 생성된 인증서를 추출하는 것은 쉘 및 기타 OS 도구의 부재로 인해 까다로울 수 있습니다.

가능한 경우 tsh를 사용하여 Teleport 클러스터에 로그인하고 로컬에서 tctl auth sign을 사용하여 인증서를 생성해야 합니다. 이 방법으로 작업이 Teleport 사용자에 대해 기록되고 클러스터의 모든 일반적인 Teleport RBAC 정책이 적용됩니다.

가능하지 않은 경우 tctl auth sign --tar를 사용하여 tctl auth sign으로 생성된 모든 파일을 tar 아카이브로 수집하고 이를 stdout으로 직접 스트리밍합니다. 결과 인증서는 컨테이너 파일 시스템에 저장되지 않습니다. 이 출력을 직접 tar에 파이프하거나 나중에 사용할 로컬 파일로 리디렉션할 수 있습니다.

예를 들어:

$ docker exec ${TELEPORT_CONTAINER} \
  tctl auth sign --user alice --format tls -o alice.local --tar | tar xv
x alice.local.crt
x alice.local.key
x alice.local.cas

Teleport 컨테이너 실행 예시#

이 예시에서는 Teleport Community Edition을 사용하여 로컬 Docker 컨테이너에서 Teleport Auth Service 및 Proxy Service를 실행하는 방법을 보여줍니다.

이 컨테이너는 자체 서명 인증서를 사용하므로 워크스테이션 외부의 인프라를 보호하기 위해 이 구성을 사용하는 것은 권장하지 않습니다. 그러나 토큰 방법을 사용하여 다른 로컬 Docker 컨테이너를 여기에 조인할 수 있습니다.

먼저 컨테이너에 마운트할 홈 디렉터리에 디렉터리를 생성합니다. Teleport 컨테이너는 구성 및 데이터를 이 디렉터리에 씁니다:

$ mkdir -p ~/teleport/config ~/teleport/data

Teleport 컨테이너에서 teleport configure를 실행하여 구성 파일을 생성합니다. 이렇게 하면 컨테이너 이름이 localhost로 설정되어 브라우저가 Proxy Service의 자체 서명 TLS 인증서를 신뢰할 수 있습니다:

$ docker run --hostname localhost --rm \
  --entrypoint=/usr/local/bin/teleport \
   configure --roles=proxy,auth > ~/teleport/config/teleport.yaml

컨테이너에서 Teleport를 시작합니다:

$ docker run --hostname localhost --name teleport \
  -v ~/teleport/config:/etc/teleport \
  -v ~/teleport/data:/var/lib/teleport \
  -p 3025:3025 -p 3080:3080 \
  

그 후 다른 터미널을 열고 Teleport 컨테이너의 웹 API가 의도한 대로 작동하는지 확인합니다:

$ curl --insecure https://localhost:3080/webapi/ping | jq

다음과 유사한 JSON 출력이 표시되어야 합니다:

{
  "auth": {
    "type": "local",
    "second_factor": "otp",
    "preferred_local_mfa": "otp",
    "local": {
      "name": ""
    },
    "private_key_policy": "none",
    "device_trust_disabled": true,
    "has_motd": false
  },
  "proxy": {
    "kube": {
      "enabled": true,
      "listen_addr": "0.0.0.0:3080"
    },
    "ssh": {
      "listen_addr": "0.0.0.0:3080",
      "tunnel_listen_addr": "0.0.0.0:3080",
      "web_listen_addr": "0.0.0.0:3080"
    },
    "db": {
      "postgres_listen_addr": "0.0.0.0:3080",
      "mysql_listen_addr": "0.0.0.0:3080"
    },
    "tls_routing_enabled": true
  },
  "server_version": "12.1.5",
  "min_client_version": "11.0.0",
  "cluster_name": "localhost",
  "automatic_upgrades": false
}

--insecure 플래그를 사용하여 Teleport의 자체 서명 인증서를 신뢰합니다. 프로덕션에서는 Let's Encrypt 등 신뢰할 수 있는 CA에서 Proxy Service에 TLS 자격 증명을 프로비저닝하는 것이 좋습니다.

Docker에서 Teleport 업그레이드#

Docker에서 실행 중인 Teleport 컨테이너를 업그레이드하려면:

  1. 컨테이너의 데이터 디렉터리를 그대로 둡니다.
  2. 컨테이너를 중지합니다.
  3. 초기에 컨테이너를 실행할 때처럼 데이터 디렉터리를 마운트하여 최신 Teleport 버전 기반의 이미지로 새 컨테이너를 실행합니다. 데이터 디렉터리에 업그레이드 전과 동일한 내용이 있는 한 Teleport 컨테이너는 클러스터에 다시 조인할 필요가 없습니다.