독립형 쿠버네티스 운영자 | Teleport 공식 기술 문서 한국판 by 인포그랩

독립형 쿠버네티스 운영자

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

전제 조건

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

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

Kubernetes 클러스터. 네임스페이스, 서비스 계정, 배포, 비밀, 역할, 역할 바인딩 및 사용자 정의 리소스 정의 리소스를 생성/읽을 수 있어야 합니다.
Helm
kubectl
최소 버전 15에서 실행 중인 Teleport 클러스터.

다음 명령을 실행하여 Kubernetes 연결을 검증하십시오:

kubectl cluster-info
Kubernetes 제어 플레인이 https://127.0.0.1:6443에서 실행 중입니다
CoreDNS는 https://127.0.0.1:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy에서 실행 중입니다
Metrics-server는 https://127.0.0.1:6443/api/v1/namespaces/kube-system/services/https:metrics-server:https/proxy에서 실행 중입니다

Tip

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

minikube start

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

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

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

curl -L https://raw.githubusercontent.com/gravitational/teleport/v16.2.0/integrations/operator/hack/fixture-operator-role.yaml -o operator-role.yaml
tctl create -f operator-role.yaml

Note

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

2단계/4. 운영자 참여 토큰 생성

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

연결된 운영자와 Teleport 간의 신뢰 관계를 설정하기 위해 인증을 Kubernetes에 위임하고 있습니다. Kubernetes에는 서비스 계정 토큰이 파드에 마운트되는 자체 내부 CA가 있습니다. 다음 설정에서, Teleport는 클러스터에 참여하기 위해 Kubernetes에서 서명한 SA 토큰을 신뢰할 것입니다.

Kubernetes JWKS(Teleport가 Kubernetes SA 토큰을 유효화하는 데 사용할 수 있는 키)를 검색합니다.
```
export JWKS="$(kubectl get --raw /openid/v1/jwks)"
```

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

cat <<EOF > operator-token.yamlkind: tokenversion: v2metadata:  name: operator-botspec:  roles: [Bot]  # bot_name은 이 가이드에서 이후에 생성될 봇의 이름과 일치해야 합니다.  bot_name: operator  join_method: kubernetes  kubernetes:    type: static_jwks    static_jwks:      jwks: |        $JWKS    allow:    - service_account: "teleport-iac:teleport-operator" # 네임스페이스:서비스계정EOF

그런 다음 토큰 매니페스트를 적용합니다:
```
tctl create -f operator-token.yaml
```
마지막으로, 토큰을 사용하기 위해 필요한 Teleport 클러스터 이름을 검색합니다:
```
export CLUSTER_NAME="$(tctl status | awk '/Cluster/ {print $2}')"
```

3단계/4. 운영자 봇 생성

Teleport에서 봇은 머신이 Teleport에 액세스할 수 있도록 하는 리소스입니다. 다음 명령으로 운영자를 위한 봇을 생성합니다:

tctl bots add operator --token operator-bot --roles operator

4단계/4. Kubernetes 클러스터에 운영자 배포

이 시점에서 운영자를 구성하고 실행할 수 있습니다:

Teleport Helm 리포지토리를 설정하세요. Teleport Helm 리포지토리에 호스팅된 차트를 설치하도록 Helm을 허용하세요:

helm repo add teleport https://charts.releases.teleport.dev

원격 리포지토리의 차트 캐시를 업데이트하여 모든 사용 가능한 릴리즈로 업그레이드할 수 있습니다:

helm repo update

Teleport 클러스터의 버전을 복구합니다:

export TELEPORT_VERSION="$(tsh version | awk '/Proxy[[:space:]]version/ {print $3}')"echo "$TELEPORT_VERSION"

운영자 Pods와 Teleport 구성에 사용할 CustomResources를 포함할 네임스페이스를 생성합니다:
```
kubectl create namespace teleport-iac
```

네임스페이스에 가장 엄격한 Pod 보안 표준을 적용합니다:

kubectl label namespace teleport-iac 'pod-security.kubernetes.io/enforce=restricted'

Helm으로 운영자를 배포합니다:

helm install teleport-operator teleport/teleport-operator -n teleport-iac --version "$TELEPORT_VERSION" --set teleportAddress=teleport.example.com:443 --set "teleportClusterName=$CLUSTER_NAME" --set token=operator-bot

운영자가 제대로 실행되고 있는지 확인합니다(운영자가 시작하는 데 몇 초가 걸릴 수 있습니다):
```
kubectl get pods -n teleport-iac
```

다음 단계

