Teleport Discovery Service는 Google Kubernetes Engine (GKE) 클러스터를 Teleport에 자동으로 등록할 수 있습니다. Teleport Kubernetes Discovery를 사용하면 Teleport Kubernetes Service와 Discovery Service를 한 번 설정한 후, GKE 클러스터를 생성할 때마다 Teleport에 등록할 필요 없이 클러스터를 생성할 수 있습니다.

이 가이드에서는 GKE에 대한 Teleport Kubernetes Discovery를 시작하는 방법을 보여드립니다.

개요

Teleport cluster 자동 발견은 두 가지 구성 요소로 이루어집니다:

1. 새로운 cluster나 이전에 발견된 cluster의 변경 사항을 감시하는 Teleport Discovery Service입니다. 발견된 각 cluster는 Teleport 클러스터에서 kube_cluster 리소스로 동적으로 등록됩니다. 발견하는 cluster에 대한 연결이 필요하지 않습니다.

2. Discovery Service에 의해 등록된 동적 kube_cluster 리소스를 모니터링하는 Teleport Kubernetes Service입니다. 이는 사용자와 cluster 간의 통신을 프록시합니다.

전제 조건

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

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

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

• GKE 클러스터, IAM 역할 및 서비스 계정을 생성할 권한이 있는 Google Cloud 계정.
• gcloud CLI 도구. Google Cloud 문서 페이지를 참조하여 gcloud를 설치하고 인증합니다.
• 하나 이상의 GKE 클러스터가 실행 중입니다. Kubernetes 사용자는 클러스터에서 ClusterRole 및 ClusterRoleBinding 리소스를 생성할 수 있는 권한이 있어야 합니다.
• Teleport Discovery 및 Kubernetes Services를 실행할 Linux 호스트. 이 호스트는 어떤 클라우드 제공업체에서나 또는 로컬 머신에서 실행할 수 있습니다.
• 당신의 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 명령어를 실행할 수도 있습니다.

1단계/3단계. Google Cloud 자격 증명 얻기

Teleport Discovery Service와 Kubernetes Service는 GKE 클러스터를 검색하고 Teleport 사용자로부터의 액세스를 관리하기 위해 Google Cloud 서비스 계정을 사용합니다. 이 단계에서는 서비스 계정을 생성하고 Teleport Discovery Service에 대한 자격 증명 파일을 다운로드합니다.

Discovery Service용 IAM 역할 만들기

Teleport Discovery Service는 Google Cloud 프로젝트와 연결된 GKE 클러스터를 검색할 수 있는 권한이 필요합니다.

이러한 권한을 부여하기 위해 다음 내용을 포함하는 GKEKubernetesAutoDisc.yaml이라는 파일을 생성합니다:

title: GKE 클러스터 검색기
description: "GKE 클러스터 가져오기 및 나열"
stage: GA
includedPermissions:
- container.clusters.get
- container.clusters.list

역할을 생성하고, --project 플래그를 Google Cloud 프로젝트 이름에 할당합니다:

gcloud iam roles create GKEKubernetesAutoDisc \  --project=google-cloud-project \  --file=GKEKubernetesAutoDisc.yaml

Kubernetes Service용 IAM 역할 만들기

Teleport Kubernetes Service는 사용자 트래픽을 GKE 클러스터로 전달하기 위해 Google Cloud IAM 권한이 필요합니다.

다음 내용을 포함한 GKEAccessManager.yaml이라는 파일을 생성합니다:

title: GKE 클러스터 액세스 관리자
description: "GKE 클러스터에 대한 액세스 관리"
stage: GA
includedPermissions:
- container.clusters.get
- container.clusters.impersonate
- container.pods.get
- container.selfSubjectAccessReviews.create
- container.selfSubjectRulesReviews.create

역할을 생성하고, --project 플래그를 Google Cloud 프로젝트 이름에 할당합니다. 특정 권한이 TESTING에 있다는 메시지가 표시되면 y를 입력합니다:

gcloud iam roles create GKEAccessManager \  --project=google-cloud-project \  --file=GKEAccessManager.yaml

서비스 계정 만들기

이제 Discovery Service와 Kubernetes Service의 역할을 선언했으므로, 이 역할을 할당할 서비스 계정을 생성합니다.

다음 명령을 실행하여 teleport-discovery-kubernetes라는 서비스 계정을 만듭니다:

