InfoGrab DocsInfoGrab Docs

Kubernetes 접근과 머신 및 워크로드 아이덴티티

요약

Teleport는 Kubernetes 클러스터에 대한 접근을 보호하고 제어합니다. 이 가이드에서는 Teleport 클러스터에 등록된 Kubernetes 클러스터에 접근하는 데 사용할 수 있는 자격 증명을 생성하도록 tbot을 설정합니다.

Teleport는 Kubernetes 클러스터에 대한 접근을 보호하고 제어합니다. 머신 및 워크로드 아이덴티티를 사용하여 머신에 이러한 클러스터에 대한 안전하고 단기적인 접근을 허용할 수 있습니다.

이 가이드에서는 Teleport 클러스터에 등록된 Kubernetes 클러스터에 접근하는 데 사용할 수 있는 자격 증명을 생성하도록 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 명령을 실행할 수도 있습니다.

  • Kubernetes 클러스터를 구성하려면 클라이언트 시스템에 kubectl이 설치되어 있어야 합니다. 설치 방법은 Kubernetes 문서를 참고하세요.
  • Kubernetes 클러스터에 접근할 머신에는 tbot이 이미 설치 및 구성되어 있어야 합니다. 자세한 내용은 배포 가이드를 참고하세요.
  • Kubernetes 클러스터에 연결하는 과정을 시연하려면 Kubernetes 클러스터에 접근할 머신에 kubectl이 설치되어 있어야 합니다. 설치 방법은 Kubernetes 문서를 참고하세요.

1/3단계. Teleport와 Kubernetes RBAC 구성#

먼저, 봇에게 올바른 수준의 접근 권한을 부여하기 위해 Teleport와 Kubernetes 양쪽의 RBAC를 구성해야 합니다.

봇을 대신하여 Kubernetes API로 요청을 전달할 때, Teleport 프록시는 봇의 Teleport 역할에서 (kubernetes_groups를 사용하여) 구성된 그룹을 요청에 첨부합니다. 이러한 그룹은 이후 Kubernetes에서 RoleBinding 또는 ClusterRoleBinding을 구성하여 Kubernetes 클러스터 내에서 봇에게 특정 권한을 부여하는 데 사용됩니다.

이 가이드에서는 봇에게 모든 클러스터 네임스페이스의 리소스에 대한 읽기/쓰기 접근 권한을 부여하기 위해, 대부분의 Kubernetes 클러스터에 미리 구성되어 있는 기본 edit ClusterRole에 editor 그룹을 바인딩하겠습니다.

프로덕션 환경에 맞게 구성할 때는 다음을 고려해야 합니다:

  • 봇의 접근을 특정 네임스페이스로 제한하려면 ClusterRoleBinding 대신 RoleBinding을 사용해야 하는지 여부.
  • edit과 같은 기존의 범용 Role을 사용하는 대신, 봇에게 필요한 최소 권한만 부여하는 Role을 새로 만들어야 하는지 여부.

editor 그룹을 edit Cluster Role에 바인딩하려면 다음을 실행하세요:

$ kubectl create clusterrolebinding teleport-editor-edit \
  --clusterrole=edit \
  --group=editor

특정 그룹에 접근 권한을 부여하도록 Kubernetes에서 적절한 RoleBinding을 구성했다면, 이제 자격 증명을 생성할 때 봇이 가장할(impersonate) 역할에 이 그룹을 추가해야 합니다. 또한 Teleport를 통해 클러스터 자체에 대한 접근 권한을 봇에게 부여해야 합니다. 이는 필요한 권한을 부여하는 역할을 생성한 다음 이 역할을 Bot에 할당하여 수행합니다.

다음 내용으로 role.yaml 파일을 생성하세요:

kind: role
version: v7
metadata:
  name: example-role
spec:
  allow:
    kubernetes_labels:
      '*': '*'
    kubernetes_groups:
    - editor
    kubernetes_resources:
    - kind: "*"
      namespace: "*"
      name: "*"
      verbs: ["*"]

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

