InfoGrab Docs

Argo CD와 함께하는 머신 및 워크로드 아이덴티티

요약

Argo CD는 Kubernetes를 위한 선언형 GitOps 지속적 배포 도구입니다. 이 가이드에서는 머신 및 워크로드 아이덴티티 에이전트 tbot이 Argo CD의 클러스터 자격 증명을 관리하도록 설정하여 Teleport를 사용하여 안전하게 애플리케이션을 배포할 수 있게 합니다.

Argo CD는 Kubernetes를 위한 선언형 GitOps 지속적 배포 도구입니다. Kubernetes에서 실행되며 동일 클러스터 또는 다른 "외부" 클러스터에 애플리케이션을 배포할 수 있습니다.

이 가이드에서는 머신 및 워크로드 아이덴티티 에이전트 tbot이 Argo CD의 클러스터 자격 증명을 관리하도록 설정하여 Teleport를 사용하여 안전하게 애플리케이션을 배포할 수 있게 합니다.

작동 방식#

Argo CD는 Kubernetes 시크릿을 사용하여 선언적으로 클러스터를 관리하는 것을 지원합니다(Argo CD 문서 참조). Argo CD 애플리케이션 컨트롤러는 이 시크릿을 읽어 클러스터 자격 증명을 검색합니다. Argo CD 출력 서비스를 사용하도록 설정하면 tbot이 Teleport로 서명된 Kubernetes 클러스터 자격 증명을 시크릿에 기록하고 Argo CD가 이를 사용하여 Teleport로 보호된 Kubernetes 클러스터에 접근할 수 있습니다.

사전 조건#

  • A running Teleport cluster. If you want to get started with Teleport, sign up for a free trial or set up a demo environment.

  • The tctl and tsh clients.

    Installing `tctl` and `tsh` clients
    1. Determine the version of your Teleport cluster. The tctl and tsh clients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at /v1/webapi/find and use a JSON query tool to obtain your cluster version. Replace with the web address of your Teleport Proxy Service:

      $ TELEPORT_DOMAIN=
      $ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"
      
    2. Follow the instructions for your platform to install tctl and tsh clients:

  • Kubernetes 클러스터에 Argo CD가 설치되어 있어야 합니다. 이 클러스터는 이 가이드에서 소스 클러스터라고 불리며 Teleport에 등록될 필요는 없습니다.
  • Argo CD가 애플리케이션을 배포할 Kubernetes 클러스터. 이 클러스터는 이 가이드에서 대상 클러스터라고 불리며 Teleport에 등록되어 있어야 합니다. 아직 하지 않았다면 Kubernetes 클러스터 등록 가이드를 따르세요.

To check that you can connect to your Teleport cluster, sign in with tsh login, then verify that you can run tctl commands using your current credentials.

For example, run the following command, assigning to the domain name of the Teleport Proxy Service in your cluster and to your Teleport username:

$ tsh login --proxy= --user=
$ tctl status
# Cluster  (=teleport.url=)
# Version  (=teleport.version=)
# CA pin   (=presets.ca_pin=)

If you can connect to the cluster and run the tctl status command, you can use your current credentials to run subsequent tctl commands from your workstation. If you host your own Teleport cluster, you can also run tctl commands on the computer that hosts the Teleport Auth Service for full permissions.

  • Kubernetes를 설정하고 tbot을 배포하려면 kubectlhelm이 설치되어 있어야 합니다.
  • 클러스터가 Argo CD에 등록되었는지 확인하려면 argocd CLI가 설치되어 있어야 합니다.

1단계/4단계. Teleport 및 Kubernetes RBAC 설정#

먼저 머신 및 워크로드 아이덴티티 에이전트 tbot에 올바른 수준의 접근을 부여하기 위해 Teleport와 Kubernetes 모두에 대한 RBAC를 설정해야 합니다.

봇을 대신하여 Kubernetes API에 요청을 전달할 때, Teleport Proxy는 봇의 Teleport 역할에서 설정된 그룹(kubernetes_groups 사용)을 요청에 첨부합니다. 이 그룹은 그런 다음 Kubernetes에서 RoleBinding 또는 ClusterRoleBinding을 설정하여 Kubernetes 클러스터 내에서 봇에게 특정 권한을 부여하는 데 사용됩니다.

이 가이드의 목적을 위해 대부분의 Kubernetes 클러스터에 사전 설정된 기본 edit ClusterRole에 editor 그룹을 바인딩하여 봇에게 모든 클러스터 네임스페이스의 리소스에 대한 읽기 및 쓰기 접근을 부여합니다.

프로덕션 환경에서 이를 설정할 때 고려해야 할 사항:

  • 봇의 접근을 특정 네임스페이스로 제한하기 위해 ClusterRoleBinding 대신 RoleBinding을 사용해야 하는지.
  • 기존의 일반 역할인 edit를 사용하는 것 대신 봇에게 최소 필요 권한을 부여하는 역할을 만들어야 하는지.

소스 및 대상 클러스터 모두에 대해 다음 명령을 실행하여 editor 그룹을 edit ClusterRole에 바인딩합니다:

$ kubectl create clusterrolebinding teleport-editor-edit \
  --clusterrole=edit \
  --group=editor

특정 그룹에 접근을 부여하도록 Kubernetes에서 적절한 RoleBinding이 설정되면 이제 봇이 자격 증명을 생성할 때 가장할 역할에 이 그룹을 추가해야 합니다. 또한 클러스터 자체에 대한 Teleport를 통한 접근을 봇에게 부여해야 합니다. 이는 필요한 권한을 부여하는 역할을 만들고 해당 역할을 봇에 할당하는 방식으로 수행됩니다.

다음 내용으로 role.yaml 파일을 만듭니다:

kind: role
version: v7
metadata:
  name: example-role
spec:
  allow:
    kubernetes_labels:
      '*': '*'
    kubernetes_groups:
    - editor
    kubernetes_resources:
    - kind: "*"
      namespace: "*"
      name: "*"
      verbs: ["*"]

example-role을 사용 사례와 관련된 설명적인 이름으로 교체하세요.

환경에 맞게 allow 필드를 조정합니다:

  • kubernetes_labels는 봇이 접근해야 하는 클러스터에만 접근을 허용하도록 조정해야 합니다. 표시된 값 '*': '*'은 모든 Kubernetes 클러스터에 대한 접근을 허용합니다.
  • editor는 RoleBinding 또는 ClusterRoleBinding에서 지정한 그룹 이름과 일치해야 합니다.
  • kubernetes_resources는 봇이 Kubernetes 클러스터 내에서 접근할 수 있는 것에 대한 추가 제한을 적용하는 데 사용할 수 있습니다. 이 제한은 Kubernetes 역할 자체 내에서 설정된 RBAC 위에 계층을 이룹니다.

tctl create -f ./role.yaml을 사용하여 역할을 만듭니다.

2단계/4단계. 봇 만들기#

다음으로 봇을 만들어야 합니다. 봇은 머신 또는 머신 그룹에 대한 Teleport 아이덴티티입니다.

다음 내용으로 bot.yaml 파일을 만듭니다:

kind: bot
version: v1
metadata:
  # name은 Teleport 내에서 봇을 고유하게 식별합니다.
  name: example-bot
spec:
  # 봇에 부여될 역할.
  roles: [example-role]

example-bot을 봇에 대한 고유하고 설명적인 이름으로 교체하고, example-role을 이전 단계에서 만든 역할의 이름으로 교체하세요.

tctl create -f ./bot.yaml을 사용하여 봇을 만듭니다.

3단계/4단계. 조인 토큰 만들기#

tbot이 Teleport 클러스터에 인증하고 조인할 수 있도록 조인 토큰을 설정해야 합니다. 여러 가지 사용 가능한 방법이 있지만, 이 가이드에서는 정적 JWKS로 kubernetes 방법을 사용합니다. 자세한 내용은 Kubernetes에 tbot 배포 가이드를 참조하세요.

OIDC 조인

Amazon EKS와 같은 특정 클라우드 공급자는 OIDC 서명 키를 정기적으로 순환하여 이 가이드에서 만든 static_jwks 설정이 짧은 시간 후에 무효화될 수 있습니다.

Amazon EKS(Elastic Kubernetes Service), Google Kubernetes Engine(GKE), Azure Kubernetes Service(AKS)와 같은 OIDC 지원이 있는 Kubernetes 공급자에서는 대신 Kubernetes OIDC 조인을 사용하는 것을 고려하세요.

먼저 소스 클러스터에 대해 다음 명령을 실행하여 JWKS 형식의 공개 키를 확인합니다:

$ kubectl get --raw /openid/v1/jwks
{"keys":[--snip--]}%