gcloud iam service-accounts create teleport-discovery-kubernetes \  --description="Teleport Discovery Service 및 Kubernetes Service" \  --display-name="teleport-discovery-kubernetes"

이전에 정의한 역할을 서비스 계정에 부여하고, PROJECT_ID를 Google Cloud 프로젝트 이름에 할당합니다:

PROJECT_ID=google-cloud-project
gcloud projects add-iam-policy-binding ${PROJECT_ID?} \   --member="serviceAccount:teleport-discovery-kubernetes@${PROJECT_ID?}.iam.gserviceaccount.com" \   --role="projects/${PROJECT_ID?}/roles/GKEKubernetesAutoDisc"
gcloud projects add-iam-policy-binding ${PROJECT_ID?} \   --member="serviceAccount:teleport-discovery-kubernetes@${PROJECT_ID?}.iam.gserviceaccount.com" \   --role="projects/${PROJECT_ID?}/roles/GKEAccessManager"

gcloud iam service-accounts create teleport-discovery-service \  --description="Teleport Discovery Service" \  --display-name="teleport-discovery-service"
gcloud iam service-accounts create teleport-kubernetes-service \  --description="Teleport Kubernetes Service" \  --display-name="teleport-kubernetes-service"

PROJECT_ID=google-cloud-project
gcloud projects add-iam-policy-binding ${PROJECT_ID?} \   --member="serviceAccount:teleport-discovery-service@${PROJECT_ID?}.iam.gserviceaccount.com" \   --role="projects/${PROJECT_ID?}/roles/GKEKubernetesAutoDisc"
gcloud projects add-iam-policy-binding ${PROJECT_ID?} \   --member="serviceAccount:teleport-kubernetes-service@${PROJECT_ID?}.iam.gserviceaccount.com" \   --role="projects/${PROJECT_ID?}/roles/GKEAccessManager"

Teleport 서비스에 대한 자격 증명 검색

이제 Google Cloud 서비스 계정을 만들고 역할을 부여했으므로, Teleport Kubernetes Service와 Discovery Service와 서비스 계정을 연결합니다.

프로세스는 Teleport Kubernetes Service와 Discovery Service를 Google Cloud에서 배포하는지 그 외의 방법(예: Amazon EC2 또는 로컬 네트워크에서)인지에 따라 다릅니다.

gcloud compute instances stop vm-name --zone=google-cloud-region

gcloud compute instances set-service-account vm-name \   --service-account teleport-discovery-kubernetes@${PROJECT_ID?}.iam.gserviceaccount.com \   --zone google-cloud-region \   --scopes=cloud-platform

gcloud compute instances set-service-account ${VM1_NAME?} \   --service-account teleport-kubernetes-service@${PROJECT_ID?}.iam.gserviceaccount.com \   --zone google-cloud-region \   --scopes=cloud-platform

gcloud compute instances set-service-account ${VM2_NAME?} \   --service-account teleport-discovery-service@${PROJECT_ID?}.iam.gserviceaccount.com \   --zone google-cloud-region \   --scopes=cloud-platform

gcloud compute instances start vm-name --zone google-cloud-region

PROJECT_ID=google-cloud-project
gcloud iam service-accounts keys create google-cloud-credentials.json \    --iam-account=teleport-discovery-kubernetes@${PROJECT_ID?}.iam.gserviceaccount.com

PROJECT_ID=google-cloud-project
gcloud iam service-accounts keys create discovery-service-credentials.json \    --iam-account=teleport-discovery-service@${PROJECT_ID?}.iam.gserviceaccount.com
gcloud iam service-accounts keys create kube-service-credentials.json \    --iam-account=teleport-kubernetes-service@${PROJECT_ID?}.iam.gserviceaccount.com

2단계/3단계. GKE 클러스터 검색을 위해 Teleport 구성

GKE 클러스터를 검색할 수 있는 서비스 계정과 액세스를 관리할 수 있는 클러스터 역할을 생성했으므로, Teleport Discovery Service를 구성하여 GKE 클러스터를 감지하고 Kubernetes Service가 사용자 트래픽을 프록시하도록 설정합니다.

Teleport 설치

Kubernetes Service와 Discovery Service를 실행할 호스트에 Teleport를 설치합니다:

Linux 서버에 Teleport 설치하기:

