신뢰할 수 있는 클러스터 구성 | Teleport 공식 기술 문서 한국판 by 인포그랩

신뢰할 수 있는 클러스터 구성

Note

신뢰할 수 있는 클러스터는 자가 호스팅된 Teleport 클러스터에서만 사용할 수 있습니다.

코어 개념에서 배운 것처럼, Teleport 클러스터는 Teleport Auth 서비스, Teleport Proxy 서비스, 및 인프라 내 리소스에 대한 액세스를 관리하는 Teleport 서비스로 구성됩니다. Teleport를 사용하면 한 클러스터의 사용자가 루트 클러스터에서 다른 클러스터인 리프 클러스터의 리소스에 연결할 수 있도록 인프라를 여러 연결된 클러스터로 분할할 수도 있습니다. 이 과정에서 단일 Teleport Auth 서비스를 사용하여 인증을 수행합니다.

루트 클러스터와 리프 클러스터 간의 신뢰 관계를 설정한 후에는 리프 클러스터가 방화벽 뒤에서 어떤 수신 포트도 열지 않고 실행될 수 있습니다. 리프 클러스터는 루트 클러스터로의 아웃바운드 리버스 SSH 터널을 생성하고 터널을 열어 둡니다. 사용자가 리프 클러스터의 리소스에 연결하려고 하면, 리프 클러스터의 Teleport Auth 서비스가 루트 클러스터로 리버스 터널을 통해 연결을 시도합니다.

Warning

루트 클러스터와 리프 클러스터 간의 신뢰 관계가 설정되면, 루트 Proxy 서비스는 리프 Proxy 서비스에 임의의 주소에 대한 네트워크 연결을 설정하도록 요청할 수 있습니다. 이것이 루트 클러스터가 리프 클러스터의 리소스에 접근하는 방법입니다. 손상된 루트 Proxy 서비스는 리프 Proxy 서비스에게 민감하거나 권한이 없는 리소스에 연결하도록 요청할 수 있으므로, 리프 Proxy 서비스가 적절한 리소스에만 연결될 수 있도록 방화벽을 사용해야 합니다.

신뢰할 수 있는 클러스터를 사용하는 사람은 누구인가요?

대부분의 조직에서는 신뢰할 수 있는 클러스터를 구성할 필요가 없습니다. 대부분의 경우, 새 클러스터를 생성하지 않고도 수천 개의 리소스를 등록하고 관리하기 위해 여러 Teleport Proxy 서비스 인스턴스를 추가할 수 있습니다.

그러나 신뢰할 수 있는 클러스터가 특히 유용하게 사용될 수 있는 몇 가지 특정 시나리오가 있습니다. 예를 들어, 대규모이고 분산된 인프라를 보유하거나 외부 기관, 계약자 또는 클라이언트의 리소스에 대한 액세스를 제공해야 하는 경우에는 신뢰할 수 있는 클러스터를 설정하는 것이 이득이 될 수 있습니다. 신뢰할 수 있는 클러스터의 가장 일반적인 사용 사례는 다음과 같습니다.

관리 서비스 제공업체(MSP)가 고객의 인프라를 원격으로 관리하는 경우.
장치 제조업체가 현장에서 배포된 컴퓨팅 장비를 원격으로 유지 관리하는 경우.
대규모 클라우드 소프트웨어 공급업체가 공통 프록시를 사용하는 여러 데이터 센터를 관리하는 경우.

작동 방식

다음 예제에서는 관리 서비스 제공업체가 서로 다른 지역의 고객에게 액세스를 제공하기 위해 세 개의 독립적인 클러스터를 사용하는 경우를 보여줍니다.

클러스터 msp-root.example.com은 루트 클러스터입니다. 이 클러스터는 자체 리소스를 보유하거나 오로지 감사 로그를 수집하고 사용자를 인증하는 데만 사용될 수 있습니다.
클러스터 leaf-east.example.com과 leaf-west.example.com은 서로 다른 지역의 고객에게 서비스를 제공하는 두 개의 독립적인 리프 클러스터입니다.
각 클러스터는 독립적인 x.509 및 SSH 인증서 권한 기관이며 자율적으로 운영될 수 있습니다.
각 리프 클러스터는 루트 클러스터에 리버스 터널을 설정합니다. 여러 Proxy 서비스 인스턴스가 있는 경우, 고가용성을 위해 여러 개의 터널이 생성됩니다.

다음 다이어그램은 아키텍처의 단순화된 모습을 제공합니다.

이 다이어그램이 시사하는 바와 같이, 사용자는 루트 클러스터에 로그인하여 루트 클러스터 인증 기관에 의해 서명된 인증서를 받을 수 있습니다. 그런 다음 사용자는 리프 클러스터에 직접 연결하거나 루트 클러스터가 바스티온 호스트 역할을 하도록 하여 리프 클러스터에 연결할 수 있습니다. 사용자가 로그인한 후, 인증서의 정보와 사용자의 루트 클러스터 내 역할이 리프 클러스터의 역할과 매핑되는 방식에 따라 리프 클러스터에서 인식되고 신뢰받을 수 있습니다.

리프 클러스터의 Teleport Auth 서비스는 사용자가 액세스할 수 있는 리소스를 다음 정보를 확인하여 결정합니다:

사용자가 사용하도록 허가된 원장(principals) 목록. 원장은 Teleport 사용자 프로필에 추가된 로컬 로그인과 동등합니다.
인증서를 발급한 인증서 권한 기관의 서명. 신뢰할 수 있는 클러스터 환경에서 루트 클러스터의 Teleport Auth 서비스가 인증서에 서명합니다.
Teleport Auth 서비스에서 제공하는 메타데이터 인증서 확장. Teleport는 메타데이터를 사용하여 사용자 역할 및 permit-agent-forwarding과 같은 SSH 옵션 목록을 저장합니다.
인증서의 만료일 또는 유효 기간(TTL), 인증서가 여전히 유효한지 확인합니다.

