인증 기관 회전 | Teleport 공식 기술 문서 한국판 by 인포그랩

인증 기관 회전

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 서비스가 새로운 CA를 사용하여 인증서를 서명하지만 원래 CA에 의해 서명된 인증서는 계속 신뢰함.
update_servers : Teleport 클러스터 구성 요소(에이전트, Auth 서비스 및 프록시 서비스 인스턴스)가 새 인증 기관에 의해 서명된 TLS 및 SSH 인증서를 다시 로드하고 제공하기 시작하지만 원래 인증 기관에 의해 발급된 인증서도 여전히 수락함. 이는 Teleport host CA에만 적용됩니다.
1. standby : 회전이 진행되지 않음. 모든 운영이 완료됨.

최종 standby 단계 이전에 회전을 rollback 단계로 전환할 수도 있으며, 이는 회전을 중단하고 원래 인증 기관으로 되돌아갑니다.

CA 회전은 수동 또는 반자동으로 수행될 수 있습니다. 수동 모드에서는 관리자가 Teleport Auth 서비스에 다음 단계로 진행하도록 지시해야 합니다. 단계 사이에 관리자는 각 변경에 맞게 인프라를 준비할 수 있습니다. 반자동 모드에서는 Teleport Auth 서비스가 각 단계를 자동으로 순환하며, 각 단계 사이에 유예 기간이 있습니다.

요구 사항

실행 중인 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 명령어를 실행할 수도 있습니다.

1/4단계. 회전할 CA 선택

CA를 회전할 때, CA에 의존하는 인프라가 연결을 잃지 않았는지 확인해야 합니다. 새 CA를 인프라에 내보내야 할 수도 있습니다. 아래의 CA 중 하나를 선택하여 마이그레이션 동안 이를 최신 상태로 유지하는 방법을 결정하십시오.

복잡성을 줄이기 위해 한 번에 하나의 CA만 회전할 것을 권장합니다. 예외는 db 와 db_client CA로, 함께 회전해야 합니다.

