이 섹션에서는 Teleport의 동적 리소스를 관리하는 방법을 설명합니다. 이는 인프라가 변경됨에 따라 Teleport 클러스터의 동작을 조정할 수 있게 해줍니다. 동적 리소스의 디자인은 Terraform, Helm 및 Teleport의 tctl 클라이언트 도구와 같은 인프라스트럭처 코드 도구를 사용하여 관리할 수 있게 합니다.

동적 리소스란 무엇입니까?

Teleport 클러스터를 구성하는 방법은 두 가지가 있습니다:

• 정적 구성 파일: 시작 시, Teleport 프로세스는 로컬 파일 시스템에서 구성 파일을 읽습니다 (기본 경로는 /etc/teleport.yaml 입니다). 정적 구성 설정은 서비스가 수신 대기하는 포트와 같이 자주 변경되지 않을 것으로 예상되는 클러스터의 측면을 제어합니다.
• 동적 리소스: 동적 리소스는 역할, 로컬 사용자 및 등록된 인프라 리소스와 같이 시간이 지남에 따라 변경될 가능성이 있는 클러스터의 측면을 제어합니다.

이 접근 방식은 Teleport 인스턴스를 다시 시작하지 않고도 Teleport 구성을 점진적으로 조정할 수 있게 합니다.

클러스터는 다양한 객체(즉, 리소스)로 구성되어 있으며, 이들에 대해 수행할 수 있는 세 가지 일반적인 작업이 있습니다: get , create , 및 remove .

Teleport의 모든 리소스는 세 가지 필수 필드를 가집니다:

• kind : 리소스의 유형
• name : 리소스를 고유하게 식별하기 위해 필요한 metadata 필드
• version : 리소스 형식의 버전

모든 다른 필드는 리소스에 특정적입니다.

Teleport Enterprise Cloud는 운영자에게 정적 구성 파일을 노출하지 않지만, 특정 설정에 대해 정적 구성 파일을 사용합니다. 정적 구성 설정의 값을 동적 리소스에서 어떻게 확인하는지 이해하려면 Teleport가 정적 및 동적 리소스를 조정하는 방법을 읽어보십시오.

동적 리소스를 검토할 때, 볼 수 있는 필드 중 일부는 내부적으로만 사용되며 변경할 수 없는 필드임을 유의하십시오. 다른 필드는 미래 사용을 위해 예약되어 있습니다.

동적 리소스 관리

Teleport는 동적 리소스를 적용하는 세 가지 방법을 제공합니다: tctl 클라이언트 도구, Teleport Terraform 공급자 및 Kubernetes Operator.

이 세 가지 방법 모두는 Auth 서비스 백엔드에 저장된 클러스터 리소스를 조작하기 위해 Teleport Auth 서비스의 gRPC 엔드포인트에 연결합니다. Teleport의 구성 인터페이스 설계는 인프라스트럭처 코드 및 GitOps 접근 방식을 잘 지원합니다.

다음과 같이 tctl , Terraform Provider 및 Kubernetes Operator를 시작할 수 있습니다:

• "IaC로 사용자 및 역할 관리" 가이드
• "IaC로 접근 목록 만들기" 가이드
• "IaC로 에이전트 없는 OpenSSH 서버 등록" 가이드

internal.logins 특성을 포함한 Teleport 역할에 대한 자세한 내용은 Teleport 접근 제어 참조를 참조하십시오.

tctl 로 YAML 문서

리소스를 YAML 문서로 정의하고 tctl 클라이언트 도구를 사용하여 이를 적용할 수 있습니다. env:test 레이블이 있는 서버에 대한 접근을 허용하는 role 리소스의 예는 다음과 같습니다:

kind: role
version: v7
metadata:
  name: developer
spec:
  allow:
    logins: ["ubuntu", "debian", "{{internal.logins}}"]
    node_labels:
      "env": "test"

tctl 은 로컬 파일 시스템에서 작동하므로, 디렉터리 트리의 모든 구성 문서를 적용하는 명령을 작성할 수 있습니다. tctl 에 대한 더 많은 정보는 CLI 참조를 참조하십시오.

