InfoGrab DocsInfoGrab Docs

Kubernetes에 tbot 배포

요약

이 가이드는 Kubernetes 클러스터에 머신 및 워크로드 아이덴티티 에이전트 tbot을 배포하고, 인증을 위해 클러스터의 서비스 계정 발급자 키에 대한 정적 참조를 사용하는 방법을 보여줍니다. 이 가이드에서 보여주는 설정에서 tbot은 Kubernetes 배포(deployment)로 실행됩니다.

이 가이드는 Kubernetes 클러스터에 머신 및 워크로드 아이덴티티 에이전트 tbot을 배포하고, 인증을 위해 클러스터의 서비스 계정 발급자 키에 대한 정적 참조를 사용하는 방법을 보여줍니다.

작동 방식#

이 가이드에서 보여주는 설정에서 tbot은 Kubernetes 배포(deployment)로 실행됩니다. 출력 자격 증명을 Kubernetes 시크릿에 작성하며, 이후 자격 증명을 사용해야 하는 Pod에 마운트할 수 있습니다. tbot은 자격 증명을 생성하여 사용하는 서비스와 동일한 Pod 내에서 사이드카로 실행할 수도 있지만, Kubernetes가 사이드카에 대한 지원이 제한적이므로 tbot을 독립적인 배포로 실행하는 것을 권장합니다.

이 가이드에서는 kubernetes 조인 방법을 보여줍니다. 이 방법에서는 tbot이 Kubernetes API 서버가 서명한 JSON 웹 토큰(JWT)을 제시하여 Teleport Auth Service에 아이덴티티를 증명합니다. 이 JWT에는 tbot이 실행 중인 서비스 계정, Pod, 네임스페이스가 포함됩니다. Teleport Auth Service는 Kubernetes 클러스터의 공개 서명 키에 대해 JWT의 서명을 확인합니다.

OIDC 조인

Amazon EKS와 같은 일부 클라우드 제공업체는 OIDC 서명 키를 정기적으로 교체하므로, 이 가이드에서 생성하는 static_jwks 설정은 짧은 시간이 지나면 유효하지 않게 됩니다.

Amazon Elastic Kubernetes Service(EKS), Google Kubernetes Engine(GKE), Azure Kubernetes Service(AKS)와 같이 OIDC를 지원하는 Kubernetes 제공업체에서는 대신 Kubernetes OIDC 조인을 사용하는 것을 고려하세요.

다른 조인 방법 사용하기

Teleport 클러스터에 tbot을 배포할 때는 일반적으로 kubernetes 조인 방법을 사용하는 것이 권장됩니다. 이 방법은 대부분의 Kubernetes 클러스터에서 작동합니다. 이어지는 가이드에서는 이 조인 방법을 설정하는 방법을 보여줍니다.

그러나 일부 클라우드 Kubernetes 서비스를 사용하는 경우, kubernetes 조인 방법 대신 해당 플랫폼과 연관된 조인 방법을 사용할 수 있습니다. 이는 동일한 플랫폼의 Kubernetes 클러스터와 표준 VM에서 하나의 조인 토큰으로 tbot의 조인을 관리하고자 하는 경우 유용할 수 있습니다. 해당 서비스는 다음과 같습니다.

