Teleport 워크로드 아이덴티티에 대한 모범 사례

디자인 파트너십

우리는 Teleport Workload Identity의 미래를 함께 만들어 나갈 디자인 파트너를 적극적으로 찾고 있으며, 귀하의 피드백을 듣고 싶습니다.

이 페이지에서는 프로덕션에서 Teleport의 워크로드 아이덴티티 기능을 사용할 때 자주 묻는 질문과 모범 사례를 다룹니다.

SPIFFE ID 구성

SPIFFE ID는 워크로드 및 잠재적으로 사용자에 대한 유연한 식별자입니다. 귀하의 조직이 SPIFFE ID 네임스페이스를 어떻게 구성할지는 궁극적으로 귀하에게 달려 있습니다.

SPIFFE ID를 구성하는 몇 가지 일반적인 전략이 있습니다. 일반적으로 계층 구조가 사용되며, 계층의 최상위는 가장 일반적이고 가장 깊은 부분은 가장 구체적입니다. 이를 통해 계층의 공통 부분을 공유하는 워크로드 그룹에 대한 액세스를 허용하는 규칙을 만들 수 있습니다.

논리적 구조

하나의 전략은 워크로드의 논리적 기능을 기반으로 SPIFFE ID를 구성하는 것입니다. 예를 들어, payments 서비스 그룹 내에 포함된 processor 라는 이름의 서비스가 있을 수 있습니다. 이 서비스에 대한 SPIFFE ID를 spiffe://example.teleport.sh/production/payments/processor 로 지정할 수 있습니다. 모든 payments 서비스가 서로에 접근할 수 있어야 한다고 결정하면, spiffe://example.teleport.sh/production/payments 로 시작하는 SPIFFE ID에 대한 액세스를 허용하는 규칙을 만들 수 있습니다.

물리적 구조

또 다른 전략은 워크로드의 "물리적" 위치를 사용하여 SPIFFE ID를 구성하는 것입니다. 여기에는 여전히 "가상" 요소가 포함될 수 있습니다. 예를 들어, 런던의 데이터 센터에 있는 호스트의 VM에서 실행되고 있는 워크로드가 있을 수 있습니다. 이 워크로드에 대한 SPIFFE ID를 spiffe://example.teleport.sh/europe/uk/london/hypervisor-001/vm-a3847f 로 지정할 수 있습니다. 이는 논리적 구조와는 다른 방식으로 유용하며, 캐시와 같이 물리적으로 인접한 다른 워크로드만 접근할 수 있도록 워크로드를 제한하고자 할 때 이상적입니다. 런던에 위치한 캐시는 spiffe://example.teleport.sh/europe/uk 로 시작하는 SPIFFE ID를 가진 워크로드에서만 연결을 수락할 것이라고 말할 수 있습니다.

하이브리드 구조

그러나 워크로드가 여러 SVID를 보유하고 이를 서로 다른 목적으로 사용할 수 있다는 점에 유의할 가치가 있습니다. 이는 여러 전략을 실제로 사용할 수 있음을 의미합니다. 이러한 두 가지 유형의 SPIFFE ID가 충돌하지 않도록 일부 형태의 네임스페이싱을 사용하는 것이 좋습니다. 예를 들어, 마지막 두 예제에서 물리적 위치를 위한 ID에 phy 를 접두사로 붙이고 논리적 위치를 위한 ID에 svc 를 접두사로 붙일 수 있습니다:

spiffe://example.teleport.sh/phy/europe/uk/london/hypervisor-001/vm-a3847f
spiffe://example.teleport.sh/svc/payments/processor

민감한 정보 피하기

SVID 내의 SPIFFE ID는 비밀이 아니며 연결된 워크로드와 연결하는 워크로드에 노출된다는 점에 유의할 가치가 있습니다. 따라서 SPIFFE ID 내에 민감한 정보를 두지 않도록 하십시오.

워크로드와 SPIFFE 통합하기

SPIFFE를 성공적으로 구현하는 데 있어 한 가지 도전 과제는 워크로드와 SPIFFE를 어떻게 통합할 것인지 결정하는 것입니다. 통합에는 일반적으로 두 가지 부분이 있습니다. 호출을 위해 SVID를 얻도록 워크로드를 구성하고, 다른 워크로드의 SVID를 검증하기 위해 신뢰 번들을 얻고 사용하는 워크로드를 구성하는 것입니다.

SPIFFE SDKs 및 `spiffe-workload-api` 서비스

SPIFFE와 통합하는 가장 기본적인 방법은 SPIFFE SDKs를 사용하는 것입니다. 이들은 SVIDs 및 신뢰 번들을 얻는 과정을 관리하고, 호출 시 SVIDs를 사용하며, 수신 호출 시 SVIDs를 검증하는 과정을 관리합니다.

Workload API 엔드포인트는 SPIFFE SDKs가 tbot 에이전트로부터 SVIDs 및 신뢰 번들을 요청하는 데 사용됩니다.