다음으로, curl 명령의 출력을 spec.kubernetes.static_jwks.jwks에 삽입하고 spec.kubernetes.allow[0].service_account에 Argo CD가 실행 중인 네임스페이스를 지정하여 다음 내용으로 join-token.yaml 파일을 만듭니다:

kind: token
version: v2
metadata:
  # name은 나중에 tbot Helm 차트 값에서 지정됩니다.
  name: example-join-token
spec:
  roles: [Bot]
  # bot_name은 이 가이드에서 이전에 만든 봇의 이름과 일치해야 합니다.
  bot_name: example-bot
  join_method: kubernetes
  kubernetes:
    # static_jwks는 Auth Service가 정적으로 설정된 JWKS의 공개 키를 사용하여
    # `tbot`이 제시한 JWT를 검증하도록 설정합니다.
    type: static_jwks
    static_jwks:
      jwks: |
        # curl 명령으로 반환된 데이터를 여기에 배치합니다.
        {"keys":[--snip--]}
    # allow는 Auth Service가 `tbot`의 조인 허용 여부를 결정하는 규칙을 지정합니다.
    allow:
    - service_account: "argocd:tbot" # namespace:service_account

tctl create -f ./join-token.yaml을 사용하여 조인 토큰을 만듭니다.

4단계/4단계. tbot 배포#

마지막으로 공식 Helm 차트를 사용하여 tbot을 배포합니다.

tctl status를 실행하여 클러스터 이름을 확인합니다.

다음 내용으로 tbot-values.yaml 파일을 만들고, 플레이스홀더 값을 클러스터 이름, 프록시 주소로 교체하고, clusterSelectors를 사용하여 Argo CD에 노출할 Kubernetes 클러스터를 식별합니다:

clusterName: "test.teleport.sh"
teleportProxyAddress: "test.teleport.sh:443"
token: "example-join-token"
defaultOutput:
  enabled: false
argocd:
  enabled: true
  clusterSelectors:
    - labels:
        environment: production

지원되는 모든 설정 옵션은 Helm 차트 레퍼런스를 참조하세요.

소스 클러스터에 대해 다음 명령을 실행하여 Helm 차트를 설치하고, Argo CD가 실행 중인 네임스페이스를 지정하세요:

$ helm repo add teleport (=teleport.helm_repo_url=)
$ helm repo update
$ helm install tbot teleport/tbot \
  --namespace argocd \
  --values tbot-values.yaml

Helm 차트 설치가 완료되면(일반적으로 몇 분 후), Argo CD에서 Kubernetes 클러스터를 볼 수 있습니다. 다음 명령을 실행하여 확인할 수 있습니다:

$ argocd cluster list
SERVER                                                                    NAME
https://test.teleport.sh:443/v1/teleport/dHAxLmZsb3BweS5jbw/Ym94b2ZyYWQ1  test.teleport.sh-prod-eu-1
https://kubernetes.default.svc                                            in-cluster

다음 명령을 실행할 때 Kubernetes에서 tbot이 관리하는 클러스터 시크릿을 볼 수 있어야 합니다:

$ kubectl get secrets -n argocd | grep ^teleport.argocd-cluster.
teleport.argocd-cluster.e815df7b7588be17   Opaque               3      7d3h

이제 Argo CD가 Teleport에 등록된 클러스터에 애플리케이션을 배포하도록 설정할 수 있습니다!

Teleport에서 새로운 일치하는 클러스터가 추가되면 tbot이 다음 인증서 갱신 시 Argo CD에 등록합니다. 필요한 경우 파드를 삭제하거나 즉시 다시 로드를 트리거하는 신호(pkill -USR1 tbot)로 tbot 프로세스를 재시작할 수 있습니다.

안전을 위해 Teleport에서 클러스터가 삭제되거나 clusterSelectors와 더 이상 일치하지 않으면 Argo CD에서 자동으로 제거되지 않습니다 - 하지만 tbot은 자격 증명 갱신을 중지합니다.

Argo CD 가장(Impersonation)#

Argo CD는 Kubernetes의 사용자 가장(impersonation) 기능을 사용하여 애플리케이션 동기화 프로세스에 Argo 컨트롤 플레인이 일반적으로 갖는 것보다 더 제한적인 권한을 부여하는 것을 지원합니다. 이를 사용하면 동일한 클러스터에 배포되지만 다른 프로젝트에 있는 애플리케이션이 서로의 리소스를 읽거나 수정할 수 없는 권한 경계를 만들 수 있습니다.