사전 요구사항#

  • 실행 중인 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` 파일을 더블 클릭하여 설치를 시작합니다.
 
     
Warning
       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 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 명령을 실행할 수도 있습니다.

  • 토큰 요청 프로젝션(Token Request Projection)을 지원하는 Kubernetes 클러스터(Kubernetes 1.20에서 일반 사용 가능(GA) 기능으로 승격됨).
  • tbot을 배포하려는 클러스터에서 리소스를 생성할 수 있는 권한으로 인증된 kubectl.
  • helm CLI 도구가 설치되어 있어야 합니다.

이 가이드의 예시는 Kubernetes 클러스터의 default 네임스페이스에 tbot 배포를 설치합니다. 사용하려는 네임스페이스에 맞게 default에 대한 참조를 조정하세요.

1/3단계. 봇 생성#

다음으로 Bot을 생성해야 합니다. Bot은 머신 또는 머신 그룹을 위한 Teleport identity입니다. 사용자와 마찬가지로 bot에는 무엇에 액세스할 수 있는지 정의하는 role 및 trait 집합이 있습니다.

bot.yaml을 생성합니다:

kind: bot
version: v1
metadata:
  # name is a unique identifier for the Bot in the cluster.
  name: example
spec:
  # roles is a list of roles to grant to the Bot. Don't worry if you don't know
  # what roles you need to specify here, the Access Guides will walk you through
  # creating and assigning roles to the already created Bot.
  roles: []

example을 Bot에 대한 고유하고 설명적인 이름으로 반드시 교체하십시오.

tctl을 사용하여 이 파일을 적용합니다:

$ tctl create bot.yaml

2/3단계. 조인 토큰 생성#

다음으로 조인 토큰을 설정해야 합니다. 이는 tbot이 클러스터에 조인하는 데 사용됩니다. kubernetes 조인 방법이 사용되므로, 먼저 Kubernetes 클러스터의 공개 키를 확인해야 합니다. JWT에 서명하는 데 사용되는 공개 키는 Kubernetes API 서버의 "JWKS" 엔드포인트에 노출됩니다. 이 공개 키는 이후 Teleport Auth Service가 tbot이 제시하는 서비스 계정 JWT가 Kubernetes 클러스터에 의해 정당하게 서명되었는지 확인하는 데 사용할 수 있습니다.

다음 명령을 실행하여 JWKS 형식의 공개 키를 확인하세요.

$ kubectl get --raw /openid/v1/jwks
{"keys":[--snip--]}%

bot-token.yaml을 생성하고, JWKS 엔드포인트에서 얻은 값을 spec.kubernetes.static_jwks.jwks에 삽입해야 합니다.

kind: token
version: v2
metadata:
  # name will be specified in the `tbot` to use this token
  name: example-bot
spec:
  roles: [Bot]
  # bot_name should match the name of the bot created earlier in this guide.
  bot_name: example
  join_method: kubernetes
  kubernetes:
    # static_jwks configures the Auth Service to validate the JWT presented by
    # `tbot` using the public key from a statically configured JWKS.
    type: static_jwks
    static_jwks:
      jwks: |
        # Place the data returned by the curl command here
        {"keys":[--snip--]}
    # allow specifies the rules by which the Auth Service determines if `tbot`
    # should be allowed to join.
    allow:
    - service_account: "default:tbot" # service_account

tctl을 사용하여 이 파일을 적용하세요.

$ tctl create -f bot-token.yaml

3/3단계. tbot 배포 생성#

이제 Teleport tbot Helm 차트를 사용하여 Kubernetes 클러스터에 tbot을 배포합니다. 이는 Helm CLI 도구에 제공하는 값을 사용하여 설정됩니다.

먼저, Helm 차트의 설정 값을 담을 tbot-values.yaml 파일을 생성하세요.

# Replace the cluster name with the name of your Teleport cluster.
# This is not necessarily the public address of your Teleport Proxy Service.
clusterName: "example.teleport.sh"
# Replace this with the address of your Teleport Proxy Service.
teleportProxyAddress: "example.teleport.sh:443"
# Ensure this matches the name of the join token you created earlier.
token: "example-bot"
FIPS 준수

기본 tbot-distroless 이미지에는 FIPS 준수 바이너리가 포함되어 있지 않습니다. FIPS 준수가 필요한 환경에서 운영하는 경우, 추가로 image: public.ecr.aws/gravitational/tbot-fips-distroless를 설정하세요.

Helm 차트를 배포하기 전에, 이전에 Teleport Helm 차트를 배포한 적이 없다면 CLI에 Teleport 차트 리포지터리를 추가해야 합니다.

$ helm repo add teleport (=teleport.helm_repo_url=)
$ helm repo update

이제 앞서 생성한 설정을 사용하여 tbot Helm 차트를 배포할 수 있습니다. 이때 tbot을 배포하려는 네임스페이스를 지정해야 합니다.

$ helm install tbot teleport/tbot \
  --namespace default \
  --values tbot-values.yaml

kubectl을 사용하여 배포가 정상 상태인지 확인하세요.

$ kubectl describe deployment/tbot
$ kubectl logs deployment/tbot

이 작업이 완료되면 tbot이 클러스터에 성공적으로 배포된 것입니다.

다음 단계: 인프라 접근 설정#

기본적으로 tbot Helm 차트는 tbot이 배포된 네임스페이스에 tbot-out이라는 Kubernetes 시크릿에 아이덴티티 파일을 작성하도록 설정되어 있습니다.

이 아이덴티티 파일은 다른 Pod에 마운트하여 tsh 또는 tctl과 함께 사용해 Teleport 클러스터에 접근하고 설정하는 데 사용할 수 있습니다. 예를 들면 다음과 같습니다.

apiVersion: v1
kind: Pod
metadata:
  name: tsh
  namespace: default
spec:
  containers:
    - name: tsh
      image: public.ecr.aws/gravitational/teleport-distroless:(=teleport.version=)
      command:
        - tsh
      args:
       - -i
       - /identity-output/identity
       - --proxy
       - example.teleport.sh:443
       - ls
      volumeMounts:
        - name: identity-output
          mountPath: /identity-output
  volumes:
    - name: identity-output
      secret:
        secretName: tbot-out

다른 종류의 접근을 위해 tbot을 사용하고 싶다면, Helm 차트의 services 값을 사용해 출력 유형을 재정의하고 defaultOutput.enabledfalse로 설정하면 됩니다.

사용 사례에 맞게 tbot을 설정하는 방법에 대해 자세히 알아보려면 접근 가이드 중 하나를 참조하세요.

추가 자료#

Kubernetes에 tbot 배포

Teleport v18.9
원문 보기
요약

이 가이드는 Kubernetes 클러스터에 머신 및 워크로드 아이덴티티 에이전트 tbot을 배포하고, 인증을 위해 클러스터의 서비스 계정 발급자 키에 대한 정적 참조를 사용하는 방법을 보여줍니다. 이 가이드에서 보여주는 설정에서 tbot은 Kubernetes 배포(deployment)로 실행됩니다.

이 가이드는 Kubernetes 클러스터에 머신 및 워크로드 아이덴티티 에이전트 tbot을 배포하고, 인증을 위해 클러스터의 서비스 계정 발급자 키에 대한 정적 참조를 사용하는 방법을 보여줍니다.

작동 방식#

이 가이드에서 보여주는 설정에서 tbot은 Kubernetes 배포(deployment)로 실행됩니다. 출력 자격 증명을 Kubernetes 시크릿에 작성하며, 이후 자격 증명을 사용해야 하는 Pod에 마운트할 수 있습니다. tbot은 자격 증명을 생성하여 사용하는 서비스와 동일한 Pod 내에서 사이드카로 실행할 수도 있지만, Kubernetes가 사이드카에 대한 지원이 제한적이므로 tbot을 독립적인 배포로 실행하는 것을 권장합니다.

이 가이드에서는 kubernetes 조인 방법을 보여줍니다. 이 방법에서는 tbot이 Kubernetes API 서버가 서명한 JSON 웹 토큰(JWT)을 제시하여 Teleport Auth Service에 아이덴티티를 증명합니다. 이 JWT에는 tbot이 실행 중인 서비스 계정, Pod, 네임스페이스가 포함됩니다. Teleport Auth Service는 Kubernetes 클러스터의 공개 서명 키에 대해 JWT의 서명을 확인합니다.

OIDC 조인

Amazon EKS와 같은 일부 클라우드 제공업체는 OIDC 서명 키를 정기적으로 교체하므로, 이 가이드에서 생성하는 static_jwks 설정은 짧은 시간이 지나면 유효하지 않게 됩니다.

Amazon Elastic Kubernetes Service(EKS), Google Kubernetes Engine(GKE), Azure Kubernetes Service(AKS)와 같이 OIDC를 지원하는 Kubernetes 제공업체에서는 대신 Kubernetes OIDC 조인을 사용하는 것을 고려하세요.

다른 조인 방법 사용하기

Teleport 클러스터에 tbot을 배포할 때는 일반적으로 kubernetes 조인 방법을 사용하는 것이 권장됩니다. 이 방법은 대부분의 Kubernetes 클러스터에서 작동합니다. 이어지는 가이드에서는 이 조인 방법을 설정하는 방법을 보여줍니다.

그러나 일부 클라우드 Kubernetes 서비스를 사용하는 경우, kubernetes 조인 방법 대신 해당 플랫폼과 연관된 조인 방법을 사용할 수 있습니다. 이는 동일한 플랫폼의 Kubernetes 클러스터와 표준 VM에서 하나의 조인 토큰으로 tbot의 조인을 관리하고자 하는 경우 유용할 수 있습니다. 해당 서비스는 다음과 같습니다.

사전 요구사항#

  • 실행 중인 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` 파일을 더블 클릭하여 설치를 시작합니다.
 
     
