텔레포트 워크로드 아이덴티티는 현재 미리보기 상태입니다. 이는 일부 기능이 누락될 수 있음을 의미합니다. 우리는 워크로드 아이덴티티의 미래를 형성하는 데 도움을 줄 디자인 파트너를 적극적으로 찾고 있으며 귀하의 피드백을 듣고 싶습니다.
이 페이지는 텔레포트의 워크로드 아이덴티티 기능을 프로덕션에서 사용할 때의 일반적인 질문과 모범 사례를 다룹니다.
SPIFFE ID 구조화
SPIFFE ID는 워크로드 및 잠재적으로 사용자를 위한 유연한 식별자입니다. SPIFFE ID 네임스페이스를 어떻게 구조화할지는 궁극적으로 귀하의 조직에 달려 있습니다.
SPIFFE ID를 구조화하는 몇 가지 일반적인 전략이 있습니다. 일반적으로는, 가장 일반적인 것이 계층 구조의 루트에 위치하고 가장 구체적인 부분이 가장 깊은 위치에 있는 계층적 구조가 사용됩니다. 이를 통해 계층의 공통 부분을 공유하는 워크로드 그룹에 대한 액세스를 허용하는 규칙을 생성할 수 있습니다.
논리적 구조
한 가지 전략은 워크로드의 논리적 기능에 따라 SPIFFE ID를 구조화하는 것입니다. 예를 들어, processor라는 서비스가 payments 서비스 그룹에 속할 수 있습니다. 이 경우 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 접두사와 논리적 위치를 위해 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를 성공적으로 구현하는 데 있어 주요 과제 중 하나는 워크로드를 어떻게 통합할 것인지를 결정하는 것입니다. 통합은 일반적으로 두 가지 부분으로 나눌 수 있습니다. 호출 목적으로 SVID를 얻기 위해 워크로드를 구성하는 것과 다른 워크로드의 SVID를 검증하기 위해 신뢰 번들을 얻고 사용하는 워크로드를 구성하는 것입니다.
SPIFFE SDK 및 spiffe-workload-api 서비스
SPIFFE와 통합하는 가장 기본적인 방법은 SPIFFE SDK를 사용하는 것입니다. 이들은 SVID 및 신뢰 번들을 획득하는 과정과 호출 시 SVID를 사용하는 것, 호출 수신 시 SVID를 검증하는 것을 관리합니다.
워크로드 API 엔드포인트는 SVID 및 신뢰 번들을 tbot 에이전트로 요청하는 데 SPIFFE SDK에서 사용됩니다.
SPIFFE SDK는 여러 언어로 제공됩니다:
SPIFFE 워크로드 API를 구성하려면 워크로드 아이덴티티 시작하기 안내를 따르세요.
spiffe-svid 출력 사용하기
워크로드가 SPIFFE SDK가 없는 언어로 작성된 경우, tbot을 구성하여 SVID, SVID 키 및 신뢰 번들을 디스크의 파일로 기록할 수 있습니다.
그런 다음 워크로드를 수정하여 이러한 파일을 읽고 SVID 및 신뢰 번들을 mTLS에 사용할 수 있습니다. 워크로드가 장기 실행되는 경우, 이 파일을 모니터링하고 변경이 발생할 때마다 다시 로드해야 합니다. 이는 단기 SVID의 갱신 및 CA 회전 수명 주기를 설명합니다.
spiffe-svid 출력 유형을 구성하려면 워크로드 아이덴티티 시작하기 안내를 따르세요.
프록시
경우에 따라 프록시를 활용하여 SPIFFE를 구현하는 것이 더 간단할 수 있습니다. 프록시는 워크로드에 사이드카로 설치되어 다른 워크로드와의 mTLS 연결을 자동으로 설정합니다. 또한 프록시는 연결하는 워크로드의 SPIFFE ID에 따라 액세스 제어 정책을 시행하여 특정 워크로드만 귀하의 워크로드에 연결할 수 있도록 보장할 수 있습니다.
이것은 귀하가 워크로드를 직접 수정할 수 없는 경우에 이상적입니다.
그런 프록시 중 하나는 Ghostunnel입니다.
X509 SVID 주제
텔레포트 워크로드 아이덴티티에서 발급된 X509 SVID의 주체 구별 이름은 다음 기준에 의해 결정됩니다:
- DNS SAN이 요청되지 않은 경우, 주체가 설정되지 않습니다.
- DNS SAN이 요청된 경우, 첫 번째 DNS SAN이 주체 공통 이름으로 설정됩니다.
이러한 동작은 DNS SAN을 분석할 수 없거나 SPIFFE를 인식하지 못하는 레거시 시스템과의 상호 운용성을 지원하기 위해 존재합니다.
이러한 레거시 시스템의 한 예는 Postgres입니다. Postgres는 인증서를 사용한 클라이언트 인증을 지원하지만, 오직 공통 이름만을 사용하여 어떤 데이터베이스 사용자에게 접근 권한을 부여할지를 결정합니다. 텔레포트 워크로드 아이덴티티를 Postgres와 통합하기 위해 DNS SAN이 포함된 X509 SVID를 발급할 수 있습니다. 예를 들어, myuser.mydb.db-access.example.com의 DNS SAN이 포함된 인증서를 발급할 수 있습니다. 위에서 설명한 동작에 따라 이 DNS SAN으로 공통 이름이 설정되며, Postgres를 구성하여 이 공통 이름을 myuser로 매핑할 수 있습니다.
직접 데이터베이스 액세스
텔레포트 워크로드 ID를 사용하여 워크로드의 데이터베이스 접근을 인증하려는 특정 상황이 있을 수 있습니다.
이는 데이터베이스 서비스와의 머신 ID 사용과 몇 가지 측면에서 다릅니다:
- 연결이 텔레포트의 프록시 서비스 및 데이터베이스 서비스를 통하지 않고 워크로드에서 직접 데이터베이스로 이루어집니다.
- 워크로드와 데이터베이스 간의 연결 지연이 줄어듭니다.
- 텔레포트는 감사 로그에 워크로드의 쿼리를 기록하지 않습니다.
- 텔레포트는 세부적인 액세스 제어 정책을 시행할 수 없습니다.
- 데이터베이스는 natively mTLS 클라이언트 인증을 지원해야 합니다.
- 데이터베이스는 권한 규칙으로 직접 구성되어야 합니다.
일반적으로 워크로드는 X509 SVID를 클라이언트 인증서로 사용하여 데이터베이스에 연결합니다. 그런 다음 데이터베이스는 텔레포트 워크로드 ID가 제공한 신뢰 번들을 사용하여 이 인증서를 검증합니다. CA 회전이 발생하는 경우 신뢰 번들이 최신 상태로 유지되도록 tbot을 데이터베이스와 가까운 위치에 설치하는 것이 좋습니다.
데이터베이스는 일반적으로 클라이언트 인증서의 주체 공통 이름(CN)을 사용하여 연결을 인증할 사용자를 결정합니다. 이는 SPIFFE ID가 URI SAN으로만 존재하는 워크로드 ID의 기본 동작과 호환되지 않습니다. 공통 이름을 설정하는 방법에 대해서는 X509 SVID 주제 섹션을 참조하세요.
mTLS를 사용하여 클라이언트 인증을 구성하는 방법에 대해서는 데이터베이스 문서를 따르세요: