InfoGrab Docs

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

요약

이 페이지는 프로덕션에서 Teleport의 워크로드 아이덴티티 기능 사용에 대한 일반적인 질문과 모범 사례를 다룹니다. SPIFFE ID는 워크로드, 그리고 잠재적으로 사용자에 대한 유연한 식별자입니다. SPIFFE ID 구조화에는 몇 가지 일반적인 전략이 있습니다.

이 페이지는 프로덕션에서 Teleport의 워크로드 아이덴티티 기능 사용에 대한 일반적인 질문과 모범 사례를 다룹니다.

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 내에 포함된 SPIFFE ID는 비밀이 아니며 연결하는 워크로드와 연결 대상에 노출됩니다. 따라서 SPIFFE ID 내에 민감한 정보를 넣지 마세요.

워크로드와 SPIFFE 통합#

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

SPIFFE SDK 및 spiffe-workload-api 서비스#

SPIFFE와 가장 기본적으로 통합하는 방법은 SPIFFE SDK를 사용하는 것입니다. 이러한 SDK는 SVID와 신뢰 번들을 얻는 프로세스를 관리하고, 호출 시 SVID를 사용하며, 호출을 받을 때 SVID를 검증합니다.

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

SPIFFE SDK는 여러 언어로 제공됩니다:

SPIFFE Workload API를 구성하려면 워크로드 아이덴티티 시작하기의 지침을 따르세요.

spiffe-svid 출력 서비스 사용#

워크로드가 SPIFFE SDK를 지원하는 언어로 작성되지 않은 경우, tbot을 구성하여 SVID, SVID 키 및 신뢰 번들을 디스크의 파일에 쓸 수 있습니다.

워크로드는 이러한 파일을 읽고 mTLS에 SVID와 신뢰 번들을 사용하도록 수정할 수 있습니다. 워크로드가 장시간 실행되는 경우 이러한 파일을 감시하고 변경이 발생하면 다시 로드해야 합니다. 이는 단기 유효 SVID의 갱신과 CA 교체를 처리합니다.

spiffe-svid 출력 서비스 유형을 구성하려면 워크로드 아이덴티티 시작하기의 지침을 따르세요.

프록시#

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

이는 워크로드 자체를 수정할 수 없는 경우에 이상적입니다.

이러한 프록시 중 하나가 Ghostunnel입니다.

X509 SVID Subject#

Teleport 워크로드 아이덴티티가 X509 SVID를 발급할 때 인증서의 주체 식별 이름은 다음 기준에 따라 결정됩니다:

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

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

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

직접 데이터베이스 접근#

워크로드의 데이터베이스 접근을 인증하기 위해 Teleport Workload ID를 사용하려는 특정 상황이 있습니다.

이는 Database Service와 함께 머신 및 워크로드 아이덴티티를 사용하는 것과 몇 가지 차이점이 있습니다:

  • 연결은 Teleport의 Proxy Service 및 Database Service를 통하지 않고 워크로드에서 데이터베이스로 직접 이루어집니다.
  • 워크로드와 데이터베이스 간의 연결 지연 시간이 줄어듭니다.
  • 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 워크로드 아이덴티티 모범 사례

원문 보기
요약

이 페이지는 프로덕션에서 Teleport의 워크로드 아이덴티티 기능 사용에 대한 일반적인 질문과 모범 사례를 다룹니다. SPIFFE ID는 워크로드, 그리고 잠재적으로 사용자에 대한 유연한 식별자입니다. SPIFFE ID 구조화에는 몇 가지 일반적인 전략이 있습니다.

이 페이지는 프로덕션에서 Teleport의 워크로드 아이덴티티 기능 사용에 대한 일반적인 질문과 모범 사례를 다룹니다.

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 내에 포함된 SPIFFE ID는 비밀이 아니며 연결하는 워크로드와 연결 대상에 노출됩니다. 따라서 SPIFFE ID 내에 민감한 정보를 넣지 마세요.

워크로드와 SPIFFE 통합#

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

SPIFFE SDK 및 spiffe-workload-api 서비스#

SPIFFE와 가장 기본적으로 통합하는 방법은 SPIFFE SDK를 사용하는 것입니다. 이러한 SDK는 SVID와 신뢰 번들을 얻는 프로세스를 관리하고, 호출 시 SVID를 사용하며, 호출을 받을 때 SVID를 검증합니다.

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

SPIFFE SDK는 여러 언어로 제공됩니다:

SPIFFE Workload API를 구성하려면 워크로드 아이덴티티 시작하기의 지침을 따르세요.

spiffe-svid 출력 서비스 사용#

워크로드가 SPIFFE SDK를 지원하는 언어로 작성되지 않은 경우, tbot을 구성하여 SVID, SVID 키 및 신뢰 번들을 디스크의 파일에 쓸 수 있습니다.

워크로드는 이러한 파일을 읽고 mTLS에 SVID와 신뢰 번들을 사용하도록 수정할 수 있습니다. 워크로드가 장시간 실행되는 경우 이러한 파일을 감시하고 변경이 발생하면 다시 로드해야 합니다. 이는 단기 유효 SVID의 갱신과 CA 교체를 처리합니다.

spiffe-svid 출력 서비스 유형을 구성하려면 워크로드 아이덴티티 시작하기의 지침을 따르세요.

프록시#

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

이는 워크로드 자체를 수정할 수 없는 경우에 이상적입니다.

이러한 프록시 중 하나가 Ghostunnel입니다.

X509 SVID Subject#

Teleport 워크로드 아이덴티티가 X509 SVID를 발급할 때 인증서의 주체 식별 이름은 다음 기준에 따라 결정됩니다:

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

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

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

직접 데이터베이스 접근#

워크로드의 데이터베이스 접근을 인증하기 위해 Teleport Workload ID를 사용하려는 특정 상황이 있습니다.

이는 Database Service와 함께 머신 및 워크로드 아이덴티티를 사용하는 것과 몇 가지 차이점이 있습니다:

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

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

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

mTLS를 사용한 클라이언트 인증 구성 방법은 각 데이터베이스의 문서를 따르세요: