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

이 가이드에서는 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 클러스터 버전 17.0.0-dev 이상. Teleport를 시작하려면 가입하여 무료 평가판을 이용하거나 데모 환경 설정 방법을 확인하십시오.

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

  tctl 및 tsh 다운로드 방법에 대한 지침은 설치를 방문하십시오.

• GKE 클러스터, IAM 역할 및 서비스 계정을 생성할 수 있는 권한이 있는 Google Cloud 계정.
• gcloud CLI 도구. Google Cloud 문서 페이지를 따라 gcloud 를 설치하고 인증하십시오.
• 하나 이상의 GKE 클러스터가 실행 중이어야 합니다. Kubernetes 사용자는 클러스터에서 ClusterRole 및 ClusterRoleBinding 리소스를 생성할 수 있는 권한이 있어야 합니다.
• Teleport Discovery 및 Kubernetes 서비스를 실행할 Linux 호스트. 이 호스트는 어떤 클라우드 공급자에서도 실행할 수 있으며, 로컬 컴퓨터를 사용할 수도 있습니다.
• 연결이 가능한지 확인하기 위해 tsh login 으로 로그인한 다음, 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어:

  tsh login --proxy=teleport.example.com --user=email@example.com
  tctl status
  클러스터  teleport.example.com
  버전  17.0.0-dev
  CA 핀   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678

  클러스터에 연결할 수 있고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 후속 tctl 명령어를 실행할 수 있습니다.
  자신의 Teleport 클러스터를 호스팅하는 경우, Teleport Auth Service를 호스팅하는 컴퓨터에서 전체 권한으로 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에 서비스 계정을 연결합니다.

프로세스는 Google Cloud에서 Teleport Kubernetes Service 및 Discovery Service를 배포하는지, 아니면 다른 방법(예: 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단계. Teleport를 구성하여 GKE 클러스터 검색

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-v15.4.11.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"
  discovery_group: "gke-myproject"
  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 클러스터에 대한 matcher입니다. Discovery Service는 각 matcher에 따라 Google Cloud API에 대한 요청을 주기적으로 실행하여 GKE 클러스터를 나열합니다. 이 경우, 단일 matcher를 선언했습니다.

각 matcher는 다음의 모든 속성과 일치하는 클러스터를 검색합니다. 즉, 지정된 위치와 프로젝트에 속하고 지정된 태그를 가진 클러스터를 검색합니다. Discovery Service는 구성된 matcher 중 임의와 일치하는 GKE 클러스터를 등록합니다.

이는 다음 두 개의 matchers를 선언하면, Discovery Service가 us-east1 에서 실행 중인 프로젝트 myproj-dev 의 클러스터와 us-east2 에서 실행 중인 프로젝트 myproj-prod 의 클러스터를 등록하지만, us-east2 에서 실행 중인 myproj-dev 의 클러스터는 등록하지 않음을 의미합니다:

discovery_service:
  enabled: "yes"
  discovery_group: "gke-myproject"
  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

각 matcher의 types 필드는 단일 문자열 값 gke 를 가진 배열로 설정해야 합니다.

discovery_service.gcp[0].project_ids

matcher에서 myproject 를 귀하의 Google Cloud 프로젝트 ID로 교체하십시오.

project_ids 필드는 다음 규칙을 따라야 합니다:

• 최소 하나의 값을 포함해야 합니다.
• 와일드카드 문자 (*)를 다른 값과 결합해서는 안 됩니다.

유효한 구성 예

• ["p1", "p2"]
• ["*"]
• ["p1"]

유효하지 않은 구성 예

• ["p1", "*"]

discovery_service.gcp[0].locations

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

discovery_service.gcp[0].tags

locations 와 마찬가지로, tags 는 각 키가 태그의 키를 나타내는 문자열이고 각 값이 단일 문자열 또는 문자열 배열로 구성된 맵입니다. 이 값은 하나의 태그 값 또는 태그 값 목록을 나타냅니다.

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

Kubernetes 서비스 및 Discovery 서비스 시작

Kubernetes 서비스를 실행할 호스트에서 다음 명령을 실행하십시오. 특정 사항에 따라:

• 패키지 관리자를 사용하여 Teleport를 설치했는지 여부 또는 TAR 아카이브를 통해 설치했는지 여부
• Google Cloud 또는 다른 플랫폼에서 Discovery 및 Kubernetes 서비스를 실행 중인지 여부

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 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.

   1. 텍스트 편집기에서 github 인증 커넥터를 엽니다:

      tctl edit github/github

   2. github 커넥터를 수정하여 teams_to_roles 섹션에 kube-access 을 추가합니다.

      이 역할에 매핑해야 하는 팀은 조직의 역할 기반 액세스 제어(RBAC) 설계에 따라 다릅니다. 그러나 팀은 귀하의 사용자 계정을 포함해야 하며, 조직 내에서 가장 작은 팀이어야 합니다.

      예시는 다음과 같습니다:

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

   3. 파일을 편집하고 저장하여 변경 사항을 적용합니다.

   4. Teleport 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.

   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 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.

   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 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.

8. Kubernetes 클러스터 내에서 viewers 그룹이 기본 제공 view ClusterRole을 갖도록 구성합니다. 여러분의 Teleport 사용자가 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
kubernetes 클러스터 "mycluster-gke"에 로그인했습니다. 연결을 테스트하려면 'kubectl version'을 사용해 보십시오.

보시다시피, Teleport GKE 자동 검색 기능을 통해 Google Cloud 계정의 GKE 클러스터에 액세스할 수 있게 되었으며, 해당 클러스터를 Teleport 내에서 수동으로 등록할 필요가 없었습니다. 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 클러스터를 나열할 수 있는 올바른 권한이 있는지 확인하십시오.