인증서의 정보를 바탕으로 Teleport Auth 서비스는 다음 작업을 수행합니다:

인증서 서명이 신뢰할 수 있는 루트 클러스터 중 하나와 일치하는지 확인합니다.
역할 매핑을 적용하여 리프 클러스터의 역할과 루트 클러스터에 할당된 역할을 연결합니다.
로컬 역할이 요청된 신원을 없람할 수 있도록 허용되었는지 확인합니다 — Unix 로그인에 대한 액세스입니다.
인증서가 만료되지 않았는지 확인합니다. TTL은 루트 클러스터에 의해 설정됩니다.

다음 다이어그램은 리프 클러스터에서 실행 중인 서비스와 루트 클러스터에서 실행 중인 서비스 간의 상호 작용의 단순화된 모습을 제공합니다.

신뢰할 수 있는 클러스터는 한 방향으로만 작동합니다. 리프 클러스터의 사용자는 루트 클러스터 내의 리소스를 볼 수 없거나 연결할 수 없습니다.

신뢰할 수 있는 클러스터의 역할 관계

리프 클러스터는 자율적이며 자신의 상태, 역할 및 로컬 사용자를 보유하고 있습니다. 이러한 자율성은 리프 클러스터 관리자가 외부 사용자의 신원을 자체 클러스터 역할에 매핑하는 방법을 결정할 수 있게 해줍니다. 다음 다이어그램은 msp-root.example.com을 루트 클러스터로, leaf-east.example.com을 리프 클러스터로 사용하여 역할 매핑이 작동하는 단순화된 모습을 보여줍니다.

이 예제에서 사용자 Alice는 msp-root.example.com 루트 클러스터에 로그인합니다. 루트 클러스터는 그녀의 신원 및 그룹 구성원을 인증하는 단일 로그온(identity provider)을 구성합니다. 신원 제공자로부터의 정보를 바탕으로 루트 클러스터는 Alice에게 full-access 역할을 부여하고 인증서를 발급합니다. 단일 로그온 속성을 Teleport 역할에 매핑하는 것은 Teleport 클러스터에 인증 커넥터를 추가할 때 설정됩니다. 외부 신원 제공자를 통한 단일 로그온 구성에 대한 자세한 내용은 단일 로그온 구성을 참조하세요.

Alice는 루트 클러스터에서 그녀에게 할당된 역할을 명시하는 인증서를 받습니다. 그녀의 역할에 대한 메타데이터는 인증서 확장에 포함되어 있으며, 루트 클러스터 인증서 권한 기관의 서명으로 보호되어 변조될 수 없습니다.

Alice가 리프 클러스터 leaf-east.example.com의 리소스에 연결할 때, 외부 인증 기관에서 서명한 인증서를 가진 외부 사용자로 식별됩니다. 리프 클러스터의 역할 매핑 규칙에 따라 Alice는 stage-access 역할을 부여받습니다. 이 역할은 그녀가 mongodb.stage.example.com에는 접근할 수 있지만, mongodb.prod.example.com에는 접근할 수 없도록 합니다.

루트 클러스터의 역할	리프 클러스터에서의 매핑 역할
full-access	stage-access

이 예제에서 리프 클러스터 leaf-east.example.com은 Alice가 full-access 역할이 stage-access 역할로 매핑되었기 때문에 mongodb.prod.example.com 리소스에 대한 접근을 거부합니다. 역할 매핑을 통해 리프 클러스터 관리자는 외부 사용자에게 부여된 권한을 제어할 수 있습니다. 역할 매핑은 사용자를 루트 클러스터와 리프 클러스터에서 동일한 역할로 할당하는 것만큼 간단할 수도 있지만, 사용자의 권한을 낮추는 방식으로 매핑을 사용하는 것도 가능합니다.

이제 신뢰할 수 있는 클러스터가 무엇인지, 어떻게 작동하는지 알았으니, 다음 가이드를 사용하여 배우십시오:

루트 클러스터와 리프 클러스터 식별하기.
신뢰할 수 있는 클러스터 리소스 추가하기.
루트 클러스터와 리프 클러스터 간의 신뢰 관계를 설정하기 위해 초대 토큰 생성하기.
Teleport 역할을 사용하여 클러스터 간 권한 매핑 설정하기.
클러스터 간 신뢰 설정 및 비활성화하기.

전제 조건

이 가이드의 단계를 완료하려면 환경이 다음 요구 사항을 충족하는지 확인하십시오:

두 개의 Teleport 클러스터 인스턴스에 대한 액세스.

두 클러스터는 동일한 버전이어야 하며, 리프 클러스터는 루트 클러스터 버전보다 한 가지 주요 버전 정도 뒤에 있을 수 있습니다.
tctl 관리자 도구와 tsh 클라이언트 도구 버전 >= 16.2.0.

Teleport Enterprise 및 Teleport Enterprise 클라우드의 경우, tctl과 tsh의 엔터프라이즈 버전을 설치해야 합니다. 설치된 도구를 확인하려면 다음 명령을 실행하십시오:
```
tctl version
Teleport Enterprise v16.2.0 go1.22

tsh version
Teleport v16.2.0 go1.22
```
Teleport 설치에 대한 자세한 내용은 설치를 참조하십시오.
리프 클러스터로 사용할 클러스터에 가입된 Teleport SSH 서버. 클러스터에서 리소스를 등록하는 방법에 대한 정보는 클러스터에 서비스 가입을 참조하십시오.

프로덕션에서 Teleport를 실행할 때 보안 사고를 피하기 위해 다음 모범 사례를 준수해야 합니다:

필요한 경우가 아니면 프로덕션 환경에서 sudo 사용을 피하세요.
새로운 비루트 사용자 계정을 생성하고 Teleport 실험을 위해 테스트 인스턴스를 사용하세요.
필요하지 않는 한 비루트 사용자로서 Teleport의 서비스를 실행하세요. SSH 서비스만 루트 접근을 필요로 합니다. Teleport가 1024보다 작은 포트(예: 443)에서 수신 대기하도록 하려면 루트 권한(또는 CAP_NET_BIND_SERVICE 권한)이 필요합니다.
최소 권한 원칙을 따르세요. 더 제한적인 역할로도 충분할 때 사용자의 권한을 허용하는 역할을 부여하지 마세요. 예를 들어, 사용자가 모든 클러스터 리소스에 액세스하고 편집할 수 있는 내장된 access,editor 역할을 부여하지 마세요. 대신 각 사용자에게 필요한 최소 권한을 가진 역할을 정의하고 액세스 요청을 구성하여 일시적으로 권한을 상승시켜주세요.
Teleport 리소스를 등록할 때(예: 새로운 데이터베이스나 응용 프로그램) 초대 토큰을 파일에 저장해야 합니다. 명령행에 토큰을 직접 입력하면 악의적인 사용자가 손상된 시스템에서 history 명령을 실행하여 이를 볼 수 있습니다.

이러한 관행이 문서에서 사용되는 예제에 반드시 반영되지 않는 점에 유의해야 합니다. 문서의 예제는 주로 시연 및 개발 환경을 위한 것입니다.

1단계/6. 리프 클러스터 환경 준비

이 가이드는 루트 클러스터의 사용자가 리프 클러스터의 서버에 특정 사용자 신원과 역할로 액세스할 수 있도록 하는 방법을 보여줍니다. 이 예제에서는 리프 클러스터의 서버에 접근하는 데 사용할 수 있는 사용자 신원이 visitor입니다. 따라서 환경을 준비하려면 먼저 visitor 사용자와 해당 사용자 이름으로 서버에 로그인할 수 있도록 Teleport 역할을 생성해야 합니다.

신뢰할 수 있는 클러스터에 대한 액세스를 위한 사용자와 역할을 추가하려면:

리프 클러스터에서 Teleport 에이전트가 실행 중인 서버의 터미널 셸을 엽니다.
다음 명령을 실행하여 로컬 visitor 사용자를 추가하고 사용자의 홈 디렉토리를 생성합니다:
```
sudo useradd --create-home visitor
```
홈 디렉토리는 visitor 사용자가 서버에서 셸에 접근하기 위해 필요합니다.
다음 명령을 실행하여 모든 사용자 로그인 및 클러스터에서 로그아웃합니다:
```
tsh logout
```
관리 작업대에서 Teleport 사용자 이름을 사용하여 리프 클러스터에 로그인합니다:
```
tsh login --proxy=leafcluster.example.com --user=myuser
```
leafcluster.example.com을 Teleport 리프 클러스터 도메인으로 바꾸고 myuser를 Teleport 사용자 이름으로 바꾸십시오.
다음 내용을 가진 visitor.yaml이라는 역할 정의 파일을 생성합니다:
```
kind: role
version: v5
metadata:
  name: visitor
spec:
  allow:
    logins:
      - visitor
    node_labels:
      '*': '*'
```
사용자가 Teleport 에이전트가 실행 중인 서버에서 SSH로 접근할 수 있도록 노드에 대한 액세스를 명시적으로 허용해야 합니다. 이 예제에서는 visitor 로그인이 모든 서버에 접근할 수 있도록 허용됩니다.
다음 명령을 실행하여 visitor 역할을 생성합니다:
```
tctl create visitor.yaml
```
이제 리프 클러스터에 visitor 역할이 있으며, visitor 역할은 visitor 로그인을 가진 사용자가 리프 클러스터에 있는 노드에 접근할 수 있도록 해줍니다. 다음 단계에서는 사용자가 리프 클러스터의 서버에 접근하기 위해 역할 조건을 충족하도록 visitor 로그인을 사용자에게 추가해야 합니다.

2단계/6. 루트 클러스터 환경 준비

리프 클러스터의 서버에 대한 액세스를 테스트하기 전에, visitor 로그인 할당을 가질 수 있는 Teleport 사용자가 필요합니다. 인증은 루트 클러스터에서 처리되므로, 루트 클러스터에 있는 사용자에게 visitor 로그인을 추가해야 합니다.

Teleport 사용자에게 로그인을 추가하려면:

다음 명령을 실행하여 모든 사용자 로그인 및 클러스터에서 로그아웃합니다:
```
tsh logout
```
관리 작업대에서 Teleport 사용자 이름을 사용하여 루트 클러스터에 로그인합니다:
```
tsh login --proxy=rootcluster.example.com --user=myuser
```
rootcluster.example.com을 Teleport 루트 클러스터 도메인으로 바꾸고 myuser를 Teleport 사용자 이름으로 바꾸십시오.
다음과 비슷한 명령을 실행하여 현재 사용자 구성으로 user.yaml 파일을 생성합니다:
```
tctl get user/myuser > user.yaml
```
myuser를 Teleport 사용자 이름으로 바꾸십시오.
텍스트 편집기에서 user.yaml 파일을 열고 visitor 로그인을 추가합니다:
```
   traits:
     logins:
+    - visitor
     - ubuntu
     - root
```
다음 명령을 실행하여 변경 사항을 적용합니다:
```
tctl create -f user.yaml
```

3단계/6. 클러스터 간 신뢰 설정

루트 클러스터의 사용자가 visitor 역할을 사용하여 리프 클러스터의 서버에 액세스할 수 있으려면, 클러스터 간의 신뢰 관계를 정의해야 합니다. Teleport는 루트 클러스터와 리프 클러스터 간의 신뢰를 초대 토큰을 사용하여 설정합니다.