CA 유형	증명서 주체
`host`	Teleport 에이전트. Auth 서비스 및 프록시 서비스 인스턴스.
`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 Agents 및 Auth Service와 Proxy Service 인스턴스에 인증서를 발급하여 Teleport 클라이언트와 Teleport Auth Service가 이를 검증할 수 있도록 합니다.

Teleport Agents와 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"}

이 예제에서 Teleport 인스턴스인 terminal 은 상태를 init 단계로 업데이트했습니다. 이는 새로운 CA 공개 키를 다운로드했으며 상태 전이에 준비가 되었음을 의미합니다.

다음 리소스를 사용하여 host CA의 회전 상태를 각 에이전트 종류에서 확인하려면 tctl get 명령어를 사용할 수 있습니다:

역할	`tctl get` 값
애플리케이션 서비스	`app_server`
데이터베이스 서비스	`db_server`
쿠버네티스 서비스	`kube_server`
프록시 서비스	`proxies`
SSH 서비스	`nodes`
윈도우 데스크탑 서비스	`windows_desktop_service`

host CA 회전의 각 단계 동안 모든 Agents와 Proxy Service 인스턴스가 다음 단계로 진행하기 전에 목표 단계로 전환을 완료했는지 확인하십시오. 우리는 2단계에서 하는 단계에 대해 설명할 것입니다.

Teleport 프로세스를 Teleport Auth Service를 통해 클러스터에 조인하는 경우 각 Teleport 프로세스는 Auth Service를 신뢰하기 위해 CA 핀이 필요합니다. CA 핀은 각 host CA 회전 후 변경됩니다. host CA 회전 후 Teleport 서비스를 추가할 때 새 CA 핀을 사용해야 합니다.

`user`

user CA는 사용자가 Teleport에 인증할 때 인증서를 발급합니다. 또한 Windows 데스크탑과 Teleport SSH 서버에 연결하는 사용자를 위한 클라이언트 인증서를 서명합니다. Teleport 보호 서버와 Windows 데스크탑은 이 인증서를 사용합니다.

회전을 완료하고 최종 standby 단계에 도달하면, Teleport에 로그인한 사용자는 새로운 CA로부터 사용자 인증서를 받기 위해 재인증해야 하며, 그렇지 않으면 Teleport 클라이언트 명령이 실패합니다.

Windows 데스크탑을 Teleport에 등록한 경우, 가이드를 따르십시오 Teleport 사용자 CA를 내보내어 Windows Desktop Service가 RDP 호스트에 인증할 수 있도록 합니다. 회전 내내 등록된 데스크탑에 연결할 수 있는지 확인하십시오.

`db` 및 `db_client`

db 및 db_client CAs는 Teleport Database Service가 자체 호스팅 데이터베이스와 통신하는 데 사용하는 인증서를 발급합니다.

Teleport Database Service는 자신이 구성한 신뢰 인증서(CA)에 의해 서명된 인증서를 가지고 자체 호스팅 데이터베이스와 통신할 때 db_client CA에 의해 서명된 인증서를 제공합니다.

관리자는 자체 호스팅 데이터베이스가 db CA에 의해 서명된 인증서를 제시하도록 구성할 수 있으며, Database Service는 데이터베이스 서버가 진정한 Teleport 보호 리소스인지 확인하는 데 사용합니다. 또는 자체 호스팅 데이터베이스가 사용자 지정 CA에 의해 서명된 인증서를 제시할 수 있으며, 관리자는 Teleport Database Service가 해당 CA를 신뢰하도록 구성할 수 있습니다.

롤레이션 시작

Teleport 데이터베이스 서비스는 update_clients 단계에서 새롭게 발급된 CA가 발급한 클라이언트 인증서를 사용하여 데이터베이스에 연결합니다. update_clients 단계에서 자가 호스팅된 데이터베이스에 대한 액세스를 잃지 않기 위해서는 init 단계에서 데이터베이스를 재구성하고, update_clients 단계로 전환 후에도 여전히 데이터베이스에 액세스할 수 있는지 확인해야 합니다.

update_clients 롤레이션 단계로 진행하기 전에 데이터베이스를 구성하는 데 필요한 적절한 문서를 참조하십시오.

init 단계에서는 tctl auth sign 명령이 db CA와 db_client CA 간에 다릅니다. db_client CA를 회전시키면, 명령은 신뢰할 수 있는 CA 출력으로 원래와 새로운 인증 기관을 모두 표시합니다. db CA를 회전시키면, 명령은 새 데이터베이스 서버 인증서만 발급합니다.

db CA만 회전시키는 경우에는 init 단계에서 데이터베이스를 재구성할 필요는 없지만, 그렇게 해도 해가 되지 않습니다. 이 시점에서 데이터베이스를 재구성하지 않으면, 롤레이션 내의 어떤 시점에 그렇게 할 계획을 세워야 하며, 그렇지 않으면 최종 standby 단계로 전환 후 이러한 데이터베이스에 대한 액세스를 잃게 됩니다.

롤레이션 되돌리기

롤레이션을 되돌리고 싶을 가장 흔한 이유는 데이터베이스를 재구성할 수 없기 때문입니다. 데이터베이스를 재구성한 후에 연결 문제 발생 시, 데이터베이스를 잘못 구성했을 가능성이 높습니다.

롤레이션 중에 데이터베이스를 재구성한 경우, rollback 단계에서 standby 로 전환하기 전에 다시 재구성해야 합니다.

`openssh`

openssh CA는 Teleport에 등록된 OpenSSH 서버에 대한 인증서를 발급합니다. 클라이언트는 Teleport로 보호된 OpenSSH 서버에 연결할 때 이 인증서를 확인합니다.

수동 방법을 사용하여 OpenSSH 서버를 등록한 경우, 회전이 최종 standby 단계로 진행되기 전에 openssh CA를 내보내고 이를 OpenSSH 서버에 제공해야 합니다. 그렇지 않으면 Teleport 사용자는 수동 방법으로 클러스터에 등록한 OpenSSH 서버에 대한 액세스를 잃게 됩니다.

`jwt`

Teleport Auth 서비스는 JSON 웹 토큰에 서명하기 위해 jwt CA를 사용합니다. Teleport 애플리케이션 서비스는 Teleport로 보호된 애플리케이션에 전달되는 HTTP 메시지에 JSON 웹 토큰을 포함하며, 이는 jwt CA를 사용하여 토큰을 확인합니다.

Teleport에 웹 애플리케이션을 등록한 경우, 이러한 애플리케이션이 Teleport 애플리케이션 서비스에서 전송된 트래픽을 Teleport 인증 기관을 통해 JSON 웹 토큰을 확인하여 인증하는 경우, 이 애플리케이션이 회전된 CA를 계속 신뢰하도록 해야 합니다.

Teleport가 보호하는 JWT 애플리케이션은 Teleport jwt CA의 공개 키를 검색하는 두 가지 방법 중 하나를 사용합니다. 방법에 따라 init 단계 이후와 롤레이션이 최종 standby 단계에 도달하기 전 사이에 조치를 취해야 할 수도 있습니다:

애플리케이션이 Teleport Proxy 서비스의 /.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를 신뢰하도록 구성해야 합니다. XML 메타데이터 파일을 내보내고 이를 서비스 제공업체에서 사용할 수 있도록 하려면 SAML IdP 문서에 있는 지침을 따르십시오.

`oidc_idp`

oidc_idp CA는 Teleport OIDC IdP 통합에서 전송된 메시지에 서명합니다. 의존하는 당사자 (예: AWS)는 이러한 메시지를 검증하여 외부 감사 저장소, 자동 검색 및 액세스 그래프에 대한 AWS 동기화와 같은 기능을 위해 Teleport 계정을 인증합니다.

Teleport 프록시 서비스는 /.well-known/jwks-oidc 경로에서 OIDC IdP 통합에 대한 JSON 웹 키 세트를 제공합니다.

Teleport 프록시 서비스 웹 API의 /.well-known/jwks-oidc 경로는 항상 활성화되어 있습니다. Teleport 프록시 서비스는 엔드포인트를 자동으로 업데이트합니다.

다음의 /.well-known/openid-configuration 경로를 쿼리하고 jwks_uri 필드를 읽어 통합의 JSON 웹 키 세트의 전체 URL을 가져올 수 있습니다:

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 서비스가 선택한 유형의 새 인증 기관을 발급하지만 이를 사용하여 인증서를 서명하지는 않습니다.

호스트 인증 기관의 수동 회전을 시작합니다:

tctl auth rotate --manual --type=type --phase=init
"init"으로 회전 단계가 업데이트되었습니다. 상태를 확인하려면 'tctl status'를 사용하십시오.

활성 회전이 진행 중인지 확인하기 위해 tctl 을 사용합니다. 이 명령은 클러스터에서 Teleport Auth 서비스가 유지하는 모든 CA의 회전 상태를 출력합니다:

tctl status
클러스터       teleport.example.com버전          17.0.0-dev호스트 CA      초기화됨 (모드: 수동, 시작: Sep 20 01:44:36 UTC, 종료: Sep 21 2023 07:44:36 UTC)사용자 CA      업데이트되지 않음db 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 서비스는 새 CA를 사용하여 인증서에 서명하지만 원래 CA에서 서명한 인증서는 계속 신뢰합니다.

update_clients 단계로 전환합니다:

tctl auth rotate --manual --type=type --phase=update_clients
"update_clients"로 회전 단계가 업데이트되었습니다. 상태를 확인하려면 'tctl status'를 사용하십시오.
tctl status
클러스터       teleport.example.com버전          17.0.0-dev호스트 CA      클라이언트 회전 중 (모드: 수동, 시작: Sep 20 2023 01:44:36 UTC, 종료: Sep 21 2023 07:44:36 UTC)사용자 CA      업데이트되지 않음db CA         업데이트되지 않음db_client CA  업데이트되지 않음openssh CA    업데이트되지 않음jwt CA        업데이트되지 않음saml_idp CA   업데이트되지 않음oidc_idp CA   업데이트되지 않음CA 핀        sha256:0000000000000000000000000000000000000000000000000000000000000000

다음 단계로 진행하기 전에 CA에 의존하는 인프라를 확인하거나 업데이트하십시오.
리소스에 대한 연결이 끊어진 경우, 새 CA를 수용하도록 재구성해야 하는지 확인하십시오. 그로 인해 액세스가 복원되지 않거나 데이터베이스를 재구성할 수 없으면 롤백하여 원래 인증 기관으로 돌아가야 합니다.

`update_servers`

update_servers 단계 시작. 이 단계에서 Teleport 클러스터 구성 요소(에이전트, 인증 서비스 및 프록시 서비스 인스턴스)는 새 인증 기관에 의해 서명된 TLS 및 SSH 인증서를 다시 로드하고 제공하기 시작하지만, 여전히 원래 인증 기관에서 발급된 인증서를 수락합니다. 이 단계는 host CA에만 영향을 미칩니다.

전환 실행:

tctl auth rotate --manual --type=type --phase=update_servers
회전 단계가 "update_servers"로 업데이트되었습니다. 상태를 확인하려면 'tctl status'를 사용하십시오.

tctl status
Cluster       teleport.example.comVersion       17.0.0-devhost CA       서버 회전 중 (모드: 수동, 시작: 2023년 9월 20일 01:44:36 UTC, 종료: 2023년 9월 21일 07:44:36 UTC)user CA       업데이트되지 않음db CA         업데이트되지 않음db_client CA  업데이트되지 않음openssh CA    업데이트되지 않음jwt CA        업데이트되지 않음saml_idp CA   업데이트되지 않음oidc_idp CA   업데이트되지 않음CA pin        sha256:0000000000000000000000000000000000000000000000000000000000000000

회전하는 CA에 따라 리소스를 구성하고 확인합니다. 이는 standby 단계로 전환하기 전에 Teleport 보호 리소스를 업데이트할 수 있는 마지막 기회입니다.
Teleport 보호 리소스에 대한 연결을 잃어버린 경우, 최종 standby 단계에 들어가기 전에 원래 인증 기관으로 롤백합니다. 이 단계에서는 롤백이 더 이상 불가능합니다.

최종 `standby`

마무리하기 전에 회전한 CA에 의존하는 Teleport 보호 리소스에 대한 접근 권한을 잃지 않았는지 확인합니다.

전환 실행:

tctl auth rotate --manual --type=type --phase=standby

tctl 로 회전이 완료되었는지 확인합니다:

tctl status
Cluster       teleport.example.comVersion       17.0.0-devhost CA       2023년 9월 20일 02:11:25 UTC에 회전됨user CA       업데이트되지 않음db CA         업데이트되지 않음db_client CA  업데이트되지 않음openssh CA    업데이트되지 않음jwt CA        업데이트되지 않음saml_idp CA   업데이트되지 않음oidc_idp CA   업데이트되지 않음CA pin        sha256:0000000000000000000000000000000000000000000000000000000000000000

회전된 CA에 의존하는 Teleport 보호 리소스에 연결할 수 있도록 CA에 대한 지침을 따르십시오. 여기서 롤백할 수 있는 마지막 단계입니다. Teleport 보호 리소스에 대한 연결을 잃었다면, 원래 인증 기관으로 롤백하십시오.

3/4단계. [선택적] 반자동 회전 실행

Teleport에게 CA 회전을 반자동으로 관리하도록 지시할 수 있습니다. 반자동 회전은 회전의 단계 간 전환을 자동으로 수행하며, 각 단계마다 tctl auth rotate 명령을 실행할 필요가 없습니다. 유예 기간이 지나면 Teleport Auth 서비스가 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를 회전할 때 유예 기간을 선택할 때 주의하십시오.

유예 기간은 클러스터 내 모든 에이전트와 프록시 서비스 인스턴스가 새 인증서를 요청할 수 있을 만큼 충분히 길어야 합니다. 일부 호스트가 회전 중에 오프라인이 되고 유예 기간이 끝난 후에 돌아오면 클러스터에서 강제로 퇴출될 것입니다.

반자동 회전 중에 Teleport는 유예 기간을 나누어 각 단계에서 다음 단계로 전환되기 전에 동일한 시간을 보내도록 시도합니다. 이는 짧은 유예 기간을 사용할 경우 상태 전환이 더 빨리 이루어진다는 것을 의미합니다.

4/4단계. [선택 사항] 회전 롤백하기

회전이 standby 상태로 들어가기 전에 롤백을 수행해야 합니다.

수동 단계 전환으로 롤백 단계로 들어갑니다:

tctl auth rotate --phase=rollback --type=type --manual
회전 단계를 "롤백"으로 업데이트했습니다. 상태를 확인하려면 'tctl status'를 사용하세요.

회전 중이던 CA에 의존하는 Teleport 리소스에 연결할 수 있는지 확인합니다.

CA 회전 롤백을 완료합니다:

tctl auth rotate --phase=standby --type=type --manual
회전 단계를 "대기"로 업데이트했습니다. 상태를 확인하려면 'tctl status'를 사용하세요.

추가 읽기

Teleport 인증 기관 작동 방식.

Teleport 원문 보기

작동 원리

요구 사항

1/4단계. 회전할 CA 선택

host

user

db 및 db_client