1. Teleport 에디션에 따라 edition을(를) 다음 중 하나로 지정합니다:

   에디션	값
   Teleport Enterprise Cloud	cloud
   Teleport Enterprise (자체 호스팅)	enterprise
   Teleport Community Edition	oss

2. 설치할 Teleport의 버전을 확인합니다. 클러스터에서 자동 에이전트 업데이트가 활성화되어 있는 경우, 업데이터와 호환되는 최신 Teleport 버전을 쿼리합니다:

   TELEPORT_DOMAIN=example.teleport.com
   TELEPORT_VERSION="$(curl https://$TELEPORT_DOMAIN/v1/webapi/automaticupgrades/channel/default/version | sed 's/v//')"

   그렇지 않으면, Teleport 클러스터의 버전을 확인합니다:

   TELEPORT_DOMAIN=example.teleport.com
   TELEPORT_VERSION="$(curl https://$TELEPORT_DOMAIN/v1/webapi/ping | jq -r '.server_version')"

3. Linux 서버에 Teleport를 설치합니다:

   curl https://cdn.teleport.dev/install-v16.2.0.sh | bash -s ${TELEPORT_VERSION} edition

   설치 스크립트는 Linux 서버에서 패키지 관리자를 감지하고 이를 사용하여 Teleport 바이너리를 설치합니다. 설치를 사용자 지정하려면 설치 가이드에서 Teleport 패키지 리포지토리에 대해 알아보세요.

가입 토큰 생성

Teleport Discovery Service와 Kubernetes Service는 클러스터에 가입하기 위한 인증 토큰이 필요합니다. 다음 tctl 명령을 실행하여 하나 생성합니다:

tctl tokens add --type=discovery,kube --format=text
abcd123-insecure-do-not-use-this

토큰을 복사하고 (예: 위의 abcd123-insecure-do-not-use-this) Discovery Service와 Kubernetes Service를 실행할 장치의 /tmp/token에 토큰을 저장합니다:

echo abcd123-insecure-do-not-use-this | sudo tee /tmp/token
abcd123-insecure-do-not-use-this

tctl tokens add --type=discovery --format=text
efgh456-insecure-do-not-use-this
tctl tokens add --type=kube --format=text
ijkl789-insecure-do-not-use-this

Kubernetes Service와 Discovery Service 구성

Kubernetes Service와 Discovery Service를 실행 중인 호스트에서 /etc/teleport.yaml에 다음 내용을 포함한 Teleport 구성 파일을 생성합니다:

version: v3
teleport:
  join_params:
    token_name: "/tmp/token"
    method: token
  proxy_server: "teleport.example.com:443"
auth_service:
  enabled: off
proxy_service:
  enabled: off
ssh_service:
  enabled: off
discovery_service:
  enabled: "yes"
  discovery_group: "gke-myproject"
  gcp:
    - types: ["gke"]
      locations: ["*"]
      project_ids: ["myproject"] # 내 프로젝트 ID로 바꾸세요
      tags:
        "*" : "*"
kubernetes_service:
  enabled: "yes"
  resources:
  - labels:
      "*": "*"

version: v3
teleport:
  join_params:
    token_name: "/tmp/token"
    method: token
  proxy_server: teleport.example.com:443    
auth_service:
  enabled: off
proxy_service:
  enabled: off
ssh_service:
  enabled: off
kubernetes_service:
  enabled: "yes"
  resources:
  - labels:
      "*": "*"

version: v3
teleport:
  join_params:
    token_name: "/tmp/token"
    method: token
  proxy_server: teleport.example.com:443    
auth_service:
  enabled: off
proxy_service:
  enabled: off
ssh_service:
  enabled: off
discovery_service:
  enabled: "yes"
  gcp:
    - types: ["gke"]
      locations: ["*"]
      project_ids: ["myproject"] # 내 프로젝트 ID로 바꾸세요
      tags:
        "*" : "*"

이 구성 파일을 귀하의 환경에 맞게 아래와 같이 편집하십시오.

proxy_server

teleport.example.com:443을 Teleport Proxy Service의 호스트와 포트로 교체합니다(예: Teleport Cloud 테넌트의 경우 mytenant.teleport.sh:443).

discovery_service.gcp

discovery_service.gcp의 각 항목은 GKE에서 실행 중인 Kubernetes 클러스터에 대한 매처입니다. Discovery Service는 구성된 모든 매처에 대해 GKE 클러스터를 나열하기 위해 Google Cloud API에 대한 요청을 주기적으로 실행합니다. 이 경우, 우리는 단일 매처를 선언했습니다.