Teleport Terraform provider

Teleport의 Terraform 공급자는 나머지 인프라와 동일한 코드 소스 내에서 Teleport 리소스를 관리할 수 있도록 해줍니다. 각 Teleport 구성 리소스에 대한 Terraform 리소스가 있습니다. 예를 들어:

resource "teleport_role" "developer" {
  version = "v7"
  metadata = {
    name = "developer"
  }

  spec = {
    allow = {
      logins = ["ubuntu", "debian", "{{internal.logins}}"]

      node_labels = {
        key   = ["env"]
        value = ["test"]
      }
    }
  }
}

Terraform 공급자로 시작하기.

Teleport Kubernetes Operator

Teleport Kubernetes Operator는 Teleport 리소스를 Kubernetes 리소스로 적용할 수 있게 해주어 Kubernetes 인프라의 나머지 부분과 함께 Teleport 설정을 관리할 수 있도록 합니다. 다음은 위에서 보여준 두 개의 역할과 동등한 TeleportRoleV7 리소스의 예입니다:

apiVersion: resources.teleport.dev/v1
kind: TeleportRoleV7
metadata:
  name: developer
spec:
  allow:
    logins: ["ubuntu", "debian", "{{internal.logins}}"]
    node_labels:
      "env": "test"

쿠버네티스 연산자로 시작하기.

동적 리소스와 구성 파일 조정

일부 동적 리소스는 Teleport의 정적 구성 파일 내의 필드와 동일한 설정을 할당합니다. 이러한 필드에 대해 Teleport Auth 서비스는 시작 시 및 Teleport 리소스를 생성하거나 제거할 때 정적 및 동적 구성을 조정합니다.

정적 구성 필드에 적용되는 구성 리소스

정적 구성 파일과 필드를 공유하는 네 개의 동적 리소스가 있습니다:

• session_recording_config
• cluster_auth_preference
• cluster_networking_config
• ui_config

session_recording_config

cluster_auth_preference

cluster_networking_config

ui_config

기원 레이블

Teleport Auth Service는 구성 리소스에 teleport.dev/origin 레이블을 적용하여 이는 정적 구성 파일, 동적 구성 리소스 또는 기본 값에서 유래했는지 여부를 나타냅니다.

teleport.dev/origin 레이블의 가능한 값은 다음과 같습니다:

• defaults
• config-file
• dynamic
• terraform
• kubernetes

Auth Service가 시작될 때, 동적 구성 리소스의 필드에 해당하는 정적 구성 필드의 값을 조회합니다. 이러한 값이 존재하는 경우, 해당 동적 구성 리소스를 생성하고 백엔드에 저장합니다.

값이 없는 정적 구성 필드에 대해 Auth Service는 백엔드에 해당 동적 구성 리소스가 존재하는지 확인합니다. 존재하지 않는 경우, 기본 값과 teleport.dev/origin=defaults 레이블로 하나를 생성합니다.

Auth Service가 이미 정적 구성 파일에서 구성을 로드한 후 동적 구성 리소스를 생성하려고 시도하면 Auth Service는 오류를 반환합니다.

동적 구성 리소스를 제거하면, Auth Service는 구성을 기본 값으로 복원하고 teleport.dev/origin=defaults 레이블을 추가합니다.

추가 자료

구성 참조

• Teleport의 정적 구성 옵션에 대한 포괄적인 참조는 구성 참조를 읽어보세요.
• 적용 가능한 동적 구성 리소스를 보려면 구성 리소스 참조를 읽어보세요. 애플리케이션 및 데이터베이스에 대한 전용 구성 리소스 참조도 있습니다.

Teleport API 사용의 다른 방법

Teleport Kubernetes Operator, Terraform 제공자 및 tctl 은 모두 Teleport Auth Service의 gRPC API 클라이언트입니다. 조직의 필요에 맞게 Teleport를 확장하기 위해 자체 API 클라이언트를 구축하려면 API 가이드를 읽어보세요.