인포레터에서 최신 DevOps 트렌드를 격주로 만나보세요!
워크로드 아이덴티티 시작하기
디자인 파트너십
우리는 Teleport Workload Identity의 미래를 함께 만들어 나갈 디자인 파트너를 적극적으로 찾고 있으며, 귀하의 피드백을 듣고 싶습니다.
Teleport의 워크로드 아이덴티티는 워크로드를 위한 유연한 단기 아이덴티티를 발급합니다. 이는 업계 표준인 SPIFFE 사양과 호환되므로 다른 SPIFFE 호환 아이덴티티 제공자의 대체로 사용할 수 있습니다.
이 가이드에서는 Bot이 SPIFFE SVID를 발급할 수 있도록 필요한 RBAC를 구성한 다음, tbot
을 구성하여 SPIFFE 워크로드 API 엔드포인트를 노출하는 방법을 설명합니다. 그런 다음 이 엔드포인트에 워크로드를 연결하여 SPIFFE SVID를 수신할 수 있습니다.
전제 조건
-
실행 중인 Teleport 클러스터 버전 17.0.0-dev 이상. Teleport를 시작하려면 가입하여 무료 평가판을 이용하거나 데모 환경 설정 방법을 확인하십시오.
-
tctl
관리자 도구와tsh
클라이언트 도구.tctl
및tsh
다운로드 방법에 대한 지침은 설치를 방문하십시오.
- 연결이 가능한지 확인하기 위해
tsh login
으로 로그인한 다음, 현재 자격 증명을 사용하여tctl
명령어를 실행할 수 있는지 확인하십시오. 예를 들어:클러스터에 연결할 수 있고tsh login --proxy=teleport.example.com --user=email@example.comtctl status클러스터 teleport.example.com
버전 17.0.0-dev
CA 핀 sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
tctl status
명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 후속tctl
명령어를 실행할 수 있습니다.
자신의 Teleport 클러스터를 호스팅하는 경우, Teleport Auth Service를 호스팅하는 컴퓨터에서 전체 권한으로tctl
명령어를 실행할 수도 있습니다. tbot
은 Teleport 워크로드 아이덴티티에 접근해야 할 워크로드가 실행될 호스트에 이미 설치되고 구성되어 있어야 합니다. 자세한 내용은 배포 가이드를 참조하세요.
1/4단계. RBAC 구성하기
먼저, Teleport는 Bot이 SPIFFE SVID를 발급할 수 있도록 구성되어야 합니다. 이는 SPIFFE SVID의 발급을 허용하는 역할을 구성하고 이를 Bot에 부여하여 수행합니다.
진행하기 전에, 워크로드가 사용할 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
를 사용하여 Bot에 역할을 추가합니다. example-bot
을 배포 가이드에서 만든 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 구성
경우에 따라 Workload API에서 발급된 SVID에 포함될 DNS 및 IP SAN을 구성할 수 있습니다. 클라이언트가 SPIFFE를 인식하지 못하고 TLS 핸드셰이크 중 SPIFFE URI 대신 DNS SAN을 확인하는 경우 유용합니다.
다음은 sans
구성 블록을 사용하여 spiffe-workload-api
서비스에서 이들을 구성하는 방법입니다:
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를 요청할 수 있도록 Bot에 명시적으로 권한을 부여하기 위해 역할을 수정해야 합니다. 예를 들면:
kind: role
version: v6
metadata:
name: spiffe-issuer
spec:
allow:
spiffe:
- path: "/svc/foo"
# Bot이 SVID에 포함할 수 있게 하려는 DNS SAN으로 교체하십시오.
dns_sans: ["example.com"]
# Bot이 SVID에 포함할 수 있게 하려는 IP SAN으로 교체하십시오.
# IP SAN을 포함하고 싶지 않다면 이 부분을 제거할 수 있습니다.
# IP는 CIDR 표기법을 사용하여 지정해야 하며,
# 단일 IP 또는 IP 범위를 지정할 수 있습니다.
ip_sans: ["10.0.0.1/32"]
Unix Workload 증명 구성
기본적으로 Workload API 서비스에 나열된 SVID는 Workload API에 연결하는 모든 워크로드에 발급됩니다. 특정 워크로드의 특성에 따라 발급되는 SVID를 제한할 수 있습니다. 이를 Workload 증명이라고 합니다.
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
를 사용하여 Workload API 테스트
tbot
바이너리에는 Workload API의 구성을 테스트하는 데 사용할 수 있는 spiffe-inspect
명령이 포함되어 있습니다. 이 명령은 Workload API에 연결하고 SVID를 요청하며 디버그 정보를 제공합니다.
Workload API를 사용하도록 워크로드를 구성하기 전에 이 명령을 사용하여 Workload API가 예상대로 작동하는지 확인하는 것이 좋습니다.
다음 단계에서 구성한 경로(/opt/machine-id/workload.sock
)를 대체하여 --path
와 함께 spiffe-inspect
명령을 사용하십시오:
tbot spiffe-inspect --path unix:///opt/machine-id/workload.sockINFO [TBOT] SPIFFE Workload API 엔드포인트 unix:///opt/machine-id/workload.sock 검토 중 tbot/spiffe.go:31INFO [TBOT] Workload API로부터 X.509 SVID 컨텍스트 수신 bundles_count:1 svids_count:1 tbot/spiffe.go:46SVIDS- spiffe://example.teleport.sh/svc/foo - Hint: my-hint - 만료: 2024-03-20 10:55:52 +0000 UTC신뢰 번들- example.teleport.sh
4/4단계. Workload API를 사용하도록 작업 로드를 구성하기
이제 Workload API가 예상대로 작동하고 있다는 것을 알았으므로, 이를 사용하도록 작업 로드를 구성할 수 있습니다. 정확한 단계는 작업 로드에 따라 달라집니다.
SPIFFE SDK를 사용한 경우, SPIFFE_ENDPOINT_SOCKET
환경 변수를 tbot
이 생성한 소켓을 가리키도록 구성할 수 있습니다.
SPIFFE를 작업 로드와 통합하는 방법에 대한 자세한 내용은 모범 사례 가이드를 참조하십시오.
다음 단계
- 작업 로드 신원 개요: Teleport 작업 로드 신원 개요입니다.
- 모범 사례: 프로덕션에서 작업 로드 신원을 사용하는 모범 사례입니다.
- 사용 가능한 모든 구성 옵션을 탐색하려면 구성 참조를 참조하십시오.