Teleport의 워크로드 아이덴티티는 워크로드를 위해 설계된 유연한 단기 아이덴티티를 제공합니다. 이는 산업 표준 SPIFFE 사양과 호환되며, SPIFFE 호환 아이덴티티 제공자의 대체로 사용될 수 있습니다.

이 가이드에서는 봇이 SPIFFE SVID를 발급할 수 있도록 필요한 RBAC를 구성한 다음, tbot을 구성하여 SPIFFE 워크로드 API 엔드포인트를 노출합니다. 그런 다음 이 엔드포인트에 귀하의 워크로드를 연결하여 SPIFFE SVID를 받을 수 있습니다.

사전 요구 사항

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

• tctl 관리 도구와 tsh 클라이언트 도구.

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

• 당신의 Teleport 클러스터에 연결할 수 있는지 확인하려면, tsh login으로 로그인한 다음 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어:

  tsh login --proxy=teleport.example.com --user=email@example.com
  tctl status
  클러스터  teleport.example.com
  버전  16.2.0
  CA 핀   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678

  클러스터에 연결하고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 작업대에서 후속 tctl 명령어를 실행할 수 있습니다. 자신의 Teleport 클러스터를 호스팅하는 경우, Teleport 인증 서비스를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.
• tbot은 워크로드 아이덴티티에 액세스해야 하는 작업이 실행될 호스트에 이미 설치되고 구성되어 있어야 합니다. 자세한 내용은 배포 가이드를 참조하세요.

1단계/4단계. RBAC 구성

먼저 Teleport는 봇이 SPIFFE SVID를 발급할 수 있도록 구성해야 합니다. 이는 SPIFFE SVID의 발급을 허용하는 역할을 구성한 다음 이 역할을 봇에 부여하여 수행됩니다.

진행하기 전에 워크로드가 사용할 SPIFFE ID 경로를 결정해야 합니다. 예를 들어, /svc/foo를 사용할 것입니다. SPIFFE ID 구조 선택에 대한 추가 지침은 모범 사례 가이드에서 제공합니다.

spiffe-issuer-role.yaml이라는 새 파일을 만듭니다:

kind: role
version: v6
metadata:
  name: spiffe-issuer
spec:
  allow:
    spiffe:
    - path: "/svc/foo"

다음으로 교체하세요:

• spiffe-issuer를 귀하의 사용 사례를 설명하는 이름으로 변경합니다.
• /svc/foo를 발급하기로 결정한 SPIFFE ID 경로로 변경합니다.

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

이제 tctl bots update를 사용하여 봇에 역할을 추가합니다. example-bot을 배포 가이드에서 생성한 봇의 이름으로, spiffe-issuer를 방금 생성한 역할의 이름으로 변경합니다:

$ tctl bots update example-bot --add-roles spiffe-issuer

2단계/4단계. tbot에서 spiffe-workload-api 서비스 구성

tbot과 함께 SPIFFE 워크로드 API 엔드포인트를 설정하려면 spiffe-workload-api 서비스의 인스턴스를 구성합니다.

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

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

services:
- type: spiffe-workload-api
  listen: unix:///opt/machine-id/workload.sock
  svids:
  - path: /svc/foo
    hint: my-hint

다음으로 교체하세요:

• /opt/machine-id/workload.sock을 생성하려는 소켓의 경로로 변경합니다.
• /svc/foo를 발급하기로 결정한 SPIFFE ID 경로로 변경합니다.
• my-hint를 SVID에 포함될 힌트로 변경합니다. 이는 워크로드가 여러 SVID를 제시할 경우 선택해야 하는 SVID를 식별하는 데 도움이 될 수 있습니다. 필요하지 않은 경우 이 필드는 생략할 수 있습니다.

새 구성을 적용하기 위해 tbot 인스턴스를 시작하거나 재시작합니다.

DNS 및 IP SAN 구성

어떤 경우에는 DNS 및 IP SAN을 구성하여 워크로드 API에서 발급된 SVID에 포함되도록 할 수 있습니다. 이는 클라이언트가 SPIFFE를 인식하지 않으며 TLS 핸드쉐이크 동안 SPIFFE URI 대신 DNS SAN을 확인할 수 있는 경우에 유용합니다.

이는 spiffe-workload-api 서비스에서 sans 구성 블록을 사용하여 구성할 수 있습니다:

services:
- type: spiffe-workload-api
  listen: unix:///opt/machine-id/workload.sock
  svids:
  - path: /svc/foo
    hint: my-hint
    sans:
      dns:
      - example.com
      ip:
      - 10.0.0.1

또한 역할을 수정하여 봇이 DNS 또는 IP SAN이 포함된 SVID를 요청할 수 있도록 명시적으로 허용해야 합니다. 예를 들어:

kind: role
version: v6
metadata:
  name: spiffe-issuer
spec:
  allow:
    spiffe:
    - path: "/svc/foo"
      # 봇이 SVID에 포함할 DNS SAN을 교체하세요.
      dns_sans: ["example.com"]
      # 봇이 SVID에 포함할 IP SAN을 교체하세요. IP SAN을 포함하고 싶지 않으면 이 구성을 삭제할 수 있습니다.
      # IP는 CIDR 표기법을 사용하여 지정해야 하며, 단일 IP 또는 IP 범위를 지정할 수 있습니다.
      ip_sans: ["10.0.0.1/32"]

Unix 워크로드 인증 구성

기본적으로 워크로드 API 서비스에 나열된 SVID는 워크로드 API에 연결하는 모든 워크로드에 발급됩니다. 특정 특성에 따라 발급되는 SVID를 제한하려면 워크로드 인증을 사용할 수 있습니다.

Unix 리스너를 사용할 때 tbot은 워크로드 프로세스의 세 가지 특성에 따라 워크로드 인증을 지원합니다:

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

워크로드 인증을 구성하기 위해 각 SVID에 대한 규칙 집합을 구성합니다. 각 규칙은 특성 목록이며, 규칙을 통과하려면 규칙 내의 모든 특성이 일치해야 합니다. 여러 규칙이 있을 경우, SVID가 발급되기 위해서는 하나의 규칙만 통과하면 됩니다.

예를 들어, ID가 1000인 사용자로 실행되거나 기본 그룹 ID가 50인 사용자로 실행되는 워크로드에만 SVID가 발급되도록 구성합니다:

services:
- type: spiffe-workload-api
  listen: unix:///opt/machine-id/workload.sock
  svids:
  - path: /svc/foo
    hint: my-hint
    rules:
      - uid: 1000
      - gid: 50

3단계/4단계. tbot spiffe-inspect로 워크로드 API 테스트

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

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

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

$ tbot spiffe-inspect --path unix:///opt/machine-id/workload.sock
INFO [TBOT]      SPIFFE 워크로드 API 엔드포인트 검사 중 unix:///opt/machine-id/workload.sock tbot/spiffe.go:31
INFO [TBOT]      Workload API에서 수신된 X.509 SVID 컨텍스트 bundles_count:1 svids_count:1 tbot/spiffe.go:46
SVIDS
- spiffe://example.teleport.sh/svc/foo
  - 힌트: my-hint
  - 만료: 2024-03-20 10:55:52 +0000 UTC
신뢰 번들
- example.teleport.sh

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

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

SPIFFE SDK를 사용한 경우 SPIFFE_ENDPOINT_SOCKET 환경 변수를 tbot에 의해 생성된 소켓을 가리키도록 설정할 수 있습니다.

SPIFFE를 귀하의 워크로드와 통합하는 방법에 대한 더 많은 정보는 모범 사례 가이드를 참조하세요.

다음 단계

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