환경에 맞게 allow 필드를 조정하세요:

  • kubernetes_labels는 봇이 접근해야 하는 클러스터로만 접근을 제한하도록 조정해야 합니다. 표시된 값 '*': '*'은 모든 Kubernetes 클러스터에 대한 접근을 허용합니다.
  • editor는 RoleBinding 또는 ClusterRoleBinding에서 지정한 그룹의 이름과 일치해야 합니다.
  • kubernetes_resources는 봇이 Kubernetes 클러스터 내에서 접근할 수 있는 항목에 추가 제약을 적용하는 데 사용할 수 있습니다. 이러한 제약은 Kubernetes 역할 자체 내에 구성된 RBAC 위에 계층으로 적용됩니다.

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

Tip

Web UI를 사용하여 역할을 생성하고 편집할 수도 있습니다. Access -> Roles로 이동하여 Create New Role을 클릭하거나 편집할 기존 역할을 선택하십시오.

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

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

2/3단계. Kubernetes tbot 출력 서비스 구성#

이제 tbot이 Kubernetes 자격 증명과 클라이언트 구성 파일을 생성하도록 출력 서비스로 구성되어야 합니다. 이는 kubernetes/v2 서비스 유형을 사용하여 수행합니다.

사용 가능하게 하려는 Kubernetes 클러스터는 selectors 목록의 항목을 사용하여 지정해야 합니다. 이 예시에서는 이름 셀렉터를 사용하여 example-k8s-cluster가 선택되고, environment=dev 라벨을 가진 모든 클러스터도 함께 선택됩니다.

출력 서비스는 대상(destination)도 함께 구성해야 합니다. 이 예시에서는 directory 유형을 사용합니다. 이는 디스크의 지정된 디렉터리에 아티팩트를 기록합니다. 이 디렉터리는 tbot이 실행되는 Linux 사용자가 쓸 수 있어야 하며, Kubernetes 클러스터에 접근할 Linux 사용자가 읽을 수 있어야 합니다.

tbot 구성을 수정하여 kubernetes/v2 서비스를 추가하세요:

services:
  - type: kubernetes/v2
    selectors:
      # 자격 증명이 접근 권한을 부여할 Kubernetes 클러스터의 이름을 지정하세요.
      # 와일드카드는 지원되지 않습니다.
      - name: example-k8s-cluster

      # 여러 클러스터를 한 번에 동적으로 선택할 라벨 셀렉터를 지정하세요.
      # 클러스터가 선택되려면 셀렉터의 모든 라벨이 일치해야 하며, 필요하다면
      # 여러 개의 별도 셀렉터를 지정할 수 있습니다. 와일드카드는 지원되지 않습니다.
      - labels:
          environment: dev
    destination:
      type: directory
          # 이 가이드에서는 대상 디렉터리로 /opt/machine-id를 사용합니다.
          # 원하는 대로 이를 변경할 수 있습니다. 여러 출력 서비스는 동일한
          # 대상을 공유할 수 없습니다.
      path: /opt/machine-id

Teleport에 등록된 Kubernetes 클러스터의 이름으로 example-k8s-cluster를 반드시 바꾸고, 필요하다면 /opt/machine-id도 조정하세요.

Note

이 섹션의 내용은 원문 문서를 참조하세요. (reload-tbot.mdx)

3/3단계. Kubernetes 클러스터에 연결하기#

새로 구성된 서비스로 tbot이 실행되고 나면, 지정한 대상 디렉터리에 kubeconfig.yaml 파일이 생성되어 있어야 합니다. 이 파일에는 kubectl이 Teleport 프록시를 통해 Kubernetes 클러스터에 연결하는 데 필요한 모든 정보가 포함되어 있습니다.

