📣 Teleport의 공식 파트너 인포그랩에서 OpenAI 기술 기반으로 자체 개발한 자동화 번역 프로그램을 통해 Teleport 공식 문서의 한글판을 국내 최초로 제공합니다.
Infograb logo
데이터베이스 CA 마이그레이션

Teleport에서 자체 호스팅 데이터베이스는 mTLS 인증을 활성화하기 위해 인증서로 구성되어야 합니다.
Teleport 데이터베이스 서비스.

Teleport 10는 자체 호스팅 데이터베이스의 CA 회전을 나머지 Teleport 클러스터와 분리하기 위해 db 인증 기관(CA)을 도입했습니다.

Teleport 15는 Teleport 자체 호스팅 데이터베이스 액세스를 위해 호스트 및 클라이언트 CA 역할을 했던 Teleport db CA의 책임을 분리하기 위해 db_client CA를 도입했습니다.
db_client CA는 Teleport 13.4.17 및 14.3.7에서 패치로 추가되었습니다.

db 및 db_client CA는 모두 Teleport 업그레이드 후 자동으로 발생하는 마이그레이션으로 도입되었습니다.

Teleport의 호스트/클라이언트 데이터베이스 CA 분리는 데이터베이스 인스턴스의 개인 키가 손상될 경우 다른 리소스로의 수평 이동 가능성을 제한하기 위한 목적입니다.

이 가이드는 이러한 CA가 Teleport에 추가된 이유와 Teleport 클러스터에 대해 보류 중인 마이그레이션을 완료하는 방법에 대한 정보를 제공합니다.

전제 조건

  • 실행 중인 Teleport 클러스터 버전 이상. Teleport를 시작하려면, 가입하기 위해 무료 평가판에 등록하거나 데모 환경 설정하기를 참조하세요.

  • tctl 관리 도구와 tsh 클라이언트 도구.

    tctl과 tsh 다운로드에 대한 지침은 설치를 방문하세요.

  • 당신의 Teleport 클러스터에 연결할 수 있는지 확인하려면, tsh login으로 로그인한 다음 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어: 
    tsh login --proxy=teleport.example.com --user=email@example.com
    tctl status
    클러스터  teleport.example.com
    버전  16.2.0
    CA 핀   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
    클러스터에 연결하고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 작업대에서 후속 tctl 명령어를 실행할 수 있습니다. 자신의 Teleport 클러스터를 호스팅하는 경우, Teleport 인증 서비스를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.
  • db 또는 db_client CA 이전 버전에서 업그레이드된 Teleport 클러스터입니다.
    Teleport 클러스터가 Teleport 15 또는 그 이후에 생성되었다면, 이 가이드는 귀하의 클러스터에 적용되지 않습니다.
    귀하의 db 및 db_client CA는 마이그레이션되지 않았습니다.

Teleport db CA 마이그레이션

귀하의 Teleport 클러스터의 db CA를 사용하여 자체 호스팅 데이터베이스에 인증서를 발급할 수 있습니다.
이는 편리합니다. Teleport 데이터베이스 서비스는 기본적으로 db CA에 의해 발급된 인증서를 신뢰하므로 추가 TLS 구성 없이도 Teleport에서 작동합니다.

또한 외부 CA를 사용하여 자체 호스팅 데이터베이스에 인증서를 발급할 수 있습니다.
데이터베이스에 연결할 때 Teleport 데이터베이스 서비스가 해당 CA를 신뢰하도록 구성하기만 하면 됩니다.

예를 들어, Teleport 데이터베이스 서비스 teleport.yaml 구성 파일에 정의된 정적 데이터베이스의 경우,
tls.ca_cert_file을 CA의 루트 인증서를 포함하는 파일로 설정합니다.

동적 데이터베이스의 경우, CA의 루트 인증서를 spec.tls.ca_cert에 넣습니다.

예제 및 더 많은 정보는 데이터베이스 액세스 구성 참조를 참조하십시오.

Teleport 10 이전에는 Teleport host CA가 자체 호스팅 데이터베이스에 인증서를 발급하는 데 사용되었습니다(tctl auth sign을 통해).
db CA는 자체 호스팅 데이터베이스의 CA 회전을 Teleport 클러스터의 나머지 부분과 분리하기 위해 도입되었습니다.
즉, 자체 호스팅 데이터베이스에 사용되는 CA를 회전하더라도 클러스터에 연결된 다른 리소스에 영향을 주지 않아야 합니다.
마찬가지로 클러스터의 host CA를 회전할 때, 자체 호스팅 데이터베이스에 영향을 주는 것에 대해 걱정할 필요가 없습니다.

Teleport 10로 업그레이드한 후 데이터베이스 액세스가 끊기지 않도록 Teleport 클러스터는 호스트 CA의 복사본으로 db CA를 생성하도록 자동으로 마이그레이션됩니다.

귀하의 클러스터가 Teleport 10으로 업그레이드되었고 Teleport를 사용하여 자체 호스팅 데이터베이스에 인증서를 발급했다면,
귀하의 db CA 마이그레이션이 완료되었는지 확인해야 합니다.
그렇지 않으면 나중에 어떤 이유로든 하나의 CA만 회전할 경우, 이전 CA의 복사본이 여전히 존재하게 됩니다.
이것이 반드시 클러스터의 취약점을 초래하는 것은 아니지만, 회전한 후 오래된 CA를 보관하는 것은 보안 관행에 어긋납니다.