사용자 및 역할 IaC 가이드를 따라 새로 배포된 Teleport Kubernetes Operator를 사용하여 Teleport 사용자 생성 및 역할 부여를 진행하십시오.

Helm Chart 매개변수는 teleport-operator Helm 차트 참조에서 문서화되어 있습니다.

Troubleshooting

CustomResources (CRs)가 조정되지 않음

Teleport Operator는 Kubernetes에서 새로운 리소스 또는 변경 사항을 감시합니다. 변경이 발생하면 조정 루프가 트리거됩니다. 이 루프는 리소스를 검증하고, Teleport에 이미 존재하는지 확인하며, 리소스를 생성/업데이트/삭제하기 위해 Teleport API에 호출을 합니다. 조정 루프는 Kubernetes 리소스에 status 필드도 추가합니다.

오류가 발생하고 조정 루프가 성공하지 못하면 status.conditions에 무슨 일이 잘못되었는지 설명하는 항목이 있습니다.
이로 인해 사용자는 kubectl을 사용하여 Kubernetes 리소스를 검사함으로써 오류를 진단할 수 있습니다:

kubectl describe teleportusers myuser

예를 들어, 사용자가 존재하지 않는 역할을 부여받았다면 상태는 다음과 같을 것입니다:

apiVersion: resources.teleport.dev/v2
kind: TeleportUser
# [...]
status:
  conditions:
  - lastTransitionTime: "2022-07-25T16:15:52Z"
    message: Teleport 리소스에 Kubernetes 출처 레이블이 있습니다.
    reason: OriginLabelMatching
    status: "True"
    type: TeleportResourceOwned
  - lastTransitionTime: "2022-07-25T17:08:58Z"
    message: 'Teleport가 반환한 오류: 역할 my-non-existing-role이(가) 발견되지 않음'
    reason: TeleportError
    status: "False"
    type: SuccessfullyReconciled

여기서 SuccessfullyReconciled는 False이며, 오류는 role my-non-existing-role is not found입니다.

상태가 존재하지 않거나 문제를 해결할 충분한 정보를 제공하지 않는 경우,
운영자 로그를 확인하세요:

CR에 상태가 없음

CR이 운영자와 동일한 네임스페이스에 있는지 확인하세요. 운영자는 자신의 네임스페이스의 리소스만 감시합니다.
운영자 포드가 실행되고 있는지 및 건강한지 확인하세요:
```
kubectl get pods -n "$OPERATOR_NAMESPACE"
```
운영자 로그를 확인하세요:
```
kubectl logs deploy/<OPERATOR_DEPLOYMENT_NAME> -n "$OPERATOR_NAMESPACE"
```
Note
다중 복제 배포의 경우, 하나의 운영자 인스턴스만이 조정 루프를 실행하고 있습니다. 이 운영자를 리더라고 하며 조정 로그를 생성하는 유일한 인스턴스입니다. 다른 운영자 인스턴스는 다음 로그와 함께 대기하고 있습니다:
leaderelection.go:248] attempting to acquire leader lease teleport/431e83f4.teleport.dev...
조정 문제를 진단하려면 모든 포드를 검사하여 리소스를 조정하는 포드를 찾아야 합니다.

Kubernetes CR을 삭제할 수 없습니다

운영자는 최종기로 인해 Kubernetes CR의 삭제를 보호합니다. Teleport 리소스가 삭제될 때까지 CR이 삭제되지 않도록 합니다. 이는 부유 리소스를 남기고 의도치 않은 접근을 부여하는 것을 방지하기 위한 안전 장치입니다.

Teleport가 리소스 삭제를 거부하는 이유는 여러 가지가 있을 수 있으며, 가장 흔한 이유는 다른 리소스가 그것에 의존할 때입니다. 예를 들어, 사용자가 여전히 할당되어 있는 경우 역할을 삭제할 수 없습니다. 이 경우, 운영자는 Teleport에 의해 전송된 오류를 로그에 기록합니다.

이 잠금을 해결하려면 다음 중 하나를 수행할 수 있습니다:

Teleport에서 리소스가 성공적으로 삭제되도록 의존성 문제를 해결합니다.
역할 예시에서는 해당 역할을 가진 사용자의 다양한 기록에서 역할 언급을 제거해야 합니다.
최종기를 제거하도록 Kubernetes CR을 패치합니다.
이렇게 하면 Kubernetes가 운영자 삭제를 기다리지 않고 CR을 제거하게 됩니다.
이를 수행하면 CR은 제거되지만 Teleport 리소스는 남아 있게 됩니다.
운영자는 다시 삭제를 시도하지 않습니다.

예를 들어, 역할 이름이 my-role인 경우:

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

Teleport 원문 보기