kubectl에서 kubeconfig.yaml을 사용하려면 kubectl--kubeconfig 플래그 또는 KUBECONFIG 환경 변수를 제공하면 됩니다:

$ kubectl --kubeconfig /opt/machine-id/kubeconfig.yaml get pods -A
# 또는 KUBECONFIG 환경 변수를 설정하세요:
$ export KUBECONFIG=/opt/machine-id/kubeconfig.yaml
$ kubectl get pods -A

여러 클러스터를 선택했다면, 생성된 kubeconfig.yaml 내에서 별도의 컨텍스트로 노출되며, $teleportClusterName-$kubeClusterName 형식을 따라 이름이 지정됩니다. 특정 클러스터를 대상으로 지정하려면 --context 플래그를 사용하세요:

$ kubectl --kubeconfig /opt/machine-id/kubeconfig.yaml --context=example.teleport.sh-my-kube-cluster get pods -A

tbot.yaml에서 처음 선택된 클러스터가 기본 컨텍스트로 사용된다는 점에 유의하세요. 라벨 셀렉터를 사용하는 경우, Teleport에서 클러스터가 추가되거나 제거됨에 따라 기본 컨텍스트가 시간이 지나면서 달라질 수 있습니다.

Teleport에서 일치하는 새 클러스터가 추가되거나 제거되면, 봇의 다음 인증서 갱신 시 kubeconfig.yaml이 변경 사항을 반영하도록 재생성됩니다. 필요한 경우, 즉시 다시 로드하도록 tbot 프로세스를 재시작하거나 시그널(pkill -USR1 tbot)을 보낼 수 있습니다. current-context 필드 변경과 같이 kubeconfig.yaml에 대한 수정 사항은 덮어써진다는 점에 유의하세요.

이 가이드에서는 kubeconfig.yamlkubectl과 함께 사용하는 방법을 설명했지만, 이 형식은 다음을 포함한 대부분의 Kubernetes 도구와 호환됩니다:

  • Helm
  • Lens
  • ArgoCD

다음 단계#

Kubernetes 접근과 머신 및 워크로드 아이덴티티

Teleport v18.9
원문 보기
요약

Teleport는 Kubernetes 클러스터에 대한 접근을 보호하고 제어합니다. 이 가이드에서는 Teleport 클러스터에 등록된 Kubernetes 클러스터에 접근하는 데 사용할 수 있는 자격 증명을 생성하도록 tbot을 설정합니다.

Teleport는 Kubernetes 클러스터에 대한 접근을 보호하고 제어합니다. 머신 및 워크로드 아이덴티티를 사용하여 머신에 이러한 클러스터에 대한 안전하고 단기적인 접근을 허용할 수 있습니다.

이 가이드에서는 Teleport 클러스터에 등록된 Kubernetes 클러스터에 접근하는 데 사용할 수 있는 자격 증명을 생성하도록 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 명령을 실행할 수도 있습니다.

  • Kubernetes 클러스터를 구성하려면 클라이언트 시스템에 kubectl이 설치되어 있어야 합니다. 설치 방법은 Kubernetes 문서를 참고하세요.
  • Kubernetes 클러스터에 접근할 머신에는 tbot이 이미 설치 및 구성되어 있어야 합니다. 자세한 내용은 배포 가이드를 참고하세요.
  • Kubernetes 클러스터에 연결하는 과정을 시연하려면 Kubernetes 클러스터에 접근할 머신에 kubectl이 설치되어 있어야 합니다. 설치 방법은 Kubernetes 문서를 참고하세요.

1/3단계. Teleport와 Kubernetes RBAC 구성#

먼저, 봇에게 올바른 수준의 접근 권한을 부여하기 위해 Teleport와 Kubernetes 양쪽의 RBAC를 구성해야 합니다.