Warning
       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 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 명령을 실행할 수도 있습니다.

  • 토큰 요청 프로젝션(Token Request Projection)을 지원하는 Kubernetes 클러스터(Kubernetes 1.20에서 일반 사용 가능(GA) 기능으로 승격됨).
  • tbot을 배포하려는 클러스터에서 리소스를 생성할 수 있는 권한으로 인증된 kubectl.
  • helm CLI 도구가 설치되어 있어야 합니다.

이 가이드의 예시는 Kubernetes 클러스터의 default 네임스페이스에 tbot 배포를 설치합니다. 사용하려는 네임스페이스에 맞게 default에 대한 참조를 조정하세요.

1/3단계. 봇 생성#

다음으로 Bot을 생성해야 합니다. Bot은 머신 또는 머신 그룹을 위한 Teleport identity입니다. 사용자와 마찬가지로 bot에는 무엇에 액세스할 수 있는지 정의하는 role 및 trait 집합이 있습니다.

bot.yaml을 생성합니다:

kind: bot
version: v1
metadata:
  # name is a unique identifier for the Bot in the cluster.
  name: example
spec:
  # roles is a list of roles to grant to the Bot. Don't worry if you don't know
  # what roles you need to specify here, the Access Guides will walk you through
  # creating and assigning roles to the already created Bot.
  roles: []