클러스터 간 신뢰를 설정하려면, 먼저 루트 클러스터의 Teleport Auth 서비스에서 초대 토큰을 생성해야 합니다. 그런 다음, 리프 클러스터의 Teleport Auth 서비스를 사용하여 초대 토큰을 포함하는 trusted_cluster 리소스를 생성하여, 리프 클러스터가 등록할 클러스터라는 것을 루트 클러스터에 증명하게 됩니다.

신뢰 관계를 설정하려면:

다음 명령을 실행하여 모든 사용자 로그인 및 클러스터에서 로그아웃합니다:
```
tsh logout
```
관리 작업대에서 Teleport 사용자 이름을 사용하여 루트 클러스터에 로그인합니다:
```
tsh login --proxy=rootcluster.example.com --user=myuser
```
rootcluster.example.com을 Teleport 루트 클러스터 도메인으로 바꾸고 myuser를 Teleport 사용자 이름으로 바꾸십시오.
다음 명령을 실행하여 초대 토큰을 생성합니다:
```
tctl tokens add --type=trusted_cluster --ttl=5m
신뢰할 수 있는 클러스터 초대 토큰: abcd123-insecure-do-not-use-this
```
이 명령은 리프 클러스터로의 인바운드 연결을 허용하는 신뢰할 수 있는 클러스터 초대 토큰을 생성합니다. 이 토큰은 여러 번 사용될 수 있습니다. 이 명령 예제에서는 토큰의 만료 시간이 5분입니다.

초대 토큰은 처음 연결을 설정하는 데만 사용됩니다. 클러스터는 인증서를 교환하며, 이후에는 토큰을 사용하여 연결을 재구성하지 않습니다.

나중에 사용할 수 있도록 토큰을 복사하십시오. 다시 토큰을 표시해야 하는 경우, 루트 클러스터에 대해 다음 명령을 실행하십시오:
```
tctl tokens ls
토큰                                                    유형            레이블   만료 시간 (UTC)-------------------------------------------------------- --------------- -------- ---------------------------abcd123-insecure-do-not-use-this                         trusted_cluster          28 Apr 22 19:19 UTC (4m48s)
```
다음 내용을 가진 trusted_cluster.yaml이라는 리소스 구성 파일을 생성합니다:
```
kind: trusted_cluster
version: v2
metadata:
  name: rootcluster.example.com
spec:
  enabled: true
  token: abcd123-insecure-do-not-use-this
  tunnel_addr: rootcluster.example.com:443
  web_proxy_addr: rootcluster.example.com:443
  role_map:
    - remote: "access"
      local: ["visitor"]
```
이 파일에서:
- metadata.name을 루트 클러스터의 이름으로 설정합니다.
- spec.token을 이전에 생성한 초대 토큰으로 설정합니다.
- spec.tunnel_addr을 Teleport Proxy 서비스의 리버스 터널 주소로 설정합니다.
- spec.web_proxy_addr을 루트 클러스터의 Teleport Proxy 서비스 주소로 설정합니다.
- spec.role_map을 사용하여 루트 클러스터의 Teleport 역할을 리프 클러스터의 역할과 매핑합니다.
클러스터 주소 확인

tunnel_addr 또는 web_proxy_addr와 같은 클러스터 설정에 대한 값을 확인할 수 없으면, JSON 파일에서 기계 가독성 데이터를 파싱하고 추출하는 명령줄 도구를 사용해 이 정보를 찾을 수 있습니다. 이러한 도구 중 가장 일반적인 것 중 하나는 jq입니다. 대부분의 운영 체제에서 jqlang 웹사이트에서 jq를 다운로드할 수 있습니다.

jq를 사용해 클러스터 주소를 가져오려면:
1. PROXY 환경 변수를 Teleport 클러스터 도메인으로 설정합니다:
```
PROXY=teleport.example.com
```
2. 다음 명령을 실행하여 클러스터의 tunnel_addr을 추출합니다:
```
curl https://$PROXY/webapi/ping | jq 'if .proxy.tls_routing_enabled == true then .proxy.ssh.public_addr else .proxy.ssh.ssh_tunnel_public_addr end'
```
3. 다음 명령을 실행하여 클러스터의 web_proxy_addr을 추출합니다:
```
curl https://$PROXY/webapi/ping | jq .proxy.ssh.public_addr
```
루트 클러스터 역할을 리프 클러스터 역할로 매핑하기

신뢰할 수 있는 클러스터 리소스 구성에서 role_map 설정을 사용하여 루트 클러스터의 역할을 리프 클러스터의 역할에 매핑할 수 있습니다. 이 예제에서는 루트 클러스터에 대해 access 역할이 부여된 사용자가 리프 클러스터에 로그인하려고 할 때 visitor 역할을 부여받도록 매핑됩니다. 이 역할 매핑을 통해 리프 클러스터의 리소스에 대한 접근을 제한할 수 있습니다.

Teleport 사용자가 루트 클러스터에서 access 역할이 부여된 경우, 사용자는 이 역할 매핑을 사용해 리프 클러스터의 서버에 접근할 수 있습니다. 만약 사용자가 access 역할이 부여되지 않았다면, role_map에서 access를 해당 사용자의 역할 중 하나로 변경하십시오.

역할 매핑은 신뢰할 수 있는 클러스터 내에서 액세스를 관리하는 데 상당히 유용합니다. 역할 매핑의 제한 사항 및 수용되는 구문에 대한 자세한 내용은 역할 매핑 구문 및 표현식을 참조하십시오.
루트 클러스터에서 로그아웃합니다:
```
tsh logout
```

4단계/6. 신뢰할 수 있는 클러스터 리소스 생성

이제 리프 클러스터에서 신뢰할 수 있는 클러스터 리소스를 생성할 준비가 되었습니다.