봇을 대신하여 Kubernetes API로 요청을 전달할 때, Teleport 프록시는 봇의 Teleport 역할에서 (kubernetes_groups를 사용하여) 구성된 그룹을 요청에 첨부합니다. 이러한 그룹은 이후 Kubernetes에서 RoleBinding 또는 ClusterRoleBinding을 구성하여 Kubernetes 클러스터 내에서 봇에게 특정 권한을 부여하는 데 사용됩니다.

이 가이드에서는 봇에게 모든 클러스터 네임스페이스의 리소스에 대한 읽기/쓰기 접근 권한을 부여하기 위해, 대부분의 Kubernetes 클러스터에 미리 구성되어 있는 기본 edit ClusterRole에 editor 그룹을 바인딩하겠습니다.

프로덕션 환경에 맞게 구성할 때는 다음을 고려해야 합니다:

  • 봇의 접근을 특정 네임스페이스로 제한하려면 ClusterRoleBinding 대신 RoleBinding을 사용해야 하는지 여부.
  • edit과 같은 기존의 범용 Role을 사용하는 대신, 봇에게 필요한 최소 권한만 부여하는 Role을 새로 만들어야 하는지 여부.

editor 그룹을 edit Cluster Role에 바인딩하려면 다음을 실행하세요:

$ kubectl create clusterrolebinding teleport-editor-edit \
  --clusterrole=edit \
  --group=editor

특정 그룹에 접근 권한을 부여하도록 Kubernetes에서 적절한 RoleBinding을 구성했다면, 이제 자격 증명을 생성할 때 봇이 가장할(impersonate) 역할에 이 그룹을 추가해야 합니다. 또한 Teleport를 통해 클러스터 자체에 대한 접근 권한을 봇에게 부여해야 합니다. 이는 필요한 권한을 부여하는 역할을 생성한 다음 이 역할을 Bot에 할당하여 수행합니다.

다음 내용으로 role.yaml 파일을 생성하세요:

kind: role
version: v7
metadata:
  name: example-role
spec:
  allow:
    kubernetes_labels:
      '*': '*'
    kubernetes_groups:
    - editor
    kubernetes_resources:
    - kind: "*"
      namespace: "*"
      name: "*"
      verbs: ["*"]

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

환경에 맞게 allow 필드를 조정하세요:

  • kubernetes_labels는 봇이 접근해야 하는 클러스터로만 접근을 제한하도록 조정해야 합니다. 표시된 값 '*': '*'은 모든 Kubernetes 클러스터에 대한 접근을 허용합니다.
  • editor는 RoleBinding 또는 ClusterRoleBinding에서 지정한 그룹의 이름과 일치해야 합니다.
  • kubernetes_resources는 봇이 Kubernetes 클러스터 내에서 접근할 수 있는 항목에 추가 제약을 적용하는 데 사용할 수 있습니다. 이러한 제약은 Kubernetes 역할 자체 내에 구성된 RBAC 위에 계층으로 적용됩니다.

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

Tip

Web UI를 사용하여 역할을 생성하고 편집할 수도 있습니다. Access -> Roles로 이동하여 Create New Role을 클릭하거나 편집할 기존 역할을 선택하십시오.

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

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

2/3단계. Kubernetes tbot 출력 서비스 구성#

이제 tbot이 Kubernetes 자격 증명과 클라이언트 구성 파일을 생성하도록 출력 서비스로 구성되어야 합니다. 이는 kubernetes/v2 서비스 유형을 사용하여 수행합니다.

사용 가능하게 하려는 Kubernetes 클러스터는 selectors 목록의 항목을 사용하여 지정해야 합니다. 이 예시에서는 이름 셀렉터를 사용하여 example-k8s-cluster가 선택되고, environment=dev 라벨을 가진 모든 클러스터도 함께 선택됩니다.

출력 서비스는 대상(destination)도 함께 구성해야 합니다. 이 예시에서는 directory 유형을 사용합니다. 이는 디스크의 지정된 디렉터리에 아티팩트를 기록합니다. 이 디렉터리는 tbot이 실행되는 Linux 사용자가 쓸 수 있어야 하며, Kubernetes 클러스터에 접근할 Linux 사용자가 읽을 수 있어야 합니다.