example을 Bot에 대한 고유하고 설명적인 이름으로 반드시 교체하십시오.

tctl을 사용하여 이 파일을 적용합니다:

$ tctl create bot.yaml

2/3단계. 조인 토큰 생성#

다음으로 조인 토큰을 설정해야 합니다. 이는 tbot이 클러스터에 조인하는 데 사용됩니다. kubernetes 조인 방법이 사용되므로, 먼저 Kubernetes 클러스터의 공개 키를 확인해야 합니다. JWT에 서명하는 데 사용되는 공개 키는 Kubernetes API 서버의 "JWKS" 엔드포인트에 노출됩니다. 이 공개 키는 이후 Teleport Auth Service가 tbot이 제시하는 서비스 계정 JWT가 Kubernetes 클러스터에 의해 정당하게 서명되었는지 확인하는 데 사용할 수 있습니다.

다음 명령을 실행하여 JWKS 형식의 공개 키를 확인하세요.

$ kubectl get --raw /openid/v1/jwks
{"keys":[--snip--]}%

bot-token.yaml을 생성하고, JWKS 엔드포인트에서 얻은 값을 spec.kubernetes.static_jwks.jwks에 삽입해야 합니다.

kind: token
version: v2
metadata:
  # name will be specified in the `tbot` to use this token
  name: example-bot
