Teleport Workload Identity 모범 사례

프로덕션에서 Teleport Workload Identity 사용에 대한 일반적인 질문에 답하고 모범 사례를 설명합니다.

이 페이지는 프로덕션에서 Teleport의 Workload Identity 기능 사용에 대한 일반적인 질문과 모범 사례를 다룹니다. SPIFFE ID 구조화 # SPIFFE ID는 워크로드, 그리고 잠재적으로 사용자에 대한 유연한 식별자입니다. SPIFFE ID 네임스페이스 구조는 궁극적으로 조직이 결정합니다. SPIFFE ID 구조화에는 몇 가지 일반적인 전략이 있습니다. 그러나 일반적으로 계층적 구조가 사용되며, 계층의 루트가 가장 일반적이고 가장 깊은 부분이 가장 구체적입니다. 이를 통해 계층의 공통 부분을 공유하는 워크로드 그룹에 대한 접근 권한을 부여하는 규칙을 만들 수 있습니다. 논리적 구조 # 한 가지 전략은 워크로드의 논리적 기능에 따라 SPIFFE ID를 구조화하는 것입니다. 예를 들어 payments 서비스 그룹 내에 속하는 processor 라는 서비스가 있을 수 있습니다. 이 서비스에 spiffe://example.teleport.sh/production/payments/processor 라는 SPIFFE ID를 부여할 수 있습니다. 그런 다음 모든 payments 서비스가 서로 접근할 수 있어야 한다고 결정하고 spiffe://example.teleport.sh/production/payments 로 시작하는 모든 SPIFFE ID에 대한 접근 권한을 부여하는 규칙을 만들 수 있습니다. 물리적 구조 # 또 다른 전략은 워크로드의 보다 "물리적" 위치를 사용하여 SPIFFE ID를 구조화하는 것입니다. 이것은 "가상"적인 요소를 여전히 포함할 수 있습니다. 예를 들어 런던의 데이터센터에 있는 호스트의 VM에서 실행되는 워크로드가 있을 수 있습니다. 이 워크로드에 spiffe://example.teleport.sh/europe/uk/london/hypervisor-001/vm-a3847f 라는 SPIFFE ID를 부여할 수 있습니다. 이는 논리적 구조와 다른 방식으로 유용합니다. 워크로드가 물리적으로 근접한 다른 워크로드에만 접근할 수 있도록 제한하고 싶은 경우 이상적입니다(예: 캐시). 런던에 위치한 캐시는 spiffe://example.teleport.sh/europe/uk 로 시작하는 SPIFFE ID를 가진 워크로드에서만 연결을 수락한다고 할 수 있습니다. 하이브리드 구조 # 그러나 워크로드가 여러 SVID를 보유하고 이를 다른 목적으로 사용할 수 있다는 점에 주목할 필요가 있습니다. 이는 실제로 여러 전략을 사용할 수 있음을 의미합니다. 두 가지 다른 유형의 SPIFFE ID가 충돌하지 않도록 일종의 네임스페이싱을 사용해야 합니다. 예를 들어 마지막 두 예제에서 물리적 위치에는 phy 접두사를, 논리적 위치에는 svc 접두사를 사용할 수 있습니다: spiffe://example.teleport.sh/phy/europe/uk/london/hypervisor-001/vm-a3847f spiffe://example.teleport.sh/svc/payments/processor 민감한 정보 회피 # SVID 내에 포