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

Teleport에서, self-hosted 데이터베이스는 mTLS 인증을 활성화하기 위해 인증서로 구성되어야 합니다 Teleport 데이터베이스 서비스.

Teleport 10 는 self-hosted 데이터베이스의 CA 회전을 Teleport 클러스터의 나머지와 분리하기 위해 db 인증서 권한(CA)을 도입했습니다.

Teleport 15 는 Teleport self-hosted 데이터베이스 접근을 위해 호스트 및 클라이언트 CA 역할을 동시에 수행하고 있던 Teleport db CA의 책임을 분리하기 위해 db_client CA를 도입했습니다. db_client CA는 또한 Teleport의 패치로 추가되었으며 13.4.17 및 14.3.7 에서도 도입되었습니다.

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

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

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

전제 조건

  • 실행 중인 Teleport 클러스터 버전 17.0.0-dev 이상. Teleport를 시작하려면 가입하여 무료 평가판을 이용하거나 데모 환경 설정 방법을 확인하십시오.

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

    tctl 및 tsh 다운로드 방법에 대한 지침은 설치를 방문하십시오.

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

Teleport db CA 마이그레이션

귀하의 Teleport 클러스터의 db CA는 self-hosted 데이터베이스에 인증서를 발급하는 데 사용될 수 있습니다. 이는 편리합니다. 왜냐하면 Teleport 데이터베이스 서비스는 기본적으로 db CA로 발급된 인증서를 신뢰하므로 추가 TLS 구성이 필요하지 않기 때문입니다.

대안으로, 외부 CA를 사용하여 self-hosted 데이터베이스에 인증서를 발급할 수 있습니다 - 데이터베이스에 연결할 때 Teleport 데이터베이스 서비스가 해당 CA를 신뢰하도록 구성하면 됩니다.

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

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

예제 및 자세한 정보는 데이터베이스 접근 구성 참조를 참조하십시오.

Teleport 10 이전에, Teleport host CA는 self-hosted 데이터베이스에 인증서를 발급하는 데 사용되었습니다 (via tctl auth sign ). db CA는 self-hosted 데이터베이스 CA 회전을 Teleport 클러스터의 나머지에서 분리하기 위해 도입되었습니다. 즉, self-hosted 데이터베이스용 CA를 회전할 때 클러스터와 연결된 다른 리소스에 영향을 주지 않아야 합니다. 마찬가지로, 클러스터의 host CA를 회전할 때 self-hosted 데이터베이스에 영향을 주지 않도록 해야 합니다.

Teleport 10로 업그레이드한 후 데이터베이스 접근이 중단되는 것을 방지하기 위해, Teleport 클러스터는 host CA의 복사본으로 db CA를 생성하도록 자동으로 마이그레이션됩니다.

귀하의 클러스터가 Teleport 10로 업그레이드되었고 self-hosted 데이터베이스에 인증서를 발급하기 위해 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 교체 후 인증서 재구성

db_client CA 교체 중에 데이터베이스의 인증서를 재구성하기 위해 tctl auth sign 을 사용하면, 신뢰된 인증서 출력에 이전 및 새로운 CA 인증서가 모두 포함됩니다. 마이그레이션을 완료하려면, 교체 후 이 데이터베이스를 다시 재구성해야 하며, 그렇게 하면 새로운 CA만을 신뢰하게 됩니다. 만약 db_client CA 교체 중 및 이후에 각 데이터베이스를 재구성하고 싶지 않거나 Teleport를 통해 데이터베이스와의 연결을 일시적으로 잃는 것에 관해 신경 쓰지 않는다면, db_client CA 교체를 완료하고 그 후 데이터베이스를 재구성할 수 있습니다.

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

기존 클러스터를 Teleport

=10 로 업그레이드하고, 업그레이드 이후에 host CA와 db CA를 모두 최소 한 번 이상 교체하지 않았다면, db CA 마이그레이션을 완료해야 합니다.

기존 클러스터를 Teleport

=13.4.17, =14.3.7, 또는 =15 로 업그레이드하고, 업그레이드 이후에 db CA와 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 트렌드를 격주로 만나보세요!