spec:
  roles: [Bot]
  # bot_name should match the name of the bot created earlier in this guide.
  bot_name: example
  join_method: kubernetes
  kubernetes:
    # static_jwks configures the Auth Service to validate the JWT presented by
    # `tbot` using the public key from a statically configured JWKS.
    type: static_jwks
    static_jwks:
      jwks: |
        # Place the data returned by the curl command here
        {"keys":[--snip--]}
    # allow specifies the rules by which the Auth Service determines if `tbot`
    # should be allowed to join.
    allow:
    - service_account: "default:tbot" # service_account

tctl을 사용하여 이 파일을 적용하세요.

$ tctl create -f bot-token.yaml

3/3단계. tbot 배포 생성#

이제 Teleport tbot Helm 차트를 사용하여 Kubernetes 클러스터에 tbot을 배포합니다. 이는 Helm CLI 도구에 제공하는 값을 사용하여 설정됩니다.

먼저, Helm 차트의 설정 값을 담을 tbot-values.yaml 파일을 생성하세요.

# Replace the cluster name with the name of your Teleport cluster.
# This is not necessarily the public address of your Teleport Proxy Service.
clusterName: "example.teleport.sh"
# Replace this with the address of your Teleport Proxy Service.
teleportProxyAddress: "example.teleport.sh:443"
# Ensure this matches the name of the join token you created earlier.
token: "example-bot"
FIPS 준수

기본 tbot-distroless 이미지에는 FIPS 준수 바이너리가 포함되어 있지 않습니다. FIPS 준수가 필요한 환경에서 운영하는 경우, 추가로 image: public.ecr.aws/gravitational/tbot-fips-distroless를 설정하세요.

Helm 차트를 배포하기 전에, 이전에 Teleport Helm 차트를 배포한 적이 없다면 CLI에 Teleport 차트 리포지터리를 추가해야 합니다.

$ helm repo add teleport (=teleport.helm_repo_url=)
$ helm repo update

이제 앞서 생성한 설정을 사용하여 tbot Helm 차트를 배포할 수 있습니다. 이때 tbot을 배포하려는 네임스페이스를 지정해야 합니다.

$ helm install tbot teleport/tbot \
  --namespace default \
  --values tbot-values.yaml

kubectl을 사용하여 배포가 정상 상태인지 확인하세요.

$ kubectl describe deployment/tbot
$ kubectl logs deployment/tbot

이 작업이 완료되면 tbot이 클러스터에 성공적으로 배포된 것입니다.

다음 단계: 인프라 접근 설정#

기본적으로 tbot Helm 차트는 tbot이 배포된 네임스페이스에 tbot-out이라는 Kubernetes 시크릿에 아이덴티티 파일을 작성하도록 설정되어 있습니다.

이 아이덴티티 파일은 다른 Pod에 마운트하여 tsh 또는 tctl과 함께 사용해 Teleport 클러스터에 접근하고 설정하는 데 사용할 수 있습니다. 예를 들면 다음과 같습니다.

apiVersion: v1
kind: Pod
metadata:
  name: tsh
  namespace: default
spec:
  containers:
    - name: tsh
      image: public.ecr.aws/gravitational/teleport-distroless:(=teleport.version=)
      command:
        - tsh
      args:
       - -i
       - /identity-output/identity
       - --proxy
       - example.teleport.sh:443
       - ls
      volumeMounts:
        - name: identity-output
          mountPath: /identity-output
  volumes:
    - name: identity-output
      secret:
        secretName: tbot-out

다른 종류의 접근을 위해 tbot을 사용하고 싶다면, Helm 차트의 services 값을 사용해 출력 유형을 재정의하고 defaultOutput.enabledfalse로 설정하면 됩니다.

사용 사례에 맞게 tbot을 설정하는 방법에 대해 자세히 알아보려면 접근 가이드 중 하나를 참조하세요.

추가 자료#