각 매처는 매처의 모든 속성을 충족하는 클러스터를 검색합니다. 즉, 지정된 위치와 프로젝트에 속하고 지정된 태그를 가진 클러스터를 검색합니다. Discovery Service는 구성된 매처 중 하나라도 매칭되는 GKE 클러스터를 등록합니다.

예를 들어 다음 두 매처를 선언하면 Discovery Service는 us-east1에서 실행 중인 myproj-dev의 클러스터와 us-east2에서 실행 중인 myproj-prod의 클러스터를 등록하지만, myproj-dev의 us-east2에서는 클러스터를 등록하지 않습니다:

discovery_service:
  enabled: "yes"
  gcp:
    - types: ["gke"]
      locations: ["us-east1"]
      project_ids: ["myproj-dev"]
      tags:
        "*" : "*"
    - types: ["gke"]
      locations: ["us-east2"]
      project_ids: ["myproj-prod"]
      tags:
        "*" : "*"

discovery_service.gcp[0].types

각 매처의 types 필드는 단일 문자열 값인 gke를 포함하는 배열로 설정해야 합니다.

discovery_service.gcp[0].project_ids

귀하의 매처에서 myproject를 Google Cloud 프로젝트의 ID로 교체하십시오. project_ids 필드는 하나 이상의 값을 포함해야 하며, 와일드카드 문자(*)일 수 없습니다.

discovery_service.gcp[0].locations

각 매처의 locations 필드는 GKE 클러스터를 검색할 Google Cloud 지역 또는 영역 이름의 배열을 포함합니다. 와일드카드 문자 *는 매처가 모든 위치를 검색하도록 구성합니다.

discovery_service.gcp[0].tags

locations와 같이 tags는 각 키가 태그의 키를 나타내는 문자열이며 각 값이 단일 문자열 또는 문자열 목록, 즉 단일 태그 값 또는 태그 값 목록을 나타내는 맵으로 구성됩니다.

와일드카드 키 또는 값은 Google Cloud 계정의 모든 태그 키 또는 값과 일치합니다. 다른 값을 포함하면 매처는 제공된 태그를 가진 모든 GKE 클러스터와 일치합니다.

Kubernetes Service와 Discovery Service 시작

Kubernetes Service를 실행할 호스트에서 다음 명령을 실행합니다. 방법에 따라:

• 패키지 관리자를 사용하여 설치했거나 TAR 아카이브를 통해 설치했는지
• Google Cloud 또는 다른 플랫폼에서 Discovery 및 Kubernetes Service를 실행하는지에 따라

sudo systemctl start teleport

sudo teleport install systemd -o /etc/systemd/system/teleport.service
sudo systemctl enable teleport
sudo systemctl start teleport

GOOGLE_APPLICATION_CREDENTIALS="/var/lib/teleport/google-cloud-credentials.json"

sudo systemctl enable teleport
sudo systemctl start teleport

sudo teleport install systemd -o /etc/systemd/system/teleport.service
sudo systemctl enable teleport

GOOGLE_APPLICATION_CREDENTIALS="/var/lib/teleport/google-cloud-credentials.json"

sudo systemctl start teleport

3단계/3단계. GKE 클러스터에 연결

Kubernetes 클러스터에 대한 액세스 허용

액세스를 활성화할 클러스터에 대한 올바른 Kubernetes 컨텍스트에 있는지 확인하십시오:

kubectl config current-context

kubectl config get-contexts

kubectl config use-context CONTEXT_NAME
Switched to context CONTEXT_NAME

Kubernetes 클러스터에 Teleport를 통해 인증하기 위해, Teleport 사용자 역할이 최소한 하나의 Kubernetes 사용자 또는 그룹에 대한 접근을 허용해야 합니다.

1. 현재 사용자의 Teleport 역할 목록을 검색합니다. 아래 예제는 JSON 파싱을 위해 jq 유틸리티가 필요합니다:

   CURRENT_ROLES=$(tsh status -f json | jq -r '.active.roles | join ("\n")')

2. 역할이 허용하는 Kubernetes 그룹을 검색합니다:

   echo "$CURRENT_ROLES" | xargs -I{} tctl get roles/{} --format json | \  jq '.[0].spec.allow.kubernetes_groups[]?'