Teleport Kubernetes Access와 함께 Argo CD 가장을 사용하려면 봇에게 kubernetes_users에 와일드카드가 포함된 역할이 있어야 합니다. 예를 들어:

kind: role
version: v7
metadata:
  name: kube-wildcard-access
spec:
  allow:
    kubernetes_users:
    - '*'

Argo CD가 가장할 수 있는 사용자를 kubernetes_users에 단순히 열거하면 다음 오류가 발생합니다:

please select a user to impersonate, refusing to select a user due to several kubernetes_users set up for this user

이는 Argo CD가 애플리케이션 범위 리소스에서 작동하는 요청에만 가장 헤더를 설정하기 때문에 발생합니다. 역할에 많은 사용자를 가장하는 권한이 있으므로 Teleport가 기본적으로 어떤 사용자를 사용해야 하는지 모호합니다.

kubernetes_users에 와일드카드가 포함되어 있고 특정 사용자가 가장되지 않는 경우 Kubernetes Access는 기본적으로 봇의 Teleport 사용자 이름을 사용합니다. 따라서 대상 클러스터에서 RoleBinding 또는 ClusterRoleBinding을 만들어 Argo CD 컨트롤 플레인에 필요한 더 광범위한 권한을 봇 사용자에게 부여해야 합니다.

$ kubectl create clusterrolebinding example-bot-edit \
  --clusterrole=edit \
  --user=bot-example-bot
Warning

Argo CD 프로젝트 간에 권한 경계를 만들기 위해 가장을 사용할 때, Kubernetes Access가 기본적으로 kubernetes_groups에 나열된 그룹을 자동으로 가장한다는 점을 기억하세요.

봇 사용자가 kubernetes_groups를 포함하는 역할을 갖지 않도록 해야 합니다. 그렇지 않으면 다른 사용자를 가장함으로써 제공되는 권한 격리가 침해됩니다. 애플리케이션 동기화 프로세스에 가장된 사용자의 권한과 그룹에 부여된 권한의 조합이 부여되기 때문입니다.

다음 단계#

Argo CD와 함께하는 머신 및 워크로드 아이덴티티

원문 보기
요약

Argo CD는 Kubernetes를 위한 선언형 GitOps 지속적 배포 도구입니다. 이 가이드에서는 머신 및 워크로드 아이덴티티 에이전트 tbot이 Argo CD의 클러스터 자격 증명을 관리하도록 설정하여 Teleport를 사용하여 안전하게 애플리케이션을 배포할 수 있게 합니다.

Argo CD는 Kubernetes를 위한 선언형 GitOps 지속적 배포 도구입니다. Kubernetes에서 실행되며 동일 클러스터 또는 다른 "외부" 클러스터에 애플리케이션을 배포할 수 있습니다.

이 가이드에서는 머신 및 워크로드 아이덴티티 에이전트 tbot이 Argo CD의 클러스터 자격 증명을 관리하도록 설정하여 Teleport를 사용하여 안전하게 애플리케이션을 배포할 수 있게 합니다.

작동 방식#

Argo CD는 Kubernetes 시크릿을 사용하여 선언적으로 클러스터를 관리하는 것을 지원합니다(Argo CD 문서 참조). Argo CD 애플리케이션 컨트롤러는 이 시크릿을 읽어 클러스터 자격 증명을 검색합니다. Argo CD 출력 서비스를 사용하도록 설정하면 tbot이 Teleport로 서명된 Kubernetes 클러스터 자격 증명을 시크릿에 기록하고 Argo CD가 이를 사용하여 Teleport로 보호된 Kubernetes 클러스터에 접근할 수 있습니다.

사전 조건#

  • A running Teleport cluster. If you want to get started with Teleport, sign up for a free trial or set up a demo environment.

  • The tctl and tsh clients.

    Installing `tctl` and `tsh` clients
    1. Determine the version of your Teleport cluster. The tctl and tsh clients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at /v1/webapi/find and use a JSON query tool to obtain your cluster version. Replace with the web address of your Teleport Proxy Service:

      $ TELEPORT_DOMAIN=
      $ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"
      
    2. Follow the instructions for your platform to install tctl and tsh clients:

  • Kubernetes 클러스터에 Argo CD가 설치되어 있어야 합니다. 이 클러스터는 이 가이드에서 소스 클러스터라고 불리며 Teleport에 등록될 필요는 없습니다.
  • Argo CD가 애플리케이션을 배포할 Kubernetes 클러스터. 이 클러스터는 이 가이드에서 대상 클러스터라고 불리며 Teleport에 등록되어 있어야 합니다. 아직 하지 않았다면 Kubernetes 클러스터 등록 가이드를 따르세요.

