Teleport는 Kubernetes 클러스터에 대한 안전하고 통합된 접근을 제공할 수 있습니다. 이 가이드는 Helm과 ArgoCD를 사용하여 Kubernetes 클러스터에 Teleport Kubernetes 에이전트를 배포하는 방법을 보여줍니다.

작동 방식#

Argo CD는 Kubernetes를 위한 선언형 GitOps 지속적 전달 도구입니다. 이는 대규모 배포를 조율하고, Kubernetes 리소스가 원하는 배포 상태에서 벗어나는 것을 방지하는 데 사용됩니다.

Teleport에는 Kubernetes 클러스터에 Teleport 에이전트를 배포하는 공식 Helm 차트(teleport-kube-agent)가 있습니다. 에이전트는 여러 서비스를 실행하도록 구성할 수 있지만, 기본적으로 kubernetes_service를 실행하여 Teleport를 통해 Kubernetes API에 대한 접근을 제공합니다.

이 가이드는 ArgoCD의 기본 Helm 지원을 활용하여 teleport-kube-agent Helm 차트를 사용해 Teleport 에이전트를 배포합니다.

사전 요구 사항#

• Teleport를 통해 접근을 제공하려는 기존 Kubernetes 클러스터.

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 클러스터에 배포할 수 있는 기존 ArgoCD 인스턴스(버전 2.10 이상).
• 워크스테이션에 설치된 tsh 클라이언트 도구 v[teleport.version]+. 설치 페이지에서 다운로드할 수 있습니다.

1/3단계. 조인 토큰 생성#

Teleport 에이전트는 조인 토큰을 사용하여 인증서를 획득하고 Teleport에 연결합니다. 자세한 내용은 조인 문서를 참조하세요. 토큰은 초기 조인 시에만 사용되며, Teleport Kube 에이전트는 Kubernetes에 인증서를 저장하고 이후 조인 시에는 토큰이 필요하지 않습니다. 이 섹션에서는 에이전트가 Teleport 클러스터에 조인할 수 있는 토큰을 생성합니다.

$ tctl tokens add --type=kube,app --ttl=5m

다음 토큰 유형을 지정할 수 있습니다:

차트가 지원하는 역할 및 토큰 유형은 teleport-kube-agent 차트 레퍼런스를 참조하세요.

2/3단계. ArgoCD를 통해 teleport-kube-agent Helm 차트 구성 및 배포#

1. Teleport를 위한 네임스페이스를 생성하고 Pod Security Admission을 구성합니다. 이는 네임스페이스의 파드에 보안 표준을 적용합니다:

   $ kubectl create namespace teleport
   namespace/teleport created
   
   $ kubectl label namespace teleport 'pod-security.kubernetes.io/enforce=baseline'
   namespace/teleport labeled
   

2. 다음을 템플릿으로 사용하여 새 ArgoCD 애플리케이션을 생성합니다.

project: default
source:
  repoURL: 'https://charts.releases.teleport.dev'
  targetRevision: (=teleport.version=)
  helm:
    values: |-
      roles: kube,app
      authToken: $YOUR_AUTH_TOKEN
      proxyAddr: $YOUR_PROXY_ADDRESS
      kubeClusterName: $YOUR_KUBE_CLUSTER_NAME

      highAvailability:
          replicaCount: 2
          podDisruptionBudget:
              enabled: true
              minAvailable: 1
  chart: teleport-kube-agent
destination:
  server: 'https://kubernetes.default.svc'
  namespace: teleport
# 이 섹션은 teleport-kube-agent-updater가 ArgoCD가 업데이트를 되돌리지 않고
# 에이전트를 업데이트할 수 있도록 허용하는 데 사용됩니다.
ignoreDifferences:
  - group: apps
    kind: StatefulSet
    name: $YOUR_APPLICATION_NAME
    namespace: teleport
    jqPathExpressions:
      - '.spec.template.spec.containers[] | select(.name == "teleport").image'

3. 다음 명령을 사용하여 변경 사항을 동기화하고 구성을 적용합니다:

$ argocd app sync $YOUR_APPLICATION_NAME

4. 설정을 확인하려면 Teleport 클러스터의 '리소스' 페이지로 이동하여 Kubernetes 클러스터가 등록되었는지 확인합니다.

3/3단계. 새 리소스에 대한 접근 관리#

이 단계에서는 viewers 그룹의 구성원으로서 Teleport로 보호된 모든 Kubernetes 클러스터에 요청을 보낼 수 있도록 사용자를 허용하는 kube-access라는 Teleport 역할을 생성합니다. Teleport Kubernetes 서비스는 해당 사용자의 요청을 프록시할 때 viewers 그룹을 가장합니다.

1. 다음 내용으로 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: {}
   

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

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

kube-access 역할이 viewers 그룹의 구성원으로서 Kubernetes 클러스터에 접근할 수 있도록 승인되었지만, 이 그룹은 아직 Kubernetes 클러스터 내에서 권한이 없습니다. 이러한 권한을 부여하려면 viewers 그룹에 권한을 부여하는 Kubernetes RoleBinding 또는 ClusterRoleBindings를 생성합니다.

1. 다음 내용으로 viewers-bind.yaml 파일을 생성합니다:

   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
   

2. kubectl로 ClusterRoleBinding을 적용합니다:

   $ kubectl apply -f viewers-bind.yaml
   

이제 Teleport 사용자는 Kubernetes 클러스터에 접근할 때 viewers 그룹의 구성원 자격을 가정할 수 있는 권한을 갖게 되었으며, viewers 그룹은 클러스터의 리소스를 조회할 수 있는 권한을 갖게 되었습니다.