3. 역할이 허용하는 Kubernetes 사용자를 검색합니다:

   echo "$CURRENT_ROLES" | xargs -I{} tctl get roles/{} --format json | \  jq '.[0].spec.allow.kubernetes_users[]?'

4. 이전 두 명령 중 하나의 출력이 비어 있지 않다면, 사용자가 최소한 하나의 Kubernetes 사용자 또는 그룹에 접근할 수 있으므로 다음 단계로 진행할 수 있습니다.

5. 두 목록이 모두 비어 있다면, 이 가이드를 위해 클러스터 내 Kubernetes 리소스를 볼 수 있는 Teleport 역할을 생성하십시오.

   kube-access.yaml이라는 파일을 만들고 다음 내용을 추가합니다:

   kind: role
   metadata:
     name: kube-access
   version: v7
   spec:
     allow:
       kubernetes_labels:
         '*': '*'
       kubernetes_resources:
         - kind: '*'
           namespace: '*'
           name: '*'
           verbs: ['*']
       kubernetes_groups:
       - viewers
     deny: {}
   

6. 변경 사항을 적용합니다:

   tctl create -f kube-access.yaml

7. kube-access 역할을 Teleport 사용자에게 할당하려면 인증 제공자에 맞는 적절한 명령어를 실행하세요:

   • 로컬 사용자
   • GitHub
   • SAML
   • OIDC

   1. 로컬 사용자의 역할을 콤마로 구분된 목록으로 가져옵니다:

      ROLES=$(tsh status -f json | jq -r '.active.roles | join(",")')

   2. 로컬 사용자를 편집하여 새로운 역할을 추가합니다:

      tctl users update $(tsh status -f json | jq -r '.active.username') \  --set-roles "${ROLES?},kube-access"

   3. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

   1. github 인증 커넥터를 가져옵니다:

      tctl get github/github --with-secrets > github.yaml

      --with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 github.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 github.yaml 파일을 제거해야 합니다.

   2. github.yaml을 편집하고 teams_to_roles 섹션에 kube-access을 추가합니다.

      이 역할에 매핑할 팀은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 하지만 팀에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 팀이어야 합니다.

      여기에 예시가 있습니다:

        teams_to_roles:
          - organization: octocats
            team: admins
            roles:
              - access
      +       - kube-access
      

   3. 변경 사항을 적용합니다:

      tctl create -f github.yaml

   4. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 assum 하기 위해 다시 로그인합니다.

   1. saml 구성 리소스를 가져옵니다:

      tctl get --with-secrets saml/mysaml > saml.yaml

      --with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 saml.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 saml.yaml 파일을 제거해야 합니다.

   2. saml.yaml을 편집하고 attributes_to_roles 섹션에 kube-access을 추가합니다.

      이 역할에 매핑할 속성은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 그러나 그룹에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 그룹이어야 합니다.

      여기에 예시가 있습니다:

        attributes_to_roles:
          - name: "groups"
            value: "my-group"
            roles:
              - access
      +       - kube-access
      

   3. 변경 사항을 적용합니다:

      tctl create -f saml.yaml

   4. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

   1. oidc 구성 리소스를 가져옵니다:

      tctl get oidc/myoidc --with-secrets > oidc.yaml

      --with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 oidc.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 oidc.yaml 파일을 제거해야 합니다.

   2. oidc.yaml을 편집하고 claims_to_roles 섹션에 kube-access을 추가합니다.

      이 역할에 매핑할 클레임은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 그러나 그룹에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 그룹이어야 합니다.

      여기에 예시가 있습니다:

        claims_to_roles:
          - name: "groups"
            value: "my-group"
            roles:
              - access
      +       - kube-access
      

   3. 변경 사항을 적용합니다:

      tctl create -f oidc.yaml

   4. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

8. Kubernetes 클러스터에서 viewers 그룹을 내장된 view ClusterRole을 가지도록 구성합니다. 사용자가 kube-access 역할을 맡고 Kubernetes API 서버에 요청을 보낼 때, Teleport Kubernetes 서비스는 viewers 그룹으로 가장하고 요청을 프록시합니다.

   viewers-bind.yaml이라는 파일을 만들고 다음 내용을 추가하여, Teleport 사용자가 접근할 수 있도록 설정한 viewers 그룹과 내장된 view ClusterRole을 바인딩합니다:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: viewers-crb
   subjects:
   - kind: Group
     # "kube-access" 역할에 대해 설정한 kubernetes_groups에 해당하는 "viewers" 그룹을 바인딩합니다.
     name: viewers
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     # "view"는 리소스에 대한 읽기 전용 액세스를 허용하는 기본 ClusterRole입니다.
     # 참고: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles
     name: view
     apiGroup: rbac.authorization.k8s.io
   

