이 가이드에서는 원격 Teleport 클러스터에 대해 Teleport Kubernetes Operator를 실행하는 방법을 설명합니다. Teleport 클러스터가 teleport-cluster Helm 차트를 사용하여 배포된 경우 대신 Helm 배포 클러스터 가이드를 따를 수 있습니다.

작동 방식#

Teleport Kubernetes Operator는 teleport-operator Helm 차트를 사용하여 설치하는 Teleport Auth Service 클라이언트입니다.

Operator가 클러스터에서 Teleport 리소스를 관리하려면 Teleport 클러스터로 인증하고 Teleport 리소스를 관리할 권한을 부여해야 합니다. 이를 위해 이 가이드에서 생성 방법을 알려드리는 다음 추가 리소스가 필요합니다:

• Teleport 역할
• 조인 토큰(join token)
• 머신 & 워크로드 아이덴티티 봇

그런 다음 teleport-operator 차트를 설치하여 Operator를 배포할 수 있습니다.

사전 요구사항#

• 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 클러스터. Namespace, ServiceAccount, Deployment, Secret, Role, RoleBinding 및 CustomResourceDefinition 리소스를 생성/읽을 수 있어야 합니다.
• Helm
• kubectl

다음 명령을 실행하여 Kubernetes 연결을 확인합니다:

$ kubectl cluster-info
# Kubernetes control plane is running at https://127.0.0.1:6443
# CoreDNS is running at https://127.0.0.1:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
# Metrics-server is running at https://127.0.0.1:6443/api/v1/namespaces/kube-system/services/https:metrics-server:https/proxy

운영자를 로컬에서 실험하려는 사용자는 minikube를 사용하여 로컬 Kubernetes 클러스터를 시작할 수 있습니다:

$ minikube start

1단계/4단계: 운영자 역할 생성#

이 단계에서는 운영자가 Teleport 리소스와 상호작용하는 데 사용하는 역할을 생성합니다.

운영자 역할 매니페스트를 다운로드하고 적용합니다:

$ curl -L https://raw.githubusercontent.com/gravitational/teleport/v(=teleport.version=)/integrations/operator/hack/fixture-operator-role.yaml -o operator-role.yaml
$ tctl create -f operator-role.yaml

참고: 새 Teleport 리소스에 대한 지원을 추가하는 새 버전으로 운영자를 업그레이드하는 경우 운영자 역할 매니페스트를 다시 적용해야 합니다. 이렇게 하면 운영자에게 새 리소스에 대한 접근 권한이 부여됩니다.

2단계/4단계: 운영자 조인 토큰 생성#

조인 토큰은 시작 시마다 운영자가 Teleport 클러스터에 조인하고 클라이언트 인증서를 검색하는 데 사용됩니다.

연결하는 운영자와 Teleport 간의 신뢰를 설정하기 위해 인증을 Kubernetes에 위임합니다. Kubernetes는 파드에 마운트된 ServiceAccount 토큰에 서명하는 자체 내부 CA를 가지고 있습니다. 다음 설정에서 Teleport는 Kubernetes가 서명한 SA 토큰을 신뢰하여 클러스터에 조인합니다.

1. Kubernetes JWKS 검색(Teleport가 Kubernetes SA 토큰을 검증하는 데 사용할 수 있는 키)

   $ export JWKS="$(kubectl get --raw /openid/v1/jwks)"
   

2. 네임스페이스 teleport-iac의 서비스 계정 teleport-iac-operator가 운영자로 클러스터에 조인할 수 있는 토큰 매니페스트를 생성합니다.

   $ cat <
   
   

I cannot delete the Kubernetes CR#

The operator protects Kubernetes CRs from deletion with a finalizer. It will not allow the CR to be deleted until the Teleport resource is deleted as well, this is a safety to avoid leaving dangling resources and potentially grant unintentional access.

There might be some reasons causing Teleport to refuse a resource deletion, the most frequent one is if another resource depends on it. For example: you cannot delete a role if it is still assigned to a user.

If this happens, the operator will report the error sent by Teleport in its log.

To resolve this lock, you can either:

• resolve the dependency issue so the resource gets successfully deleted in Teleport. In the role example, this would imply removing any mention of the role from the various users who had it.

• patch the Kubernetes CR to remove the finalizers. This will tell Kubernetes to stop waiting for the operator deletion and remove the CR. If you do this, the CR will be removed but the Teleport resource will remain. The operator will never attempt to remove it again.

  For example, if the role is named my-role:

  kubectl patch TeleportRole my-role -p '{"metadata":{"finalizers":null}}' --type=merge