Teleport 검색 서비스는 Google Kubernetes Engine(GKE) 클러스터를 Teleport에 자동으로 등록할 수 있습니다. Teleport Kubernetes 검색을 통해 Teleport Kubernetes 서비스와 검색 서비스를 한 번 구성한 다음, 각 생성 후 Teleport에 등록하지 않고도 GKE 클러스터를 생성할 수 있습니다.

이 가이드에서는 GKE용 Teleport Kubernetes 검색을 시작하는 방법을 보여줍니다.

작동 방식#

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 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` 파일을 더블 클릭하여 설치를 시작합니다.
 
     

       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
     ```
   

 

• GKE 클러스터, IAM 역할 및 서비스 계정을 생성할 권한이 있는 Google Cloud 계정.
• gcloud CLI 도구. gcloud를 설치하고 인증하려면 Google Cloud 문서 페이지를 따르세요.
• 실행 중인 하나 이상의 GKE 클러스터. Kubernetes 사용자는 클러스터에서 ClusterRole 및 ClusterRoleBinding 리소스를 생성할 권한이 있어야 합니다.
• Teleport 검색 및 Kubernetes 서비스를 실행할 Linux 호스트. 이 호스트는 어떤 클라우드 공급자에서든 또는 로컬 머신에서도 실행할 수 있습니다.

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 명령을 실행할 수도 있습니다.

1/3단계. Google Cloud 자격 증명 획득#

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

검색 서비스를 위한 IAM 역할 생성#

Teleport 검색 서비스는 Google Cloud 프로젝트와 연결된 GKE 클러스터를 검색하는 권한이 필요합니다.

이러한 권한을 부여하려면 다음 내용으로 GKEKubernetesAutoDisc.yaml 파일을 생성합니다:

title: GKE Cluster Discoverer
description: "Get and list GKE clusters"
stage: GA
includedPermissions:
- container.clusters.get
- container.clusters.list

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

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

Kubernetes 서비스를 위한 IAM 역할 생성#

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

다음 내용으로 GKEAccessManager.yaml 파일을 생성합니다:

title: GKE Cluster Access Manager
description: "Manage access to GKE clusters"
stage: GA
includedPermissions:
- container.clusters.connect
- container.clusters.get
- container.clusters.impersonate
- container.pods.get
- container.selfSubjectAccessReviews.create
- container.selfSubjectRulesReviews.create

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

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

서비스 계정 생성#

검색 서비스 및 Kubernetes 서비스에 대한 역할을 선언했으므로 이제 이러한 역할을 할당할 수 있는 서비스 계정을 생성합니다.

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

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

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

$ 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 서비스 및 검색 서비스와 연결합니다.

프로세스는 Google Cloud 또는 다른 방법(예: Amazon EC2 또는 로컬 네트워크를 통해)으로 Teleport Kubernetes 서비스와 검색 서비스를 배포하는지에 따라 다릅니다.

$ 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 클러스터를 검색할 수 있는 서비스 계정과 접근을 관리할 수 있는 클러스터 역할을 생성했으므로, 이제 GKE 클러스터를 감지하도록 Teleport 검색 서비스를 구성하고 사용자 트래픽을 프록시하도록 Kubernetes 서비스를 구성합니다.

Teleport 설치#

Kubernetes 서비스와 검색 서비스를 실행하는 데 사용하는 호스트에 Teleport를 설치합니다:

Linux 서버에 Teleport Agent를 설치하려면:

권장 설치 방법은 클러스터 설치 스크립트입니다. 이 스크립트는 클러스터에 맞는 올바른 버전, 에디션, 설치 모드를 선택합니다.

1. teleport.example.com:443에 Teleport 클러스터의 호스트명과 포트를 할당하되, 스킴(https://)은 포함하지 마십시오.

2. 클러스터의 설치 스크립트를 실행하십시오:

   $ curl "https://teleport.example.com:443/scripts/install.sh" | sudo bash
   

참여 토큰 생성#

Teleport 검색 서비스와 Kubernetes 서비스는 클러스터에 참여하기 위한 인증 토큰이 필요합니다. 다음 tctl 명령을 실행하여 생성합니다:

$ tctl tokens add --type=discovery,kube --format=text
(=presets.tokens.first=)

토큰(예: 위의 <code>[presets.tokens.first]</code>)을 복사하고 검색 서비스와 Kubernetes 서비스를 실행할 머신의 /tmp/token에 저장합니다. 예를 들어:

$ echo (=presets.tokens.first=) | sudo tee /tmp/token
# (=presets.tokens.first=)

$ tctl tokens add --type=discovery --format=text
# (=presets.tokens.second=)
$ tctl tokens add --type=kube --format=text
# (=presets.tokens.third=)

Kubernetes 서비스 및 검색 서비스 구성#

Kubernetes 서비스와 검색 서비스를 실행하는 호스트에서 /etc/teleport.yaml에 다음 내용으로 Teleport 구성 파일을 생성합니다:

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

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

version: v3
teleport:
  join_params:
    token_name: "/tmp/token"
    method: token
  proxy_server: teleport.example.com:443
auth_service:
  enabled: false
proxy_service:
  enabled: false
ssh_service:
  enabled: false
discovery_service:
  enabled: true
  discovery_group: "gke-myproject"
  gcp:
    - types: ["gke"]
      locations: ["*"]
      project_ids: ["myproject"] # 내 프로젝트 ID로 교체
      tags:
        "*" : "*"

아래 설명에 따라 환경에 맞게 이 구성을 편집합니다.

proxy_server#

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

discovery_service.gcp#

discovery_service.gcp의 각 항목은 GKE에서 실행 중인 Kubernetes 클러스터에 대한 매처입니다. 검색 서비스는 각 매처를 기반으로 Google Cloud API에 주기적으로 요청을 실행하여 GKE 클러스터를 나열합니다. 이 경우 단일 매처를 선언했습니다.

각 매처는 매처의 모든 속성과 일치하는 클러스터, 즉 지정된 위치와 프로젝트에 속하고 지정된 태그가 있는 클러스터를 검색합니다. 검색 서비스는 구성된 매처 중 하나와 일치하는 GKE 클러스터를 등록합니다.

즉, 다음 두 매처를 선언하면 검색 서비스는 us-east1에서 실행 중인 myproj-dev 프로젝트의 클러스터와 us-east2에서 실행 중인 myproj-prod 프로젝트의 클러스터를 등록하지만, us-east2에서 실행 중인 myproj-dev의 클러스터는 등록하지 않습니다:

discovery_service:
  enabled: true
  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#

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

discovery_service.gcp[0].project_ids#

매처에서 myproject를 Google Cloud 프로젝트의 ID로 교체합니다.

project_ids 필드가 다음 규칙을 따르는지 확인합니다:

• 하나 이상의 값이 포함되어야 함.
• 와일드카드 문자(*)를 다른 값과 결합할 수 없음.

유효한 구성 예시#

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

유효하지 않은 구성 예시#

• ["p1", "*"]

discovery_service.gcp[0].locations#

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

discovery_service.gcp[0].tags#

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

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

Kubernetes 서비스 및 검색 서비스 시작#

Kubernetes 서비스를 실행할 호스트에서 다음 항목에 따라 다음 명령을 실행합니다:

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

$ sudo systemctl start teleport

$ sudo teleport install systemd -o /etc/systemd/system/teleport.service
$ sudo systemctl enable teleport
$ 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

Teleport를 통해 Kubernetes 클러스터에 인증하려면, 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
   

인증 공급자에 맞는 적절한 명령을 실행하여 kube-access 역할을 your Teleport user에게 할당하십시오:

Local User

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 클러스터에서 로그아웃한 다음 다시 로그인하여 새 역할을 적용합니다.

GitHub

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 클러스터에서 로그아웃한 다음 다시 로그인하여 새 역할을 적용합니다.

SAML

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 클러스터에서 로그아웃한 다음 다시 로그인하여 새 역할을 적용합니다.

OIDC

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 클러스터에서 로그아웃한 다음 다시 로그인하여 새 역할을 적용합니다.

5. Kubernetes 클러스터에서 viewers 그룹이 내장 view ClusterRole을 갖도록 구성합니다. Teleport 사용자가 kube-access 역할을 맡아 Kubernetes API 서버로 요청을 보내면, Teleport Kubernetes Service가 viewers 그룹을 가장(impersonate)하여 요청을 프록시합니다.

   다음 내용으로 viewers-bind.yaml 파일을 생성하여, 내장 view ClusterRole을 Teleport 사용자가 접근할 수 있도록 활성화한 viewers 그룹에 바인딩합니다.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: viewers-crb
   subjects:
   - kind: Group
     # Bind the group "viewers", corresponding to the kubernetes_groups we assigned our "kube-access" role above
     name: viewers
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     # "view" is a default ClusterRole that grants read-only access to resources
     # See: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles
     name: view
     apiGroup: rbac.authorization.k8s.io
   

6. kubectl로 ClusterRoleBinding을 적용합니다.

   $ kubectl apply -f viewers-bind.yaml
   

클러스터 접근#

검색 서비스를 실행했을 때 GKE 클러스터를 검색하고 Teleport에 클러스터를 등록했습니다. 다음 tctl 명령을 실행하여 이를 확인할 수 있습니다:

$ tctl get kube_clusters
kind: kube_cluster
metadata:
  description: GKE cluster "mycluster-gke" in us-east1
  id: 0000000000000000000
  labels:
    location: us-east1
    project-id: myproject
    teleport.dev/cloud: GCP
    teleport.dev/origin: cloud
  name: mycluster-gke
spec:
  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 계정에서 역할을 assume하도록 구성되어 있어야 합니다.

둘 이상의 Discovery Service가 실행 중인지 확인합니다:

$ tctl inventory status --connected

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

Kubernetes Service 문제 해결#

tctl get kube_cluster 명령이 발견된 클러스터를 반환하지만 tctl kube ls 명령에는 해당 클러스터가 포함되지 않는 경우, kubernetes_service.resources 섹션이 올바르게 설정되어 있는지 확인하십시오.

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

섹션이 올바르게 구성되어 있는데도 클러스터가 여전히 나타나지 않거나 인증 오류를 반환하는 경우, 대상 클러스터에 권한이 올바르게 구성되어 있는지 또는 Teleport에서 Kubernetes 클러스터를 나열할 수 있는 올바른 권한을 보유하고 있는지 확인하십시오.