9. kubectl을 사용하여 ClusterRoleBinding을 적용합니다:

   kubectl apply -f viewers-bind.yaml

클러스터에 액세스

Discovery Service를 실행하면 GKE 클러스터를 검색하고 Teleport에 클러스터를 등록합니다. 다음 tctl 명령을 실행하여 확인할 수 있습니다:

tctl get kube_clusters
kind: kube_clustermetadata:  description: GKE 클러스터 "mycluster-gke" in us-east1  id: 0000000000000000000  labels:    location: us-east1    project-id: myproject    teleport.dev/cloud: GCP    teleport.dev/origin: cloud  name: mycluster-gkespec:  aws: {}  azure: {}version: v3

Teleport 사용자에게 액세스할 수 있는 Kubernetes 클러스터 목록을 나열하려면 다음 명령을 실행합니다. 목록에는 이제 GKE 클러스터가 포함되어야 합니다:

tsh kube ls
Kube Cluster Name   Labels                                                                                                   Selected------------------- -------------------------------------------------------------------------------------------------------- --------mycluster-gke location=us-east1 project-id=myproject teleport.dev/cloud=GCP teleport.dev/origin=cloud

클러스터에 로그인하려면, 이전에 나열한 클러스터의 이름을 mycluster-gke로 교체하십시오:

tsh kube login mycluster-gke
Logged into kubernetes cluster "mycluster-gke". Try 'kubectl version' to test the connection.

보시다시피, Teleport GKE 자동 검색 기능을 통해 클러스터를 Teleport 내에 수동으로 등록할 필요 없이 Google Cloud 계정 내 GKE 클러스터에 액세스할 수 있습니다. GKE에서 클러스터를 생성하거나 제거할 때마다 Teleport는 계정에서 사용할 수 있는 클러스터 상태를 업데이트합니다.

문제 해결

Discovery Service 문제 해결

먼저, 발견된 Kubernetes cluster가 있는지 확인하세요. 이렇게 하려면 tctl get kube_cluster 명령을 사용하여 예상되는 Kubernetes cluster가 이미 Teleport 클러스터에 등록되었는지 확인할 수 있습니다.

목록에 일부 Kubernetes cluster가 나타나지 않으면, Discovery Service 선택기 레이블이 누락된 Kubernetes cluster 태그와 일치하는지 확인하거나 Discovery Service 로그에서 권한 오류를 확인하세요.

Discovery Service가 올바른 AWS 계정의 자격 증명으로 실행되고 있는지 확인하세요. 다른 AWS 계정에서 리소스를 발견할 수 있지만, 그럴 경우 다른 AWS 계정에서 역할을 맡도록 구성되어야 합니다.

한 개 이상의 Discovery Service가 실행되고 있는지 확인하세요:

tctl inventory status --connected

여러 개의 Discovery Service를 실행하는 경우, 각 서비스가 동일한 클라우드 Kubernetes cluster를 감시하는 경우는 동일한 discovery_group 값으로 구성되어야 하며, 다른 클라우드 Kubernetes cluster를 감시하는 경우는 서로 다른 값으로 구성되어야 합니다. 이것이 올바르게 구성되지 않으면, 일반적인 증상은 kube_cluster 리소스가 Teleport 클러스터의 레지스트리에서 간헐적으로 삭제되는 것입니다.

Kubernetes 서비스 문제 해결

tctl get kube_cluster 명령이 발견된 클러스터를 반환하지만 tctl kube ls 명령에 포함되지 않는 경우, kubernetes_service.resources 섹션이 올바르게 설정되었는지 확인하세요.

kubernetes_service:
  enabled: "yes"
  resources:
  - labels:
      "env": "prod"

섹션이 올바르게 구성되었지만 클러스터가 여전히 나타나지 않거나 인증 오류가 반환되는 경우, 대상 클러스터에서 권한이 올바르게 구성되었는지 또는 Teleport에서 Kubernetes 클러스터를 나열할 수 있는 올바른 권한이 있는지 확인하세요.