신뢰할 수 있는 클러스터 리소스를 생성하려면:

관리 작업대에서 Teleport 사용자 이름을 사용하여 리프 클러스터에 로그인합니다:
```
tsh login --proxy=leafcluster.example.com --user=myuser
```
leafcluster.example.com을 Teleport 리프 클러스터 도메인으로 바꾸고 myuser를 Teleport 사용자 이름으로 바꾸십시오.
다음 명령을 실행하여 리소스 구성 파일에서 신뢰할 수 있는 클러스터 리소스를 생성합니다:
```
tctl create trusted_cluster.yaml
```
leaf 클러스터를 Teleport 웹 UI에서 직접 구성할 수도 있습니다. 예를 들어, Management를 선택한 후 Trusted Clusters를 클릭하여 새 trusted_cluster 리소스를 생성 또는 기존의 신뢰할 수 있는 클러스터를 관리할 수 있습니다.
리프 클러스터에서 로그아웃한 후 루트 클러스터에 다시 로그인합니다.

다음 명령을 실행하여 신뢰할 수 있는 클러스터 구성을 확인합니다:

tsh clusters

이 명령은 다음과 유사한 출력으로 루트 클러스터와 리프 클러스터를 나열해야 합니다:

클러스터 이름                상태 클러스터 유형 레이블 선택됨 
--------------------------- ------ ------------ ------ -------- 
rootcluster.example.com     online root                *        
leafcluster.example.com     online leaf

5단계/6. 신뢰할 수 있는 클러스터에 대한 액세스 관리

trusted_cluster 리소스를 리프 클러스터에 생성할 때, 리프 클러스터의 Teleport Auth 서비스는 루트 클러스터의 Teleport Proxy 서비스에 신뢰할 수 있는 클러스터를 검증하는 요청을 보냅니다. 요청을 검증한 후 루트 클러스터는 신뢰할 수 있는 리프 클러스터를 나타내는 remote_cluster 리소스를 생성합니다.

루트 클러스터의 remote_cluster 리소스에 레이블을 추가하여 리프 클러스터에 대한 액세스를 관리할 수 있습니다. 리프 클러스터 자체에서 레이블을 관리할 수 없습니다. 각 리프 클러스터가 자체 레이블을 전파하면 악성 클러스터가 예기치 않은 값으로 자신의 레이블을 업데이트할 수 있는 문제가 발생할 수 있습니다.

리프 클러스터에 대한 액세스를 관리하려면:

다음 명령을 실행하여 루트 클러스터에 Teleport 사용자로 로그인되어 있는지 확인합니다:
```
tsh status
```

다음 명령을 실행하여 remote_cluster 리소스를 검색합니다:

tctl get rc

이 명령은 다음과 유사한 출력을 표시합니다:

kind: remote_cluster
metadata:
  id: 1651261581522597792
  name: leafcluster.example.com
status:
  connection: online
  last_heartbeat: "2022-04-29T19:45:35.052864534Z"
version: v3

다음과 유사한 명령을 실행하여 리프 클러스터에 레이블을 추가합니다:
```
tctl update rc/leafcluster.example.com --set-labels=env=demo
```
이 명령을 실행한 후에는 방금 설정한 레이블에 대해 클러스터에 접근하기 위해 명시적인 권한을 부여받아야 합니다. 신뢰할 수 있는 클러스터에 레이블이 설정된 경우, Teleport Auth 서비스는 설정된 레이블이 있는 클러스터에 대한 정보를 반환하지 않습니다.

env: demo 레이블에 대한 액세스를 허용하는 demo-cluster-access.yaml이라는 역할 구성 파일을 생성합니다:

kind: role
metadata:
  name: demo-cluster-access
spec:
  allow:
    cluster_labels:
      'env': 'demo'
version: v5

다음 명령을 실행하여 역할을 생성합니다:
```
tctl create demo-cluster-access.yaml
```
demo-cluster-access 역할을 Teleport 사용자에게 할당하려면 인증 제공자에 맞는 적절한 명령어를 실행하세요:
1. 로컬 사용자의 역할을 콤마로 구분된 목록으로 가져옵니다:
  
  ROLES=$(tsh status -f json | jq -r '.active.roles | join(",")')
2. 로컬 사용자를 편집하여 새로운 역할을 추가합니다:
  
  tctl users update $(tsh status -f json | jq -r '.active.username') \ --set-roles "${ROLES?},demo-cluster-access"
3. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.
1. github 인증 커넥터를 가져옵니다:
  
  tctl get github/github --with-secrets > github.yaml
  
  --with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 github.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 github.yaml 파일을 제거해야 합니다.
2. github.yaml을 편집하고 teams_to_roles 섹션에 demo-cluster-access을 추가합니다.
  
  이 역할에 매핑할 팀은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 하지만 팀에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 팀이어야 합니다.
  
  여기에 예시가 있습니다:
  
  teams_to_roles: - organization: octocats team: admins roles: - access + - demo-cluster-access
3. 변경 사항을 적용합니다:
  
  tctl create -f github.yaml
4. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 assum 하기 위해 다시 로그인합니다.
1. saml 구성 리소스를 가져옵니다:
  
  tctl get --with-secrets saml/mysaml > saml.yaml
  
  --with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 saml.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 saml.yaml 파일을 제거해야 합니다.
2. saml.yaml을 편집하고 attributes_to_roles 섹션에 demo-cluster-access을 추가합니다.
  
  이 역할에 매핑할 속성은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 그러나 그룹에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 그룹이어야 합니다.
  
  여기에 예시가 있습니다:
  
  attributes_to_roles: - name: "groups" value: "my-group" roles: - access + - demo-cluster-access
3. 변경 사항을 적용합니다:
  
  tctl create -f saml.yaml
4. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.
1. oidc 구성 리소스를 가져옵니다:
  
  tctl get oidc/myoidc --with-secrets > oidc.yaml
  
  --with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 oidc.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 oidc.yaml 파일을 제거해야 합니다.
2. oidc.yaml을 편집하고 claims_to_roles 섹션에 demo-cluster-access을 추가합니다.
  
  이 역할에 매핑할 클레임은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 그러나 그룹에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 그룹이어야 합니다.
  
  여기에 예시가 있습니다:
  
  claims_to_roles: - name: "groups" value: "my-group" roles: - access + - demo-cluster-access
3. 변경 사항을 적용합니다:
  
  tctl create -f oidc.yaml
4. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.
다음 명령을 실행하여 설정한 레이블로 리프 클러스터가 업데이트되었는지 확인합니다:
```
tctl get rc
```
이제 클러스터에 대한 에코리 역할을 부여받았으므로, 명령은 업데이트된 리소스 정보를 표시합니다:
```
kind: remote_cluster
metadata:
  id: 1651262381521336026
  labels:
    env: demo
  name: leafcluster.example.com
status:
  connection: online
  last_heartbeat: "2022-04-29T19:55:35.053054594Z"
version: v3
```

6단계/6. 리프 클러스터의 서버에 접근

이전에 생성한 trusted_cluster 리소스를 통해, 루트 클러스터 사용자로서 리프 클러스터의 서버에 로그인할 수 있습니다.

서버 접근을 테스트하려면:

다음 명령을 실행하여 루트 클러스터에 Teleport 사용자로 로그인되어 있는지 확인합니다:
```
tsh status
```

다음과 유사한 명령을 실행하여 Teleport 에이전트가 실행 중인 서버가 리프 클러스터에 가입되어 있는지 확인합니다:

tsh ls --cluster=leafcluster.example.com

이 명령은 다음과 유사한 출력을 표시합니다:

노드 이름       주소        레이블
--------------- -------------- ------------------------------------
ip-172-3-1-242  127.0.0.1:3022 hostname=ip-172-3-1-242                                                                    
ip-172-3-2-205  ⟵ 터널      hostname=ip-172-3-2-205

visitor 로그인을 사용하여 안전한 셸 연결을 엽니다:
```
tsh ssh --cluster=leafcluster.example.com visitor@ip-172-3-2-205
```

다음 명령을 실행하여 리프 클러스터의 서버에서 visitor 사용자로 로그인되었는지 확인합니다:

pwd
/home/visitoruname -a
Linux ip-172-3-2-205 5.15.0-1041-aws #46~20.04.1-Ubuntu SMP Wed Jul 19 15:39:29 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

역할 매핑 구문 및 표현식

이 가이드에서는 역할 매핑의 간단한 예제를 보았습니다. 그러나 신뢰할 수 있는 클러스터에 대한 더 정교한 역할 매핑을 와일드카드, 정규 표현식, 역할 템플릿 변수, 공유 사용자 특성 및 레이블을 사용하여 정의할 수 있습니다. 다음 섹션에서는 신뢰할 수 있는 클러스터에서의 역할 매핑에 대한 추가 세부 정보를 제공하고 더 복잡한 역할 매핑 구문을 사용하는 예를 제공합니다.

와일드카드 문자

역할 매핑에서 별표(*)는 문자열의 임의의 개수의 문자를 일치시킬 수 있는 와일드카드 문자입니다. 예를 들어, 루트 클러스터의 모든 사용자가 리프 클러스터에 연결할 수 있도록 하려면 다음과 같이 role_map에서 와일드카드 *를 사용할 수 있습니다:

role_map:
  - remote: "*"
    local: [access]

다음 예제는 루트 클러스터에서 cluster-로 시작하는 모든 역할이 리프 클러스터에서 역할 clusteradmin으로 매핑됨을 설명합니다:

role_map:
   - remote: 'cluster-*'
     local: [clusteradmin]

정규 표현식

정규 표현식을 사용하여 사용자 역할을 한 클러스터에서 다른 클러스터로 매핑할 수도 있습니다. 정규 표현식 구문을 사용하면 원격 역할 이름의 일부가 정규 표현식과 일치하는 경우 해당 지역 역할에 매핑할 수 있습니다. 다음 예제에서는 원격 사용자가 remote-one이라는 원격 역할을 가질 때 이를 local-one로, remote-two는 local-two로 매핑합니다:

  - remote: "^remote-(.*)$"
    local: [local-$1]

정규 표현식 매칭은 표현식이 ^로 시작하고 $로 끝날 때만 활성화됩니다.

정규 표현식은 Google의 re2 구문을 사용합니다. 자세한 내용은 re2 구문 안내서를 참조하십시오.

신뢰할 수 있는 클러스터 간 사용자 특성 공유

신뢰할 수 있는 클러스터 간에 사용자 SSH 로그인, Kubernetes 사용자 및 그룹, 데이터베이스 사용자 및 이름을 공유할 수 있습니다. 예를 들어, 루트 클러스터에 root라는 역할과 다음과 같은 허용 규칙이 있다고 가정해 보겠습니다:

logins: ["root"]
kubernetes_groups: ["system:masters"]
kubernetes_users: ["alice"]
db_users: ["postgres"]
db_names: ["dev", "metrics"]

신뢰할 수 있는 클러스터 관계를 설정할 때 리프 클러스터는 이 root 클러스터 역할을 자체 admin 역할에 매핑할 수 있습니다:

role_map:
- remote: "root"
  local: ["admin"]

이제 리프 클러스터의 admin 역할을 다음 변수를 사용하여 루트 클러스터의 역할 로그인, Kubernetes 그룹 및 기타 특성을 사용할 수 있도록 설정할 수 있습니다:

logins: ["{{internal.logins}}"]
kubernetes_groups: ["{{internal.kubernetes_groups}}"]
kubernetes_users: ["{{internal.kubernetes_users}}"]
db_users: ["{{internal.db_users}}"]
db_names: ["{{internal.db_names}}"]