tbot 구성을 수정하여 kubernetes/v2 서비스를 추가하세요:

services:
  - type: kubernetes/v2
    selectors:
      # 자격 증명이 접근 권한을 부여할 Kubernetes 클러스터의 이름을 지정하세요.
      # 와일드카드는 지원되지 않습니다.
      - name: example-k8s-cluster

      # 여러 클러스터를 한 번에 동적으로 선택할 라벨 셀렉터를 지정하세요.
      # 클러스터가 선택되려면 셀렉터의 모든 라벨이 일치해야 하며, 필요하다면
      # 여러 개의 별도 셀렉터를 지정할 수 있습니다. 와일드카드는 지원되지 않습니다.
      - labels:
          environment: dev
    destination:
      type: directory
          # 이 가이드에서는 대상 디렉터리로 /opt/machine-id를 사용합니다.
          # 원하는 대로 이를 변경할 수 있습니다. 여러 출력 서비스는 동일한
          # 대상을 공유할 수 없습니다.
      path: /opt/machine-id

Teleport에 등록된 Kubernetes 클러스터의 이름으로 example-k8s-cluster를 반드시 바꾸고, 필요하다면 /opt/machine-id도 조정하세요.

Note

이 섹션의 내용은 원문 문서를 참조하세요. (reload-tbot.mdx)

3/3단계. Kubernetes 클러스터에 연결하기#

새로 구성된 서비스로 tbot이 실행되고 나면, 지정한 대상 디렉터리에 kubeconfig.yaml 파일이 생성되어 있어야 합니다. 이 파일에는 kubectl이 Teleport 프록시를 통해 Kubernetes 클러스터에 연결하는 데 필요한 모든 정보가 포함되어 있습니다.

kubectl에서 kubeconfig.yaml을 사용하려면 kubectl--kubeconfig 플래그 또는 KUBECONFIG 환경 변수를 제공하면 됩니다:

$ kubectl --kubeconfig /opt/machine-id/kubeconfig.yaml get pods -A
# 또는 KUBECONFIG 환경 변수를 설정하세요:
$ export KUBECONFIG=/opt/machine-id/kubeconfig.yaml
$ kubectl get pods -A

여러 클러스터를 선택했다면, 생성된 kubeconfig.yaml 내에서 별도의 컨텍스트로 노출되며, $teleportClusterName-$kubeClusterName 형식을 따라 이름이 지정됩니다. 특정 클러스터를 대상으로 지정하려면 --context 플래그를 사용하세요:

$ kubectl --kubeconfig /opt/machine-id/kubeconfig.yaml --context=example.teleport.sh-my-kube-cluster get pods -A

tbot.yaml에서 처음 선택된 클러스터가 기본 컨텍스트로 사용된다는 점에 유의하세요. 라벨 셀렉터를 사용하는 경우, Teleport에서 클러스터가 추가되거나 제거됨에 따라 기본 컨텍스트가 시간이 지나면서 달라질 수 있습니다.

Teleport에서 일치하는 새 클러스터가 추가되거나 제거되면, 봇의 다음 인증서 갱신 시 kubeconfig.yaml이 변경 사항을 반영하도록 재생성됩니다. 필요한 경우, 즉시 다시 로드하도록 tbot 프로세스를 재시작하거나 시그널(pkill -USR1 tbot)을 보낼 수 있습니다. current-context 필드 변경과 같이 kubeconfig.yaml에 대한 수정 사항은 덮어써진다는 점에 유의하세요.

이 가이드에서는 kubeconfig.yamlkubectl과 함께 사용하는 방법을 설명했지만, 이 형식은 다음을 포함한 대부분의 Kubernetes 도구와 호환됩니다:

  • Helm
  • Lens
  • ArgoCD

다음 단계#