Teleport의 워크로드 아이덴티티는 워크로드를 위한 유연한 단기 아이덴티티를 발급합니다. 업계 표준 SPIFFE 사양과 호환되므로 다른 SPIFFE 호환 아이덴티티 공급자 대신 사용할 수 있습니다.

이 가이드에서는 Bot이 워크로드 아이덴티티 자격 증명을 발급할 수 있도록 필요한 RBAC를 구성한 다음, SPIFFE Workload API 엔드포인트를 노출하도록 tbot을 구성합니다. 그런 다음 워크로드를 이 엔드포인트에 연결하여 SPIFFE SVID 호환 워크로드 아이덴티티 자격 증명을 받을 수 있습니다.

사전 요구 사항#

• 실행 중인 Teleport 클러스터. Teleport를 시작하려면 무료 체험판에 가입하거나 데모 환경을 구성하세요.

• tctl and tsh clients.

  Installing `tctl` and `tsh` clients

  1. Teleport 클러스터의 버전을 확인합니다. tctl and tsh clients는 Teleport 클러스터 버전보다 최대 한 개의 메이저 버전까지만 뒤처질 수 있습니다. Proxy Service의 /v1/webapi/find로 GET 요청을 보내고 JSON 쿼리 도구를 사용하여 클러스터 버전을 확인합니다. teleport.example.com:443를 Teleport Proxy Service의 웹 주소로 바꿉니다:

     $ TELEPORT_DOMAIN=teleport.example.com:443
     $ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"
     

  2. 사용 중인 플랫폼에 대한 지침에 따라 tctl and tsh clients를 설치합니다:

Mac

     `tctl` and `tsh` clients가 포함된, 서명된 Teleport macOS .pkg 설치 프로그램을 다운로드합니다:
 
     ```code
     $ curl -O https://cdn.teleport.dev/teleport-${TELEPORT_VERSION?}.pkg
     ```

     Finder에서 `pkg` 파일을 더블 클릭하여 설치를 시작합니다.
 
     

       Homebrew를 사용하여 Teleport를 설치하는 것은 지원되지 않습니다. Homebrew의
       Teleport 패키지는 Teleport에서 유지 관리하지 않으므로 신뢰성이나 보안을
       보장할 수 없습니다.
     

Windows - Powershell

     ```code
     $ curl.exe -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-windows-amd64-bin.zip
     # Unzip the archive and move the `tctl` and `tsh` clients to your %PATH%
     # NOTE: Do not place the `tctl` and `tsh` clients in the System32 directory, as this can cause issues when using WinSCP.
     # Use %SystemRoot% (C:\Windows) or %USERPROFILE% (C:\Users\<username>) instead.
     ```
 
   

 
   

Linux

     Linux 설치판의 모든 Teleport 바이너리에는 `tctl` and `tsh` clients가 포함되어 있습니다.  RPM/DEB
     패키지 및 i386/ARM/ARM64용 다운로드를 포함한 더 많은 옵션은
     [설치 페이지](../installation/installation.mdx)를 참조하세요.
 
     ```code
     $ curl -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
     $ tar -xzf teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
     $ cd teleport
     $ sudo ./install
     # Teleport binaries have been copied to /usr/local/bin
     ```
   

 

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 명령을 실행할 수도 있습니다.

• 워크로드 아이덴티티에 접근해야 하는 워크로드가 실행되는 호스트에 tbot이 이미 설치되고 구성되어 있어야 합니다. 자세한 내용은 배포 가이드를 참조하세요.

1/3단계. 워크로드 아이덴티티 구성#

먼저 워크로드 아이덴티티 리소스를 생성해야 합니다.

이 리소스는 Teleport 워크로드 아이덴티티를 구성하는 주요 방법입니다. 각 워크로드 아이덴티티 리소스는 특정 워크로드에 대한 아이덴티티의 구성 또는 워크로드 그룹의 아이덴티티를 나타낼 때 사용되는 템플릿을 나타냅니다. 워크로드 아이덴티티 리소스는 다음과 같은 여러 주요 항목을 지정합니다:

• 워크로드 아이덴티티의 이름으로, 이를 발급할 때 필요합니다.
• 이 WorkloadIdentity에 대해 발급되는 자격 증명에 포함될 SPIFFE ID.
• 이 워크로드 아이덴티티를 사용하여 자격 증명을 발급할 수 있는 시점에 관한 규칙.