db CA 마이그레이션을 완료하려면:

  • host CA를 회전할 것을 권장합니다.
  • db CA를 회전할 것을 강력히 권장합니다.

Teleport db_client CA 마이그레이션

Teleport 데이터베이스 서비스는 클라이언트 인증서를 사용하여 자체 호스팅 데이터베이스에 인증해야 하며,
이는 데이터베이스가 Teleport의 db_client CA를 신뢰하도록 구성되어야 함을 요구합니다.
db_client CA가 도입되기 이전에는, 자체 호스팅 데이터베이스가 클라이언트 인증을 위해 Teleport db CA를 신뢰하도록 구성되어야 했습니다.

구식 접근법인 db CA를 클라이언트 연결에 대해 신뢰하는 경우, 데이터베이스의 개인 키가 손상되고 해당 키에 대해 db 인증서가 발급되었을 경우,
그 인증서를 이용해 다른 데이터베이스에 접근할 수 있습니다.

모든 자체 호스팅 데이터베이스가 개인 키 손상 이후의 수평 이동에 취약한 것은 아닙니다.
예를 들어, MySQL과 PostgreSQL은 클라이언트의 인증서 주체가 클라이언트의 데이터베이스 사용자와 일치하는지 확인합니다.
다른 데이터베이스는 클라이언트의 인증서가 신뢰할 수 있는지를 검증하지만, 인증서 주체를 데이터베이스 사용자 이름과 일치시키지는 않습니다.
예를 들어, Cassandra, ScyllaDB 및 Redis는 클라이언트 인증서 주체를 검증하지 않습니다.
이러한 모든 데이터베이스는 성공적인 mTLS 핸드셰이크 이후에 비밀번호 인증이 요구되도록 구성할 수 있습니다.
그러나 심층 방어를 위해 이러한 데이터베이스는 db_client CA에서 발급된 인증서를 제시한 클라이언트와만 mTLS 핸드셰이크를 수행해야 합니다.

귀하의 Teleport 클러스터가 Teleport >= 13.4.17,

= 14.3.7, 또는
= 15로 업그레이드되었다면,
db_client 마이그레이션이 완료되었는지 확인해야 합니다.
db_client CA 마이그레이션을 완료하려면:

  • db CA를 회전할 것을 권장합니다.
  • db_client CA를 회전할 것을 강력히 권장합니다.
  • db_client CA 회전을 완료한 후 데이터베이스의 인증서를 다시 구성할 것을 강력히 권장합니다.
db_client CA 회전 후 인증서 재구성

tctl auth sign을 사용하여 db_client CA 회전 중에 데이터베이스의 인증서를 다시 구성하는 경우,
신뢰할 수 있는 인증서 출력에는 이전 및 새로운 CA 인증서가 모두 포함됩니다.
마이그레이션을 완료하려면 회전 후 다시 한 번 해당 데이터베이스를 재구성해야 하며,
그렇게 하면 새 CA만 신뢰하게 됩니다.

db_client CA 회전 중 및 이후에 각 데이터베이스를 재구성하고 싶지 않으며,
Teleport를 통해 데이터베이스와의 연결을 일시적으로 잃는 것이 괜찮다면,
db_client CA 회전을 완료하고 그 이후에 데이터베이스를 다시 구성할 수 있습니다.

1/2. Teleport CA 마이그레이션 확인

기존 클러스터를 Teleport >= 10으로 업그레이드하고, 업그레이드 이후 두 개 모두 host 및 db CA를
최소 한 번도 회전하지 않았다면, db CA 마이그레이션을 완료해야 합니다.

기존 클러스터를 Teleport >= 13.4.17,

= 14.3.7 또는
= 15으로 업그레이드하고,
업그레이드 이후 두 개 모두 db 및 db_client CA를 최소 한 번도 회전하지 않았다면,
db_client CA 마이그레이션을 완료해야 합니다.

db 또는 db_client CA 중 하나의 마이그레이션이 필요한지 확실하지 않은 경우, 중복 CA를 확인할 수 있습니다.
다음 명령을 사용하여 host, db, db_client CA의 X.509 인증서 일련 번호를 출력합니다(순서대로):

tctl auth export --type=tls-host | openssl x509 -noout -serial
tctl auth export --type=db | openssl x509 -noout -serial
tctl auth export --type=db-client | openssl x509 -noout -serial

db CA 일련 번호가 host CA 일련 번호와 일치하면,
db CA 마이그레이션을 완료해야 합니다.

db_client CA 일련 번호가 db CA 일련 번호와 일치하면,
db_client CA 마이그레이션을 완료해야 합니다.

2/2. CA 회전

db 및 db_client 마이그레이션을 모두 완료해야 하는 경우, host, db, db_client CA 각각의 단일 회전으로 충분합니다:
db CA를 두 번 회전할 필요는 없습니다.

host CA를 회전해야 하는 경우, db 또는 db_client CA 회전 중에 이 회전을 먼저 완료할 것을 권장합니다:
host CA 회전 중에 다른 CA를 병행하여 회전하지 마십시오.

데이터베이스 CA 회전은 새 인증서를 사용하여
외부 리소스(자체 호스팅 데이터베이스)를 구성하는 것이 포함되기 때문에 약간 다릅니다.
db 및 db_client CA를 동시에 회전하여 데이터베이스 인증서 재구성 단계를 반복하지 않도록 합니다.

CA 회전에 대한 정보는 CA 회전 가이드를 참조하십시오.

추가 읽기

Teleport 원문 보기
인포레터에서 최신 DevOps 트렌드를 격주로 만나보세요!