To check that you can connect to your Teleport cluster, sign in with tsh login, then verify that you can run tctl commands using your current credentials.

For example, run the following command, assigning to the domain name of the Teleport Proxy Service in your cluster and to your Teleport username:

$ tsh login --proxy= --user=
$ tctl status
# Cluster  (=teleport.url=)
# Version  (=teleport.version=)
# CA pin   (=presets.ca_pin=)

If you can connect to the cluster and run the tctl status command, you can use your current credentials to run subsequent tctl commands from your workstation. If you host your own Teleport cluster, you can also run tctl commands on the computer that hosts the Teleport Auth Service for full permissions.

  • Kubernetes를 설정하고 tbot을 배포하려면 kubectlhelm이 설치되어 있어야 합니다.
  • 클러스터가 Argo CD에 등록되었는지 확인하려면 argocd CLI가 설치되어 있어야 합니다.

1단계/4단계. Teleport 및 Kubernetes RBAC 설정#

먼저 머신 및 워크로드 아이덴티티 에이전트 tbot에 올바른 수준의 접근을 부여하기 위해 Teleport와 Kubernetes 모두에 대한 RBAC를 설정해야 합니다.

봇을 대신하여 Kubernetes API에 요청을 전달할 때, Teleport Proxy는 봇의 Teleport 역할에서 설정된 그룹(kubernetes_groups 사용)을 요청에 첨부합니다. 이 그룹은 그런 다음 Kubernetes에서 RoleBinding 또는 ClusterRoleBinding을 설정하여 Kubernetes 클러스터 내에서 봇에게 특정 권한을 부여하는 데 사용됩니다.

이 가이드의 목적을 위해 대부분의 Kubernetes 클러스터에 사전 설정된 기본 edit ClusterRole에 editor 그룹을 바인딩하여 봇에게 모든 클러스터 네임스페이스의 리소스에 대한 읽기 및 쓰기 접근을 부여합니다.

프로덕션 환경에서 이를 설정할 때 고려해야 할 사항:

  • 봇의 접근을 특정 네임스페이스로 제한하기 위해 ClusterRoleBinding 대신 RoleBinding을 사용해야 하는지.
  • 기존의 일반 역할인 edit를 사용하는 것 대신 봇에게 최소 필요 권한을 부여하는 역할을 만들어야 하는지.

소스 및 대상 클러스터 모두에 대해 다음 명령을 실행하여 editor 그룹을 edit ClusterRole에 바인딩합니다:

$ kubectl create clusterrolebinding teleport-editor-edit \
  --clusterrole=edit \
  --group=editor

특정 그룹에 접근을 부여하도록 Kubernetes에서 적절한 RoleBinding이 설정되면 이제 봇이 자격 증명을 생성할 때 가장할 역할에 이 그룹을 추가해야 합니다. 또한 클러스터 자체에 대한 Teleport를 통한 접근을 봇에게 부여해야 합니다. 이는 필요한 권한을 부여하는 역할을 만들고 해당 역할을 봇에 할당하는 방식으로 수행됩니다.

다음 내용으로 role.yaml 파일을 만듭니다:

kind: role
version: v7
metadata:
  name: example-role
spec:
  allow:
    kubernetes_labels:
      '*': '*'
    kubernetes_groups:
    - editor
    kubernetes_resources:
    - kind: "*"
      namespace: "*"
      name: "*"
      verbs: ["*"]

example-role을 사용 사례와 관련된 설명적인 이름으로 교체하세요.

환경에 맞게 allow 필드를 조정합니다:

  • kubernetes_labels는 봇이 접근해야 하는 클러스터에만 접근을 허용하도록 조정해야 합니다. 표시된 값 '*': '*'은 모든 Kubernetes 클러스터에 대한 접근을 허용합니다.
  • editor는 RoleBinding 또는 ClusterRoleBinding에서 지정한 그룹 이름과 일치해야 합니다.
  • kubernetes_resources는 봇이 Kubernetes 클러스터 내에서 접근할 수 있는 것에 대한 추가 제한을 적용하는 데 사용할 수 있습니다. 이 제한은 Kubernetes 역할 자체 내에서 설정된 RBAC 위에 계층을 이룹니다.

tctl create -f ./role.yaml을 사용하여 역할을 만듭니다.

2단계/4단계. 봇 만들기#

다음으로 봇을 만들어야 합니다. 봇은 머신 또는 머신 그룹에 대한 Teleport 아이덴티티입니다.

다음 내용으로 bot.yaml 파일을 만듭니다:

kind: bot
version: v1
metadata:
  # name은 Teleport 내에서 봇을 고유하게 식별합니다.
  name: example-bot
spec:
  # 봇에 부여될 역할.
  roles: [example-role]

example-bot을 봇에 대한 고유하고 설명적인 이름으로 교체하고, example-role을 이전 단계에서 만든 역할의 이름으로 교체하세요.

tctl create -f ./bot.yaml을 사용하여 봇을 만듭니다.

3단계/4단계. 조인 토큰 만들기#

tbot이 Teleport 클러스터에 인증하고 조인할 수 있도록 조인 토큰을 설정해야 합니다. 여러 가지 사용 가능한 방법이 있지만, 이 가이드에서는 정적 JWKS로 kubernetes 방법을 사용합니다. 자세한 내용은 Kubernetes에 tbot 배포 가이드를 참조하세요.

OIDC 조인

Amazon EKS와 같은 특정 클라우드 공급자는 OIDC 서명 키를 정기적으로 순환하여 이 가이드에서 만든 static_jwks 설정이 짧은 시간 후에 무효화될 수 있습니다.

Amazon EKS(Elastic Kubernetes Service), Google Kubernetes Engine(GKE), Azure Kubernetes Service(AKS)와 같은 OIDC 지원이 있는 Kubernetes 공급자에서는 대신 Kubernetes OIDC 조인을 사용하는 것을 고려하세요.

먼저 소스 클러스터에 대해 다음 명령을 실행하여 JWKS 형식의 공개 키를 확인합니다:

$ kubectl get --raw /openid/v1/jwks
{"keys":[--snip--]}%

다음으로, curl 명령의 출력을 spec.kubernetes.static_jwks.jwks에 삽입하고 spec.kubernetes.allow[0].service_account에 Argo CD가 실행 중인 네임스페이스를 지정하여 다음 내용으로 join-token.yaml 파일을 만듭니다:

kind: token
version: v2
metadata:
  # name은 나중에 tbot Helm 차트 값에서 지정됩니다.
  name: example-join-token
spec:
  roles: [Bot]
  # bot_name은 이 가이드에서 이전에 만든 봇의 이름과 일치해야 합니다.
  bot_name: example-bot
  join_method: kubernetes
  kubernetes:
    # static_jwks는 Auth Service가 정적으로 설정된 JWKS의 공개 키를 사용하여
    # `tbot`이 제시한 JWT를 검증하도록 설정합니다.
    type: static_jwks
    static_jwks:
      jwks: |
        # curl 명령으로 반환된 데이터를 여기에 배치합니다.
        {"keys":[--snip--]}
    # allow는 Auth Service가 `tbot`의 조인 허용 여부를 결정하는 규칙을 지정합니다.
    allow:
    - service_account: "argocd:tbot" # namespace:service_account

tctl create -f ./join-token.yaml을 사용하여 조인 토큰을 만듭니다.

4단계/4단계. tbot 배포#

마지막으로 공식 Helm 차트를 사용하여 tbot을 배포합니다.

tctl status를 실행하여 클러스터 이름을 확인합니다.

다음 내용으로 tbot-values.yaml 파일을 만들고, 플레이스홀더 값을 클러스터 이름, 프록시 주소로 교체하고, clusterSelectors를 사용하여 Argo CD에 노출할 Kubernetes 클러스터를 식별합니다:

clusterName: "test.teleport.sh"
teleportProxyAddress: "test.teleport.sh:443"
token: "example-join-token"
defaultOutput:
  enabled: false
argocd:
  enabled: true
  clusterSelectors:
    - labels:
        environment: production

지원되는 모든 설정 옵션은 Helm 차트 레퍼런스를 참조하세요.

소스 클러스터에 대해 다음 명령을 실행하여 Helm 차트를 설치하고, Argo CD가 실행 중인 네임스페이스를 지정하세요:

$ helm repo add teleport (=teleport.helm_repo_url=)
$ helm repo update
$ helm install tbot teleport/tbot \
  --namespace argocd \
  --values tbot-values.yaml

Helm 차트 설치가 완료되면(일반적으로 몇 분 후), Argo CD에서 Kubernetes 클러스터를 볼 수 있습니다. 다음 명령을 실행하여 확인할 수 있습니다:

$ argocd cluster list
SERVER                                                                    NAME
https://test.teleport.sh:443/v1/teleport/dHAxLmZsb3BweS5jbw/Ym94b2ZyYWQ1  test.teleport.sh-prod-eu-1
https://kubernetes.default.svc                                            in-cluster

다음 명령을 실행할 때 Kubernetes에서 tbot이 관리하는 클러스터 시크릿을 볼 수 있어야 합니다:

$ kubectl get secrets -n argocd | grep ^teleport.argocd-cluster.
teleport.argocd-cluster.e815df7b7588be17   Opaque               3      7d3h

이제 Argo CD가 Teleport에 등록된 클러스터에 애플리케이션을 배포하도록 설정할 수 있습니다!

Teleport에서 새로운 일치하는 클러스터가 추가되면 tbot이 다음 인증서 갱신 시 Argo CD에 등록합니다. 필요한 경우 파드를 삭제하거나 즉시 다시 로드를 트리거하는 신호(pkill -USR1 tbot)로 tbot 프로세스를 재시작할 수 있습니다.

안전을 위해 Teleport에서 클러스터가 삭제되거나 clusterSelectors와 더 이상 일치하지 않으면 Argo CD에서 자동으로 제거되지 않습니다 - 하지만 tbot은 자격 증명 갱신을 중지합니다.

Argo CD 가장(Impersonation)#

Argo CD는 Kubernetes의 사용자 가장(impersonation) 기능을 사용하여 애플리케이션 동기화 프로세스에 Argo 컨트롤 플레인이 일반적으로 갖는 것보다 더 제한적인 권한을 부여하는 것을 지원합니다. 이를 사용하면 동일한 클러스터에 배포되지만 다른 프로젝트에 있는 애플리케이션이 서로의 리소스를 읽거나 수정할 수 없는 권한 경계를 만들 수 있습니다.

Teleport Kubernetes Access와 함께 Argo CD 가장을 사용하려면 봇에게 kubernetes_users에 와일드카드가 포함된 역할이 있어야 합니다. 예를 들어:

kind: role
version: v7
metadata:
  name: kube-wildcard-access
spec:
  allow:
    kubernetes_users:
    - '*'

Argo CD가 가장할 수 있는 사용자를 kubernetes_users에 단순히 열거하면 다음 오류가 발생합니다:

please select a user to impersonate, refusing to select a user due to several kubernetes_users set up for this user

이는 Argo CD가 애플리케이션 범위 리소스에서 작동하는 요청에만 가장 헤더를 설정하기 때문에 발생합니다. 역할에 많은 사용자를 가장하는 권한이 있으므로 Teleport가 기본적으로 어떤 사용자를 사용해야 하는지 모호합니다.

kubernetes_users에 와일드카드가 포함되어 있고 특정 사용자가 가장되지 않는 경우 Kubernetes Access는 기본적으로 봇의 Teleport 사용자 이름을 사용합니다. 따라서 대상 클러스터에서 RoleBinding 또는 ClusterRoleBinding을 만들어 Argo CD 컨트롤 플레인에 필요한 더 광범위한 권한을 봇 사용자에게 부여해야 합니다.

$ kubectl create clusterrolebinding example-bot-edit \
  --clusterrole=edit \
  --user=bot-example-bot
Warning

Argo CD 프로젝트 간에 권한 경계를 만들기 위해 가장을 사용할 때, Kubernetes Access가 기본적으로 kubernetes_groups에 나열된 그룹을 자동으로 가장한다는 점을 기억하세요.

봇 사용자가 kubernetes_groups를 포함하는 역할을 갖지 않도록 해야 합니다. 그렇지 않으면 다른 사용자를 가장함으로써 제공되는 권한 격리가 침해됩니다. 애플리케이션 동기화 프로세스에 가장된 사용자의 권한과 그룹에 부여된 권한의 조합이 부여되기 때문입니다.

다음 단계#