SPIFFE SDKs는 여러 언어에서 사용할 수 있습니다:

SPIFFE Workload API를 구성하려면 Workload Identity 시작하기 의 지침을 따르십시오.

`spiffe-svid` 출력 사용하기

작업 부하가 SPIFFE SDK가 지원되지 않는 언어로 작성된 경우, tbot 을 구성하여 SVID, SVID 키 및 신뢰 번들을 디스크의 파일에 기록할 수 있습니다.

작업 부하는 이러한 파일을 읽고 SVID 및 신뢰 번들을 mTLS에 사용할 수 있도록 수정할 수 있습니다. 작업 부하가 장기 실행되는 경우, 이러한 파일을 감시하고 변경 사항 발생 시 다시 로드해야 합니다. 이는 단기 SVID 갱신 및 CA 순환을 반영합니다.

spiffe-svid 출력 유형을 구성하려면 Workload Identity 시작하기 의 지침을 따르십시오.

프록시

경우에 따라, SPIFFE를 구현하기 위해 프록시를 활용하는 것이 더 간단할 수 있습니다. 프록시는 작업 부하에 사이드카로 설치되어 자동으로 다른 작업 부하에 대한 mTLS 연결 설정을 처리할 수 있습니다. 또한, 프록시는 연결하는 작업 부하의 SPIFFE ID를 기반으로 액세스 제어 정책을 시행하여 특정 작업 부하만 귀하의 작업 부하에 연결할 수 있도록 보장할 수 있습니다.

이것은 작업 부하를 직접 수정할 수 없는 경우에 이상적입니다.

그런 프록시 중 하나는 Ghostunnel입니다.

X509 SVID 주체

X509 SVID가 Teleport Workload Identity에 의해 발급될 때, 인증서의 주체 구별 이름은 다음 기준에 의해 결정됩니다:

요청된 DNS SAN이 없으면 주체는 설정되지 않습니다.
DNS SAN이 요청된 경우, 첫 번째 DNS SAN이 주체의 공통 이름으로 설정됩니다.

이 동작은 DNS SAN을 파싱할 수 없거나 SPIFFE를 인식하지 못하는 레거시 시스템과의 상호 운용성을 지원하기 위해 존재합니다.

그런 레거시 시스템의 예로 Postgres가 있습니다. Postgres는 인증서를 사용한 클라이언트 인증을 지원하지만, 공통 이름만 사용하여 어떤 데이터베이스 사용자에게 접근을 허용할지를 결정할 수 있도록 허용합니다. Teleport Workload Identity를 Postgres와 통합하려면 DNS SAN이 있는 X509 SVID를 발급하여 데이터베이스 사용자와 매핑할 수 있습니다. 예를 들어, myuser.mydb.db-access.example.com 의 DNS SAN이 있는 인증서를 발급할 수 있습니다. 위에서 설명한 동작은 이 DNS SAN을 공통 이름으로 설정하며, 이후 Postgres에서 이 공통 이름을 myuser 에 매핑하도록 구성할 수 있습니다.

직접 데이터베이스 접근

특정 상황에서는 Teleport Workload ID를 사용하여 워크로드의 데이터베이스 접근을 인증할 수 있습니다.

이 방법은 데이터베이스 서비스와 함께 머신 ID를 사용하는 것과 몇 가지 차이가 있습니다:

연결이 Teleport의 프록시 서비스와 데이터베이스 서비스를 거치지 않고 워크로드에서 데이터베이스로 직접 이루어집니다.
워크로드와 데이터베이스 간의 연결 지연 시간이 줄어듭니다.
Teleport는 감사 로그에 워크로드의 쿼리를 기록하지 않습니다.
Teleport는 세분화된 접근 제어 정책을 시행할 수 없습니다.
데이터베이스는 기본적으로 mTLS 클라이언트 인증을 지원해야 합니다.
데이터베이스는 권한 규칙으로 직접 구성되어야 합니다.

일반적으로 워크로드는 클라이언트 인증서로 X509 SVID를 사용하여 데이터베이스에 연결합니다. 데이터베이스는 Teleport Workload ID가 제공한 신뢰 번들을 사용하여 이 인증서를 검증합니다. CA가 교체되는 경우 신뢰 번들이 최신 상태로 유지되도록 데이터베이스 가까이에 tbot 을 설치하는 것을 권장합니다.

데이터베이스는 일반적으로 클라이언트 인증서의 Common Name (CN)을 사용하여 연결을 인증할 사용자 를 결정합니다. 이는 SPIFFE ID가 URI SAN으로만 존재하는 Workload ID의 기본 동작과 호환되지 않습니다. CN 설정 방법에 대한 정보는 X509 SVID Subject를 참조하십시오.

mTLS를 사용하여 클라이언트 인증을 구성하는 방법에 대한 데이터베이스 문서를 따르십시오:

Teleport 원문 보기