Teleport 클러스터의 구성 요소는 X.509 또는 SSH 인증서를 사용하여 서로를 인증합니다. 인증서를 발급하기 위해 Teleport는 여러 개의 인증 기관을 유지합니다. 악의적인 행위자가 귀하의 Teleport 클러스터의 일부로 가장하지 못하도록 Teleport CA를 회전할 수 있습니다. 이 가이드는 Teleport가 유지하는 CA와 이를 회전하는 방법을 설명합니다.
단계에 따라 진행하기 전, 전체 가이드를 숙지하는 것이 좋습니다. CA 회전이 예상대로 진행되지 않을 경우 롤백할 준비가 되어 있어야 합니다.
작동 방식
Teleport는 CA를 서로 독립적으로 유지하며, 하나의 CA를 회전해도 다른 CA의 회전 상태에는 영향을 주지 않습니다. 회전 프로세스는 운영자가 인프라를 업데이트하고 필요한 경우 CA 회전을 롤백할 수 있도록 단계로 진행됩니다.
Teleport CA 회전은 각 CA에 대해 다섯 단계로 이루어집니다. 단계의 순서는 다음과 같습니다.
standby: 진행 중인 회전 없음. 아무 작업이 시작되지 않았습니다.init: 새로운 인증 기관이 발급되지만 사용되지 않습니다.update_clients: Teleport Auth Service는 새로운 CA를 사용하여 인증서를 서명하지만, 원래 CA로 서명된 인증서를 계속 신뢰합니다.update_servers: Teleport 클러스터 구성 요소(에이전트, Auth Service 및 Proxy Service 인스턴스)는 새로운 인증 기관으로 서명된 TLS 및 SSH 인증서를 제공하기 위해 다시 로드하고 시작하지만 여전히 원래 인증 기관에서 발급된 인증서를 수락합니다. 이는 Teleport의hostCA 에만 적용됩니다.standby: 진행 중인 회전 없음. 모든 작업이 완료되었습니다.
최종 standby 단계 이전에 회전을 rollback 단계로 설정하여 회전을 중단하고 원래 인증 기관으로 돌아갈 수 있습니다.
CA 회전은 수동 또는 반자동으로 수행할 수 있습니다. 수동 모드에서는 관리자가 Teleport Auth Service에 각 단계에서 다음 단계로 진행하라고 지시해야 합니다. 단계 간에 관리자는 각 변경 사항에 적응하기 위해 인프라를 준비할 수 있습니다. 반자동 모드에서는 Teleport Auth Service가 자동으로 각 단계를 순환하며, 각 단계 간의 유예 기간이 있습니다.
전제 조건
-
실행 중인 Teleport 클러스터 버전 이상. Teleport를 시작하려면, 가입하기 위해 무료 평가판에 등록하거나 데모 환경 설정하기를 참조하세요.
-
tctl관리 도구와tsh클라이언트 도구.tctl과tsh다운로드에 대한 지침은 설치를 방문하세요.
- 당신의 Teleport 클러스터에 연결할 수 있는지 확인하려면,
tsh login으로 로그인한 다음 현재 자격 증명을 사용하여tctl명령어를 실행할 수 있는지 확인하십시오. 예를 들어:클러스터에 연결하고tsh login --proxy=teleport.example.com --user=email@example.comtctl status클러스터 teleport.example.com
버전 16.2.0
CA 핀 sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
tctl status명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 작업대에서 후속tctl명령어를 실행할 수 있습니다. 자신의 Teleport 클러스터를 호스팅하는 경우, Teleport 인증 서비스를 호스팅하는 컴퓨터에서 전체 권한으로tctl명령어를 실행할 수도 있습니다.
1단계/4. 회전할 CA 선택
CA를 회전할 때는 CA에 의존하는 인프라의 연결 상태가 끊어지지 않았는지 확인해야 합니다. 새로운 CA를 인프라로 내보내야 할 수도 있습니다. 아래에서 하나의 CA를 선택하여 마이그레이션 중 최신 상태를 유지하는 방법을 결정하십시오.
요소의 복잡성을 줄이기 위해 한 번에 하나의 CA를 회전하는 것이 좋습니다. 예외는 db 와 db_client CA로, 이 두 개는 함께 회전해야 합니다.
| CA 유형 | 인증서 주체 |
|---|---|
host | Teleport 에이전트. Auth Service 및 Proxy Service 인스턴스. |
user | Teleport 사용자. |
db | Teleport로 보호되는 자체 호스팅 데이터베이스(사용자는 인증서를 데이터베이스에 배포해야 함). |
db_client | Teleport 데이터베이스 서비스. |
openssh | Teleport 클러스터에 등록된 OpenSSH 서버. |
jwt | 웹 애플리케이션에 액세스하는 Teleport 사용자. |
saml_idp | Teleport SAML IdP. |
oidc_idp | Teleport OIDC IdP 통합. |
host
host CA는 Teleport 에이전트와 Auth Service 및 Proxy Service 인스턴스에 인증서를 발급하여 Teleport 클라이언트와 Teleport Auth Service가 이를 확인할 수 있도록 합니다.
Teleport 에이전트와 Proxy Service 인스턴스는 하트비트를 사용하여 주기적으로 Teleport Auth Service에 상태를 보고하고 Auth Service에 의해 보유된 데이터를 반영하도록 내부 데이터를 업데이트합니다. 이 내부 데이터에는 진행 중인 경우 host CA 회전 상태가 포함됩니다.
에이전트 또는 Proxy Service 인스턴스의 회전 상태를 확인하려면 다음 명령의 변형을 실행합니다:
tctl get resource --format=json | jq '.[] | {hostname: .spec.hostname, rotation: .spec.rotation.state, phase: .spec.rotation.phase}'{ "hostname": "terminal", "rotation": "in_progress", "phase": "init"}
이 예에서 terminal이라는 이름의 Teleport 인스턴스는 상태가 init 단계로 업데이트되었습니다. 이는 새로운 CA 공개 키를 다운로드했으며 상태 전환을 준비하고 있음을 나타냅니다.
다음 리소스를 사용하여 host CA의 회전 상태를 확인할 수 있습니다:
| 역할 | tctl get 값 |
|---|---|
| 애플리케이션 서비스 | app_server |
| 데이터베이스 서비스 | db_server |
| 쿠버네티스 서비스 | kube_server |
| Proxy Service | proxies |
| SSH 서비스 | nodes |
| Windows Desktop Service | windows_desktop_service |
host CA 회전의 각 단계에서, 모든 에이전트와 Proxy Service 인스턴스가 대상 단계로의 전환을 완료했는지 확인한 후 다음 단계로 진행합니다. 2단계에서 단계에 대해 설명하겠습니다.
Teleport 프로세스를 Teleport Auth Service를 통해 클러스터에 추가하는 경우, 각 Teleport 프로세스는 Auth Service를 신뢰하기 위해 CA 핀을 필요로 합니다. host CA 회전 후 CA 핀은 변경됩니다. host CA 회전 후 Teleport 서비스를 추가할 때는 새로운 CA 핀을 사용해야 합니다.
user
user CA는 사용자가 Teleport에 인증할 때 인증서를 발급합니다. 또한 Windows 데스크톱과 Teleport SSH 서버에 연결하는 사용자를 위한 클라이언트 인증서에 서명합니다. Teleport로 보호되는 서버와 Windows 데스크톱은 이 인증서를 사용합니다.
회전을 완료하고 최종 standby 단계에 도달한 후, Teleport에 로그인한 사용자는 새로운 CA로부터 사용자 인증서를 받기 위해 재인증해야 하며, 그렇지 않으면 Teleport 클라이언트 명령이 실패합니다.
Teleport에 Windows 데스크톱을 등록한 경우, 가이드를 따르세요 Teleport 사용자 CA를 내보내 Windows Desktop Service가 RDP 호스트를 인증할 수 있도록 합니다. 회전 중 등록된 데스크톱에 연결할 수 있는지 확인하십시오.
db 및 db_client
db 및 db_client CAs는 Teleport 데이터베이스 서비스가 자체 호스팅된 데이터베이스와 통신하는 데 사용하는 인증서를 발급합니다.
Teleport 데이터베이스 서비스는 자가 호스팅 데이터베이스와 통신할 때 db_client CA로 서명된 인증서를 제시하며, 관리자는 CA가 발급한 인증서를 신뢰하도록 데이터베이스를 구성해야 합니다.
관리자는 자체 호스팅된 데이터베이스가 Teleport로 보호되는 자원임을 확인하기 위해 db CA로 서명된 인증서를 제시하도록 구성할 수 있습니다. 또는, 자체 호스팅된 데이터베이스는 사용자 정의 CA로 서명된 인증서를 제시할 수 있으며, 관리자는 Teleport 데이터베이스 서비스가 CA를 신뢰하도록 구성할 수 있습니다.
회전 시작
Teleport 데이터베이스 서비스는 update_clients 단계에서 새로운 CA로 발급된 클라이언트 인증서를 사용하여 데이터베이스에 연결하기 시작합니다. update_clients 단계에서 자가 호스팅된 데이터베이스에 대한 액세스를 잃지 않도록, init 단계에서 데이터베이스를 재구성한 후 update_clients 단계로 전환한 후에도 여전히 데이터베이스에 액세스할 수 있는지 확인해야 합니다.
update_clients 회전 단계로 진행하기 전에 데이터베이스를 구성하려면 적절한
문서를 참조하세요.
init 단계에서 tctl auth sign 명령은 db와 db_client CA 간에 다릅니다. db_client CA를 회전할 경우, 명령은 신뢰할 수 있는 CA 출력에서 원본 및 새로운 인증 기관을 모두 출력합니다. db CA를 회전할 경우, 명령은 새로운 데이터베이스 서버 인증서만 발급합니다.
db CA만 회전할 경우 init 단계에서 데이터베이스를 재구성할 필요는 없지만, 그렇게 하는 데 해가 되지는 않습니다. 이 시점에서 데이터베이스를 재구성하지 않으면, 회전 중 언제든지 이를 계획해야 하며, 그렇지 않으면 최종 standby 단계로 전환한 후에 이러한 데이터베이스에 대한 액세스를 잃게 됩니다.
회전 롤백
가장 일반적인 롤백 이유는 데이터베이스를 재구성할 수 없는 경우입니다. 데이터베이스를 재구성한 후 연결에 문제가 발생하면 데이터베이스를 잘못 구성했을 가능성이 큽니다.
회전 중에 데이터베이스를 재구성한 경우, 최종 standby 단계로 전환하기 전에 다시 재구성해야 합니다.
openssh
openssh CA는 Teleport에 등록된 OpenSSH 서버에 인증서를 발급합니다. 클라이언트는 Teleport로 보호되는 OpenSSH 서버에 연결할 때 이러한 인증서를 검증합니다.
수동 방법을 사용하여 OpenSSH 서버를 등록한 경우, 최종 standby 단계로 회전을 전환하기 전에 openssh CA를 내보내고 이를 OpenSSH 서버에 제공해야 합니다. 그렇지 않으면 Teleport 사용자가 수동 방법으로 클러스터에 등록한 OpenSSH 서버에 액세스할 수 없습니다.
jwt
Teleport Auth Service는 jwt CA를 사용하여 JSON 웹 토큰에 서명합니다. Teleport 애플리케이션 서비스는 HTTP 메시지에 JSON 웹 토큰을 포함하며, 이는 Teleport로 보호되는 애플리케이션에 전달되며, 이 애플리케이션은 jwt CA를 사용하여 토큰을 검증합니다.
Teleport에 웹 애플리케이션을 등록한 경우 및 해당 애플리케이션이 Teleport 애플리케이션 서비스에서 발신한 트래픽을 JSON 웹 토큰을 검증하여 인증하는 경우, 이러한 애플리케이션이 회전된 CA를 계속 신뢰할 수 있도록 해야 합니다.
Teleport로 보호되는 JWT 애플리케이션은 Teleport jwt CA의 공개 키를 검색하는 두 가지 방법 중 하나를 사용합니다. 방법에 따라, init 단계 이후 및 회전이 최종 standby 단계에 도달하기 전에 조치를 취해야 할 수 있습니다:
- 애플리케이션이 Teleport Proxy Service의
/.well-known/jwks.json엔드포인트를 쿼리합니다. 이 경우 애플리케이션이 엔드포인트에 계속 접근할 수 있는 한 추가 작업이 필요하지 않습니다. 애플리케이션이jwks.json을 캐시하는 경우, 캐시를 무효화해야 합니다. - 애플리케이션이 로컬 파일 시스템에서
jwks.json파일에 액세스합니다./.well-known/jwks.json엔드포인트를 쿼리하여 새로운jwks.json파일을 얻고 이를 다시 업로드해야 합니다.
웹 애플리케이션이 Teleport에서 발행한 JWT를 신뢰할 수 있도록 jwt CA를 내보내는 예는 Elasticsearch와의 JWT 인증 사용 가이드를 참조하세요.
saml_idp
saml_idp CA는 Teleport IdP에 의해 전송된 SAML 메시지에 서명하여 Teleport IdP에 의존하는 서비스가 이를 검증할 수 있도록 합니다.
이 CA를 회전하는 경우, 최종 standby 단계에 들어가기 전에 Teleport SAML IdP에 의존하는 서비스 제공자가 Teleport saml_idp CA를 신뢰하도록 구성해야 합니다. SAML IdP 문서에서 XML 메타데이터 파일을 내보내고 서비스 제공자에게 제공하는 방법을 따르세요.
oidc_idp
oidc_idp CA는 Teleport OIDC IdP 통합에 의해 전송된 메시지에 서명합니다. 의존측(예: AWS)은 이러한 메시지를 검증하여 Teleport 계정을 인증합니다. 이 기능은 External Audit Storage, Auto-Discovery 및 Access Graph의 AWS 동기화와 같은 기능을 위해 필요합니다.
Teleport Proxy Service는 /.well-known/jwks-oidc 경로의 웹 API에서 OIDC IdP 통합을 위한 JSON Web Key Sets를 제공합니다.
Teleport Proxy Service 웹 API의 /.well-known/jwks-oidc 경로는 항상 활성화되어 있습니다. Teleport Proxy Service는 엔드포인트를 자동으로 업데이트합니다.
통합의 JSON Web Key Sets의 전체 URL을 검색하려면 웹 UI의 /.well-known/openid-configuration 경로를 쿼리하고 jwks_uri 필드를 읽습니다:
curl https://example.teleport.sh/.well-known/open-id-configuration | jq '.jwks_uri'"https://example.teleport.sh/.well-known-jwks-oidc"
2단계/4. 수동 회전 시작
회전할 CA를 선택하고 해당 CA에 의존하는 인프라를 확인하거나 업데이트할 계획이 세워지면 수동 회전을 시작할 준비가 된 것입니다.
init 단계
init 단계에서 Teleport Auth Service는 선택한 유형의 새로운 인증 기관을 발급하지만, 인증서를 서명하는 데 사용하지 않습니다.
-
호스트 인증 기관의 수동 회전을 시작합니다:
tctl auth rotate --manual --type=type --phase=init업데이트된 회전 단계는 "init"입니다. 상태를 확인하려면 'tctl status'를 사용하세요. -
tctl를 사용하여 현재 활성 회전이 진행 중인지 확인합니다. 이 명령은 클러스터에 Teleport Auth Service가 유지하는 모든 CA의 회전 상태를 출력합니다:tctl status클러스터 teleport.example.com버전 16.2.0호스트 CA 초기화됨 (모드: 수동, 시작됨: Sep 20 01:44:36 UTC, 종료: Sep 21 2023 07:44:36 UTC)사용자 CA 업데이트된 적 없음데이터베이스 CA 업데이트된 적 없음db_client CA 업데이트된 적 없음openssh CA 업데이트된 적 없음jwt CA 업데이트된 적 없음saml_idp CA 업데이트된 적 없음oidc_idp CA 업데이트된 적 없음CA 핀 sha256:0000000000000000000000000000000000000000000000000000000000000000 -
CA 유형에 따라 인프라를 확인하고 업데이트합니다.
update_clients
init에서 update_clients로 전환하세요. 이 단계에서 Teleport Auth Service는 새로운 CA로 인증서를 서명하지만, 여전히 원래 CA로 서명된 인증서를 신뢰합니다.
-
update_clients단계로 전환합니다:tctl auth rotate --manual --type=type --phase=update_clients업데이트된 회전 단계는 "update_clients"입니다. 상태를 확인하려면 'tctl status'를 사용하세요.
tctl status클러스터 teleport.example.com버전 16.2.0호스트 CA 클라이언트 회전 중 (모드: 수동, 시작됨: Sep 20 2023 01:44:36 UTC, 종료: Sep 21 2023 07:44:36 UTC)사용자 CA 업데이트된 적 없음데이터베이스 CA 업데이트된 적 없음db_client CA 업데이트된 적 없음openssh CA 업데이트된 적 없음jwt CA 업데이트된 적 없음saml_idp CA 업데이트된 적 없음oidc_idp CA 업데이트된 적 없음CA 핀 sha256:0000000000000000000000000000000000000000000000000000000000000000 -
다음 단계로 진행하기 전에 CA에 의존하는 인프라를 확인하거나 업데이트합니다.
-
리소스에 대한 연결이 끊어지는 경우, 새로운 CA를 수용하도록 재구성해야 할 수 있습니다. 액세스를 복원할 수 없거나 데이터베이스를 재구성할 수 없는 경우, 회전 롤백을 수행하여 원래 인증 기관으로 되돌리세요.
update_servers
update_servers 단계로 전환합니다. 이 단계에서 Teleport 클러스터 구성 요소(에이전트, Auth Service 및 Proxy Service 인스턴스)는 새로운 인증 기관으로 서명된 TLS 및 SSH 인증서를 제공하기 위해 다시 로드하고 시작하지만 여전히 원래 인증 기관에서 발급된 인증서를 수락합니다. 이 단계는 host CA에만 적용됩니다.
-
전환을 실행하세요:
tctl auth rotate --manual --type=type --phase=update_servers업데이트된 회전 단계는 "update_servers"입니다. 상태를 확인하려면 'tctl status'를 사용하세요.
tctl status클러스터 teleport.example.com버전 16.2.0호스트 CA 서버 회전 중 (모드: 수동, 시작됨: Sep 20 2023 01:44:36 UTC, 종료: Sep 21 2023 07:44:36 UTC)사용자 CA 업데이트된 적 없음데이터베이스 CA 업데이트된 적 없음db_client CA 업데이트된 적 없음openssh CA 업데이트된 적 없음jwt CA 업데이트된 적 없음saml_idp CA 업데이트된 적 없음oidc_idp CA 업데이트된 적 없음CA 핀 sha256:0000000000000000000000000000000000000000000000000000000000000000 -
회전 중인 CA에 의존하는 리소스를 구성하고 확인합니다. 이는
standby단계로 전환하기 전에 Teleport로 보호되는 리소스를 업데이트할 수 있는 마지막 기회입니다. -
Teleport로 보호되는 리소스에 대한 연결을 잃은 경우, 최종
standby단계에 들어가기 전에 회전 롤백을 수행하여 원래 인증 기관으로 되돌리세요. 최종standby단계로 들어간 후에는 롤백이 불가능합니다.
최종 standby
최종 점검을 하여 회전한 CA에 의존하는 Teleport로 보호되는 리소스에 대한 액세스를 잃지 않았는지 확인합니다.
-
전환을 실행하세요:
tctl auth rotate --manual --type=type --phase=standby -
tctl로 회전이 완료되었는지 확인하세요:tctl status클러스터 teleport.example.com버전 16.2.0호스트 CA Sep 20 2023 02:11:25 UTC에 회전됨사용자 CA 업데이트된 적 없음데이터베이스 CA 업데이트된 적 없음db_client CA 업데이트된 적 없음openssh CA 업데이트된 적 없음jwt CA 업데이트된 적 없음saml_idp CA 업데이트된 적 없음oidc_idp CA 업데이트된 적 없음CA 핀 sha256:0000000000000000000000000000000000000000000000000000000000000000 -
회전한 CA에 의존하는 Teleport로 보호되는 리소스에 연결할 수 있는지 확인하기 위한 CA에 대한 지침을 따릅니다. 이 단계는 롤백할 수 있는 마지막 기회입니다. Teleport로 보호되는 리소스에 대한 연결을 잃은 경우, 회전 롤백을 수행하여 원래 인증 기관으로 되돌리세요.
3단계/4. [선택 사항] 반자동 회전 실행
Teleport에 CA 회전을 반자동으로 관리하게 할 수 있습니다. 반자동 회전은 회전의 각 단계를 자동으로 전환하며, 각 단계에서 tctl auth rotate 명령을 실행할 필요가 없습니다. 유예 기간이 경과하면 Teleport Auth Service는 CA 회전의 단계를 다음 단계로 업데이트합니다.
반자동 회전을 사용할지 결정하기
자동 단계 업데이트 외에도 반자동 회전은 수동 회전과 동일합니다. 운영자가 유예 기간 경과 전에 현재 단계에 맞게 인프라를 업데이트해야 합니다.
Teleport는 CA에 의존하는 인프라의 상태를 확인하지 않으므로, 문제가 발생하면 연결을 잃을 수 있습니다. 따라서 CA를 인프라에 내보내야 하는 경우 반자동 회전을 수행하지 않는 것이 좋습니다.
모든 엣지 케이스와 위험을 이해하기 위해 먼저 수동 모드에서 회전을 완료한 후 반자동 회전을 시도하십시오.
반자동 회전 시작
반자동 회전을 실행하려는 경우 tctl로 시작하고 회전 상태를 모니터링합니다.
반자동 회전을 트리거하려면 다음 명령을 사용할 수 있습니다:
tctl auth rotate --type=type
이 명령은 기본 유예 기간으로 48시간의 회전 프로세스를 트리거합니다.
추가 플래그로 유예 기간 및 CA 유형을 사용자 정의할 수 있습니다:
유예 기간을 200시간으로 설정하여 사용자 인증서만 회전:
tctl auth rotate --type=user --grace-period=200h유예 기간을 8시간으로 설정하여 호스트 인증서만 회전:
tctl auth rotate --type=host --grace-period=8h
host CA를 회전할 때 유예 기간 선택에 주의하세요.
유예 기간은 클러스터 내 모든 에이전트와 Proxy Service 인스턴스가 새로운 인증서를 요청할 수 있을 만큼 길어야 합니다. 회전 중 일부 호스트가 오프라인 상태로 있다가 유예 기간이 끝난 후에 돌아오면 클러스터에서 강제로 떠나게 됩니다.
반자동 회전 중 Teleport는 유예 기간을 구분하여 각 단계에서 동일한 시간만큼 보내고 다음 단계로 전환합니다. 따라서 짧은 유예 기간을 사용할 경우 상태 전환이 빨라지게 됩니다.
4단계/4. [선택 사항] 회전 롤백
회전이 standby 상태에 들어가기 전에 롤백을 수행해야 합니다.
-
수동 단계 전환으로 롤백 단계에 들어갑니다:
tctl auth rotate --phase=rollback --type=type --manual업데이트된 회전 단계는 "rollback"입니다. 상태를 확인하려면 'tctl status'를 사용하세요.
-
회전 중이었던 CA에 의존하는 Teleport 리소스에 연결할 수 있는지 확인합니다.
-
CA 회전 롤백을 완료합니다:
tctl auth rotate --phase=standby --type=type --manual업데이트된 회전 단계는 "standby"입니다. 상태를 확인하려면 'tctl status'를 사용하세요.
추가 읽기
Teleport 인증 기관 작동 방식.