Teleport를 사용하여 Kubernetes 클러스터에 등록할 수 있지만, Teleport Kubernetes Service를 해당 클러스터에서 실행 할 수 있으며, 클러스터 외부의 Linux 호스트에서 Teleport Kubernetes Service를 실행할 수도 있습니다. 이는 Teleport 배포를 관리할 Kubernetes 클러스터와 분리하려는 경우에 유용합니다.

이 설정에서는 Teleport Kubernetes Service가 선택한 Kubernetes 클러스터의 API 서버에 인증하기 위해 kubeconfig 파일을 사용합니다.

사전 요구 사항

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

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

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

• 액세스할 Kubernetes 클러스터.
• Teleport Kubernetes Service를 실행하기 위한 자체 인프라에 배포된 Linux 호스트. 이 호스트는 Kubernetes 클러스터 외부에서 실행될 수 있습니다.
• 작업 공간에 설치된 kubectl 명령줄 도구.
• 당신의 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/4. kubeconfig 파일 생성

Teleport Kubernetes Service는 Kubernetes 클러스터에 인증하기 위해 kubeconfig 파일을 사용합니다. 이 섹션에서는 Teleport Kubernetes Service가 나중에 사용할 수 있도록 kubeconfig 파일을 생성합니다.

컨텍스트가 올바른지 확인

먼저, 등록할 Kubernetes 클러스터를 가리키도록 로컬 kubectl 명령을 구성합니다. 다음 명령을 사용하여 올바른 클러스터가 선택되었는지 확인할 수 있습니다:

kubectl config get-contexts

다음 명령을 사용하여 CONTEXT_NAME에 할당된 클러스터로 전환합니다:

예: my-context
CONTEXT_NAME=context-name
kubectl config use-context ${CONTEXT_NAME?}

스크립트 실행

작업 공간에서 Teleport의 get-kubeconfig.sh 스크립트를 다운로드하여 kubeconfig 파일을 생성하는 데 사용합니다:

curl -OL \https://raw.githubusercontent.com/gravitational/teleport/v16.2.0/examples/k8s-auth/get-kubeconfig.sh

get-kubeconfig.sh는 Teleport Kubernetes Service를 위한 서비스 계정을 생성하여 Kubernetes 포드를 가져오고 사용자, 그룹 및 기타 서비스 계정을 임인할 수 있습니다. Teleport Kubernetes Service는 이 서비스 계정을 사용하여 Kubernetes 클러스터의 리소스에 대한 액세스를 관리합니다. 스크립트는 또한 서비스 계정 자격 증명을 저장할 Kubernetes Secret가 클러스터에 존재하는지 확인합니다.

get-kubeconfig.sh는 또한 배포하는 리소스를 위한 teleport라는 네임스페이스를 생성하지만, 스크립트를 실행하는 셸에서 TELEPORT_NAMESPACE 환경 변수를 할당하여 다른 이름을 선택할 수 있습니다.

리소스를 생성한 후에 get-kubeconfig.sh는 스크립트를 실행한 디렉토리에 kubeconfig라는 새 kubeconfig 파일을 씁니다.

get-kubeconfig.sh 스크립트를 실행합니다:

bash get-kubeconfig.sh

스크립트가 성공하면 다음 메시지를 볼 수 있습니다:

Done!

kubeconfig 파일을 Teleport Kubernetes Service를 실행하는 호스트로 이동합니다. 이제 kubeconfig 파일이 /var/lib/teleport/kubeconfig에 존재한다고 가정합니다.

단계 2/4. Teleport Kubernetes Service 설정

이 단계에서는 Teleport Kubernetes Service를 설치하고, 이용 가능한 Kubernetes 클러스터에 액세스하기 위해 생성한 kubeconfig 파일을 사용하도록 구성합니다.

조인 토큰 가져오기

귀하의 Teleport 클러스터와 새로운 Kubernetes Service 인스턴스 간의 신뢰를 확립하기 위해 조인 토큰을 생성합니다:

tctl tokens add --type=kube --format=text --ttl=1h
abcd123-insecure-do-not-use-this

Teleport Kubernetes Service를 실행하는 호스트에서 /tmp/token이라는 파일을 만듭니다. 이 파일에는 오직 귀하의 토큰만 포함되어야 합니다:

echo join-token | sudo tee /tmp/token

Teleport Kubernetes Service 설치

Teleport Kubernetes Service를 설치할 호스트에서 다음 명령을 실행합니다:

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 Kubernetes Service 구성

Teleport Kubernetes Service를 실행할 호스트에서 다음 내용을 가진 파일을 /etc/teleport.yaml에 생성합니다:

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"
  kubeconfig_file: "/var/lib/teleport/kubeconfig"
  labels:
    "region": "us-east1"

/etc/teleport.yaml에서 teleport.example.com:443를 귀하의 Teleport Proxy Service나 Teleport Cloud 테넌트의 호스트 및 포트로 교체하십시오. 예: mytenant.teleport.sh:443.

Teleport Kubernetes Service 시작

호스트가 부팅될 때 Teleport Kubernetes Service가 자동으로 시작되도록 시스템 데몬 서비스를 생성하여 구성합니다. 지침은 Teleport Kubernetes Service를 설치한 방법에 따라 다릅니다.

sudo systemctl enable teleport
sudo systemctl start teleport

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

Teleport Kubernetes Service의 상태는 systemctl status teleport로 확인할 수 있으며, 로그는 journalctl -fu teleport로 볼 수 있습니다.

단계 3/4. Teleport 사용자에게 액세스 권한 부여

Teleport 사용자에게 Kubernetes 클러스터의 리소스에 액세스할 수 있도록 설정하여 이 가이드에서 나중에 클러스터에 연결할 수 있도록 합니다.

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

단계 4/4. Kubernetes 클러스터에 액세스

위의 구성으로 Teleport가 시작되면, 모든 새로운 클러스터를 볼 수 있습니다:

tsh kube ls
Kube Cluster Name                       Labels           Selected--------------------------------------- ------           --------my-cluster                              region=us-east-1

클러스터에 액세스하려면, 다음 명령을 실행하되, my-cluster를 액세스할 클러스터 이름으로 교체하십시오:

tsh kube login my-cluster
Kubernetes 클러스터 "my-cluster"에 로그인했습니다. 연결을 테스트하려면 'kubectl version'을 시도하십시오.