계속하기 전에 워크로드가 사용할 SPIFFE ID 경로를 결정해야 합니다. 예시에서는 /svc/foo를 사용합니다. SPIFFE ID 구조를 선택하는 방법에 대한 자세한 안내는 모범 사례 가이드를 참조하세요.

workload-identity.yaml이라는 새 파일을 생성합니다:

kind: workload_identity
version: v1
metadata:
  name: example-workload-identity
  labels:
    example: getting-started
spec:
  spiffe:
    id: /svc/foo

다음을 교체하세요:

• example-workload-identity를 사용 사례를 설명하는 이름으로 교체합니다.
• /svc/foo를 발급하기로 결정한 SPIFFE ID 경로로 교체합니다.

tctl create -f ./workload-identity.yaml을 사용하여 워크로드 아이덴티티를 생성합니다.

이제 방금 생성한 워크로드 아이덴티티에 대한 접근 권한을 부여할 역할을 생성해야 합니다. 다른 Teleport 리소스와 마찬가지로, 접근 권한은 리소스 자체의 라벨과 일치하는 라벨 매처를 역할에 지정하여 부여됩니다.

리소스에 대한 접근 권한을 부여하는 것 외에도, 워크로드 아이덴티티 리소스 타입을 읽고 목록화할 수 있는 권한도 부여해야 합니다.

workload-identity-issuer-role.yaml을 생성합니다:

kind: role
version: v6
metadata:
  name: example-workload-identity-issuer
spec:
  allow:
    workload_identity_labels:
      example: ["getting-started"]
    rules:
    - resources:
      - workload_identity
      verbs:
      - list
      - read

tctl create -f ./workload-identity-issuer-role.yaml을 사용하여 역할을 생성합니다.

이제 tctl bots update를 사용하여 Bot에 역할을 추가합니다. example-bot은 배포 가이드에서 생성한 Bot의 이름으로, example-workload-identity-issuer는 방금 생성한 역할의 이름으로 교체하세요:

$ tctl bots update example-bot --add-roles example-workload-identity-issuer

DNS SAN 구성#

경우에 따라 Workload API에서 발급하는 X509 인증서에 포함할 DNS SAN을 구성하고자 할 수 있습니다. 이는 클라이언트가 SPIFFE를 인식하지 못하고 TLS 핸드셰이크 중에 SPIFFE URI 대신 DNS SAN을 확인하는 경우에 유용합니다.

workload-identity.yaml 리소스 정의를 수정하여 spec.spiffe.x509.dns_sans 필드를 포함시키고, example.com을 필요한 DNS 이름으로 교체하세요:

kind: workload_identity
version: v1
metadata:
  name: example-workload-identity
  labels:
    example: getting-started
spec:
  spiffe:
    id: /svc/foo
    x509:
      dns_sans:
      - example.com

tctl create -f ./workload-identity.yaml을 사용하여 변경 사항으로 WorkloadIdentity 리소스를 업데이트합니다.

2/3단계. tbot에서 workload-identity-api 서비스 구성#

tbot으로 SPIFFE Workload API 엔드포인트를 설정하려면 workload-identity-api 서비스의 인스턴스를 구성합니다.

먼저, 이 소켓을 생성할 위치를 결정하세요. 예시에서는 /opt/machine-id/workload.sock을 사용합니다. Workload API에 연결해야 하는 프로세스만 접근할 수 있는 디렉터리를 선택하는 것이 좋습니다.

tbot 구성 파일을 수정하여 workload-identity-api 서비스를 포함시킵니다:

services:
- type: workload-identity-api
  listen: unix:///opt/machine-id/workload.sock
  selector:
    name: example-workload-identity

다음을 교체하세요:

• /opt/machine-id/workload.sock을 생성하려는 소켓의 경로로 교체합니다.
• example-workload-identity를 이전에 생성한 워크로드 아이덴티티 리소스의 이름으로 교체합니다.

새 구성을 적용합니다. tbot이 이미 실행 중이라면 구성을 다시 로드하세요:

$ sudo systemctl reload tbot

그렇지 않다면, 이 예시에서 /etc/tbot.yaml이라고 가정하는 구성 파일로 tbot을 시작하세요:

$ sudo tbot start -c /etc/tbot.yaml

Unix 워크로드 어테스테이션 구성#

기본적으로 Workload API 서비스 아래에 나열된 SVID는 Workload API에 연결하는 모든 워크로드에 발급됩니다. 워크로드의 특정 특성을 기반으로 어떤 SVID를 발급할지 제한하고 싶을 수 있습니다. 이를 워크로드 어테스테이션(Workload Attestation)이라고 합니다.

Unix 리스너를 사용할 때, tbot은 워크로드 프로세스의 세 가지 특성을 기반으로 하는 워크로드 어테스테이션을 지원합니다:

• uid: 워크로드 프로세스가 실행 중인 사용자의 UID.
• gid: 워크로드 프로세스가 실행 중인 사용자의 기본 GID.
• pid: 워크로드 프로세스의 PID.

워크로드 아이덴티티 내에서 워크로드 어테스테이션을 통해 확인된 속성을 기반으로 규칙을 구성할 수 있습니다. 각 규칙에는 여러 테스트가 포함되며, 규칙이 통과하려면 모든 테스트가 통과해야 합니다. 워크로드 아이덴티티가 자격 증명을 발급할 수 있으려면 최소한 하나의 규칙이 통과해야 합니다.

예를 들어, ID가 1000인 사용자로 실행 중이거나 기본 그룹 ID가 50인 사용자로 실행 중인 워크로드에만 워크로드 아이덴티티가 발급되도록 구성하려면:

kind: workload_identity
version: v1
metadata:
  name: example-workload-identity
  labels:
    example: getting-started
spec:
  rules:
    allow:
    - conditions:
      - attribute: workload.unix.uid
        eq:
          value: 1000
    - conditions:
      - attribute: workload.unix.gid
        eq:
          value: 50
  spiffe:
    id: /svc/foo

3/3단계. tbot spiffe-inspect로 Workload API 테스트#

tbot 바이너리에는 Workload API의 구성을 테스트하는 데 사용할 수 있는 spiffe-inspect 명령어가 포함되어 있습니다. 이 명령어는 Workload API에 연결하여 SVID를 요청하는 동시에 디버그 정보를 제공합니다.

워크로드가 Workload API를 사용하도록 구성하기 전에, 이 명령어를 사용하여 Workload API가 예상대로 동작하는지 확인하는 것이 좋습니다.

--path와 함께 spiffe-inspect 명령어를 사용하여 Workload API 소켓의 경로를 지정하세요. /opt/machine-id/workload.sock을 이전 단계에서 구성한 경로로 교체하세요:

$ tbot spiffe-inspect --path unix:///opt/machine-id/workload.sock
INFO [TBOT]      Inspecting SPIFFE Workload API Endpoint unix:///opt/machine-id/workload.sock tbot/spiffe.go:31
INFO [TBOT]      Received X.509 SVID context from Workload API bundles_count:1 svids_count:1 tbot/spiffe.go:46
SVIDS
- spiffe://example.teleport.sh/svc/foo
  - Expiry: 2024-03-20 10:55:52 +0000 UTC
Trust Bundles
- example.teleport.sh

다음 단계: 워크로드가 Workload API를 사용하도록 구성#

Workload API가 예상대로 동작하는 것을 확인했으니, 이제 워크로드가 이를 사용하도록 구성할 수 있습니다. 정확한 단계는 워크로드에 따라 다릅니다.

SPIFFE SDK를 사용한 경우, SPIFFE_ENDPOINT_SOCKET 환경 변수를 tbot이 생성한 소켓을 가리키도록 구성할 수 있습니다.

워크로드에 SPIFFE를 통합하는 방법에 대한 자세한 내용은 모범 사례 가이드를 참조하세요.

추가 자료#

• 워크로드 아이덴티티 개요: Teleport 워크로드 아이덴티티에 대한 개요입니다.
• 모범 사례: 프로덕션에서 워크로드 아이덴티티를 사용하기 위한 모범 사례입니다.
• 워크로드 아이덴티티 리소스의 구성을 살펴보려면 워크로드 아이덴티티 참조를 읽어보세요.
• tbot에 사용 가능한 모든 구성 옵션을 살펴보려면 구성 참조를 읽어보세요.