신원 제공자로부터 오는 사용자 특성(예: OIDC 주장 또는 SAML 속성)도 리프 클러스터에 전달되며, external 변수 접두사를 사용하여 역할 템플릿에서 사용할 수 있습니다. 예를 들어:

logins: ["{{internal.logins}}", "{{external.logins_from_okta}}"]
node_labels:
  env: "{{external.env_from_okta}}"

Teleport 역할에서 변수 확장이 작동하는 방식에 대한 전체 세부 정보는 Teleport 액세스 제어 참조를 참조하세요.

역할 매핑 업데이트

신뢰할 수 있는 클러스터 리소스의 역할 매핑은 trusted_cluster.yaml 리소스 구성 파일에 있는 role_map 필드를 수정하여 업데이트할 수 있습니다. 리소스 구성 파일을 업데이트한 후, 리프 클러스터에 로그인하고 다음 명령을 실행하여 신뢰할 수 있는 클러스터를 업데이트할 수 있습니다:

tctl create --force trusted_cluster.yaml

역할 매핑 및 클러스터 수준 레이블

이 가이드에서는 역할 매핑과 레이블을 결합하여 리프 클러스터 리소스에 대한 액세스를 관리하는 방법을 배웠습니다. 루트 클러스터의 인증서를 사용하여 리프 클러스터에 직접 연결할 수 있다는 점에 유의해야 합니다. 리프 클러스터는 루트 클러스터를 본질적으로 신뢰하므로, 루트 클러스터에서 발급된 인증서는 리프 클러스터에 대한 접근을 제한하기 위해 의도된 특정 cluster_labels 설정을 우회하는 데 사용될 수 있습니다. 예를 들어, 리프 클러스터에 다음 명령을 사용하여 레이블을 할당했다고 가정합니다:

tctl update rc/leaf --set-labels=env=prod

이 레이블은 사용자가 루트 클러스터에서 서명된 인증서를 가지고 있는 경우 리프 클러스터에 대한 직접 액세스를 방지할 수 없습니다. 역할 매핑을 신뢰할 수 있는 클러스터의 액세스를 제한하는 주된 방법으로 사용하고, cluster_labels를 사용하여 리프 클러스터 리소스의 가시성을 필터링하고 제한해야 합니다.

신뢰할 수 있는 클러스터 일시적으로 비활성화하기

클러스터의 신뢰 관계를 일시적으로 비활성화하려면, 리프 클러스터에 로그인하여 이전에 생성한 trusted_cluster 리소스 구성 파일을 수정합니다.

신뢰를 일시적으로 비활성화하려면:

관리 작업대에서 Teleport 사용자 이름을 사용하여 리프 클러스터에 로그인합니다:
```
tsh login --proxy=leafcluster.example.com --user=myuser
```
leafcluster.example.com을 Teleport 리프 클러스터 도메인으로 바꾸고 myuser를 Teleport 사용자 이름으로 바꾸십시오.

다음 명령을 실행하여 리소스 구성을 검색합니다:

tctl get trusted_cluster/rootcluster.example.com > trusted_cluster.yaml

spec.enabled 필드를 false로 설정합니다:

 spec:
-  enabled: true
+  enabled: false
   role_map:
   - local:
     - visitor

다음 명령을 실행하여 신뢰할 수 있는 클러스터 구성을 업데이트합니다:
```
tctl create --force trusted_cluster.yaml
```
이 명령은 리프 클러스터와 루트 클러스터 간의 리버스 터널을 종료합니다. 또한 리프 클러스터의 루트 클러스터 인증서 권한 기관이 비활성화됩니다.

리프 클러스터와 루트 클러스터 간의 신뢰 관계를 재설정하려면 spec.enabled를 true로 변경하는 단계를 반복할 수 있습니다.

Kubernetes 클러스터에 대한 접근을 연합하기

Kubernetes 클러스터가 독립적으로 운영되어야 하는 경우가 있습니다. 예를 들어, 이는 서로 다른 조직의 일부이거나 간헐적인 연결을 가지는 클러스터일 수 있습니다.

신뢰할 수 있는 클러스터를 이용하여 Kubernetes 클러스터 간 신뢰를 연합할 수 있습니다.

여러 신뢰할 수 있는 클러스터가 Teleport Proxy 서비스 뒤에 있을 때, tsh login으로 생성된 kubeconfig는 tsh login 명령의 <cluster> 인수에 따라 결정된 Kubernetes API 엔드포인트를 포함합니다.

예를 들어, 다음 시나리오를 고려해 보십시오:

east와 west라는 두 Teleport 클러스터와 동일한 이름을 가진 두 Kubernetes 클러스터가 있습니다. 각 Teleport 클러스터는 cluster_name 필드에 이름이 지정된 자체 구성 파일을 가지고 있습니다.
클러스터 east와 west는 Teleport Team 또는 Enterprise Cloud 계정인 example.teleport.sh를 신뢰하는 리프 클러스터입니다.
사용자는 항상 example.teleport.sh 인증을 하지만, 세 클러스터 모두의 SSH 노드 및 Kubernetes API에 액세스하기 위해 인증서를 사용합니다.

이 시나리오에서 사용자는 일반적으로 다음과 같은 명령을 사용하여 로그인합니다:

루트 클러스터에 로그인
tsh --proxy=mytenant.teleport.sh login

"east"에 대한 인증서를 받음
tsh --proxy=mytenant.teleport.sh login east

Teleport 클러스터와 동일한 이름의 Kubernetes 클러스터인 "east"에 로그인
tsh kube login --proxy=mytenant.teleport.sh --cluster=east east

사용자의 kubeconfig에는 이제 "east" Kubernetes 엔드포인트에 대한 항목이 포함됩니다.

