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

작동 방식#

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

사전 요구 사항#

• 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:

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.

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

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

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

이 리소스는 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을 확인하는 경우에 유용합니다.

필요한 DNS 이름으로 example.com을 교체하여 spec.spiffe.x509.dns_sans 필드를 포함하도록 workload-identity.yaml 리소스 정의를 수정합니다:

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/4단계. tbot에서 workload-identity-api 서비스 구성#

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

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

workload-identity-api 서비스를 포함하도록 tbot 구성 파일을 수정합니다:

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 인스턴스를 시작하거나 재시작합니다.

Unix Workload 어테스테이션 구성#

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

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/4단계. tbot spiffe-inspect로 Workload API 테스트#

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

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

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

$ 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

4/4단계. Workload API를 사용하도록 워크로드 구성#

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

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

워크로드와 SPIFFE 통합에 대한 자세한 정보는 모범 사례 가이드를 참조하세요.

다음 단계#

• 워크로드 아이덴티티 개요: Teleport 워크로드 아이덴티티 개요.
• 모범 사례: 프로덕션에서 워크로드 아이덴티티 사용에 대한 모범 사례.
• 워크로드 아이덴티티 참조를 읽어 워크로드 아이덴티티 리소스의 구성을 탐색하세요.
• 구성 참조를 읽어 tbot에 대한 모든 사용 가능한 구성 옵션을 탐색하세요.