신뢰할 수 있는 리프 클러스터 제거하기

리프 클러스터를 완전히 제거하고 나중에 복원할 가능성을 없애려면, 리프 클러스터와 루트 클러스터 모두에서 명령을 실행해야 합니다.

리프 클러스터를 완전히 제거하려면:

관리 작업대에서 Teleport 사용자 이름을 사용하여 리프 클러스터에 로그인합니다:
```
tsh login --proxy=leafcluster.example.com --user=myuser
```
leafcluster.example.com을 Teleport 리프 클러스터 도메인으로 바꾸고 myuser를 Teleport 사용자 이름으로 바꾸십시오.
다음 명령을 실행하여 리프 클러스터를 비활성화하고 제거합니다:
```
tctl rm trusted_cluster/rootcluster.example.com
```
이 명령은 trusted_cluster 리소스에 대해 spec.enabled를 false로 설정하고 Teleport Auth 서비스 백엔드에서 신뢰할 수 있는 클러스터 리소스를 제거합니다.
관리 작업대에서 Teleport 사용자 이름을 사용하여 루트 클러스터에 로그인합니다:
```
tsh login --proxy=rootcluster.example.com --user=myuser
```
rootcluster.example.com을 Teleport 루트 클러스터 도메인으로 바꾸고 myuser를 Teleport 사용자 이름으로 바꾸십시오.
원격 클러스터와 관련된 인증서 권한 기관을 삭제하고 Teleport Auth 서비스 베이스에서 remote_cluster 리소스를 제거하려면 다음 명령을 실행합니다:
```
tctl rm rc/leafcluster.example.com
```
이 명령을 리프 클러스터에서 신뢰 관계를 제거하지 않고 실행하면 리프 클러스터는 루트 클러스터에 계속 핑을 보내지만 연결할 수 없습니다. 신뢰할 수 있는 클러스터 관계를 재설정하려면 리프 클러스터에서 신뢰할 수 있는 클러스터를 다시 생성해야 합니다.

문제 해결

신뢰 관계를 구성할 때 발생할 수 있는 일반적인 문제는 다음 범주에 포함됩니다:

HTTPS 구성 문제.
연결 문제.
액세스 문제.

HTTPS 구성 문제

가장 일반적인 HTTPS 구성 문제는 루트 클러스터가 자체 서명된 또는 유효하지 않은 HTTPS 인증서를 사용하는 경우 발생합니다. 루트 클러스터의 web_proxy_addr 끝점이 자체 서명된 또는 유효하지 않은 HTTPS 인증서를 사용하는 경우, 신뢰할 수 있는 클러스터에는 잘못 구성된 HTTP/TLS 인증서가 있습니다.와 유사한 오류가 발생할 수 있습니다.

테스트의 용이성을 위해, 리프 클러스터에서 --insecure 커맨드라인 옵션으로 teleport 데몬을 시작하여 자체 서명된 인증서를 허용할 수 있습니다. 하지만, 문제를 해결하기 위해 HTTPS를 올바르게 구성한 후에는 프로덕션 환경에서 Teleport를 실행하기 전에 --insecure를 제거해야 합니다.

연결 문제

리프 클러스터가 루트 클러스터에서 tsh clusters 명령을 실행할 때 출력에 나타나지 않으면 네트워크 연결 문제 또는 Teleport Auth 서비스와의 통신 문제를 나타낼 수 있습니다.

연결 문제를 해결하기 위해, 루트 클러스터와 리프 클러스터 양쪽의 Teleport Auth 서비스에 대해 자세한 출력을 활성화합니다. 일반적으로, teleport start --debug 명령에 --debug 플래그를 추가하여 수행할 수 있습니다:

teleport start --debug`

또한 두 Auth 서비스의 구성 파일을 업데이트하여 상세 출력을 활성화할 수 있습니다. /etc/teleport.yaml 구성 파일을 열고 log 구성 섹션에 DEBUG를 추가합니다:

# /etc/teleport.yaml의 스니펫
teleport:
  log:
    output: stderr
    severity: DEBUG

systemd 기반 배포판에서는 다음 명령을 실행하여 로그 출력을 확인할 수 있습니다:

journalctl -fu teleport

대부분의 경우, 초대 토큰이 잘못되었거나 만료되었거나, tunnel_addr 또는 web_proxy_addr의 네트워크 주소가 방화벽 규칙이나 AWS의 네트워크 보안 그룹 구성 때문에 도달할 수 없는 경우를 찾게 됩니다.

액세스 문제

루트 클러스터의 사용자가 리프 클러스터의 노드에 연결하려고 할 때 Access denied 오류 메시지가 표시되면, 사용자 역할 할당, 역할 매핑 또는 허용된 로그인의 문제를 나타낼 수 있습니다 하며, Access denied 메시지를 해결하는 것이 상당히 어려울 수 있습니다. 문제 해결을 위해, 액세스가 거부된 사용자의 다음 정보를 확인해야 합니다:

사용자가 tsh login 명령으로 로그인할 때 루트 클러스터에 할당된 역할입니다. tsh status 명령을 실행하여 인증서와 할당된 역할을 검사할 수 있습니다.
역할 매핑이 이루어져 있는 리프 클러스터에서 사용자의 역할입니다. Teleport 감사 로그에서 역할 매핑을 확인할 수 있습니다.

Teleport를 자신의 네트워크에서 관리하는 경우, 감사 로그의 기본 위치는 Teleport 클러스터에 대한 Auth 서비스가 실행되는 서버의 /var/lib/teleport/log입니다.

Teleport를 관리형 클라우드 기반 서비스로 사용하는 경우, Teleport 웹 UI에서 Management를 선택하고 활동 섹션의 Audit Log를 클릭하여 감사 로그에 접근할 수 있습니다.

Teleport 원문 보기