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

루트 클러스터와 리프 클러스터 간에 신뢰 관계를 설정한 후, 리프 클러스터는 방화벽 뒤에서 수신 포트를 열지 않고 실행할 수 있습니다. 리프 클러스터는 루트 클러스터에 대한 아웃바운드 역 SSH 터널을 생성하고 이 터널을 유지합니다.
사용자가 리프 클러스터의 리소스에 연결하려고 할 때, 리프 클러스터의 Teleport Auth 서비스는 루트 클러스터의 Teleport 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 서비스는 다음 작업을 수행합니다:

• 인증서 서명이 신뢰하는 루트 클러스터 중 하나와 일치하는지 확인합니다.
• 역할 매핑을 적용하여 리프 클러스터의 역할과 루트 클러스터에서 사용자에게 할당된 역할을 연결합니다.
• 로컬 역할이 요청된 신원을 허용하는지—유닉스 로그인—확인합니다.
• 인증서가 만료되지 않았는지 확인합니다. TTL은 루트 클러스터에서 설정됩니다.

다음 다이어그램은 리프 클러스터에서 실행되는 서비스와 루트 클러스터에서 실행되는 서비스 간의 상호작용의 간략한 뷰를 제공합니다:

신뢰할 수 있는 클러스터는 한 방향으로만 작동한다는 점에 유의하십시오.
리프 클러스터의 사용자는 루트 클러스터의 리소스를 보고 연결할 수 없습니다.

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

리프 클러스터는 고유한 상태, 역할 및 로컬 사용자를 갖고 있어 자율적으로 운영됩니다. 이러한 자율성은 리프 클러스터 관리자가 외부 사용자의 신원을 로컬 클러스터 역할에 매핑하는 방법을 결정할 수 있도록 합니다. 다음 다이어그램은 msp-root.example.com 을 루트 클러스터로, leaf-east.example.com 을 리프 클러스터로 사용하여 역할 매핑 작동 방식을 간단하게 보여줍니다:

이 예에서 사용자 앨리스는 msp-root.example.com 루트 클러스터에 로그인합니다. 루트 클러스터는 그녀의 신원과 그룹 소속을 인증하는 단일 로그인을 제공하는 ID 공급자로 구성되어 있습니다. ID 공급자의 정보를 기반으로, 루트 클러스터는 앨리스에게 full-access 역할을 할당하고 인증서를 발급합니다. 단일 로그인 속성과 Teleport 역할 간의 매핑은 Teleport 클러스터에 인증 연결을 추가할 때 구성됩니다. 외부 ID 공급자를 통한 단일 로그인 구성에 대한 자세한 내용은 단일 로그인 구성하기를 참조하세요.

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

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

이 예에서 리프 클러스터 leaf-east.example.com 는 앨리스의 full-access 역할이 이 리프 클러스터에서 stage-access 역할로 매핑되기 때문에 그녀의 mongodb.prod.example.com 리소스에 대한 접근을 거부합니다. 역할 매핑을 통해 리프 클러스터 관리자는 외부 사용자에게 부여되는 권한을 제어할 수 있습니다. 역할 매핑은 루트 및 리프 클러스터에서 사용자에게 동일한 역할을 할당하는 것만큼 간단할 수 있지만, 사용자의 권한을 하향 조정하거나 특정 리소스에 대한 접근을 제한하는 데에도 사용할 수 있습니다.

신뢰할 수 있는 클러스터가 무엇인지, 그리고 어떻게 작동하는지 알게 되었으니 이 가이드를 사용하여 다음을 배울 수 있습니다:

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

사전 요구 사항

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

• 두 개의 Teleport 클러스터 인스턴스에 대한 접근.

  두 클러스터는 동일한 버전이어야 하며, 최대한 리프 클러스터는 루트 클러스터 버전보다 하나의 주요 버전만 뒤쳐질 수 있습니다.

• tctl 관리 도구 및 tsh 클라이언트 도구 버전 >= 17.0.0-dev.

  Teleport Enterprise 및 Teleport Enterprise 클라우드를 위해서는 tctl 및 tsh 의 엔터프라이즈 버전을 설치해야 합니다. 설치된 도구를 확인하려면 다음 명령어를 실행하십시오:

  tctl version
  Teleport Enterprise v17.0.0-dev go1.22
  
  tsh version
  Teleport v17.0.0-dev go1.22

  Teleport 설치에 대한 자세한 내용은 설치를 참조하세요.

• 사용하려는 리프 클러스터에 가입된 Teleport SSH 서버. 클러스터에 리소스를 등록하는 방법에 대한 정보는 클러스터에 서비스 가입하기를 참조하십시오.

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

이 가이드는 루트 클러스터의 사용자가 특정 사용자 아이덴티티와 역할로 리프 클러스터의 서버에 접근하는 방법을 보여줍니다. 이 예제에서 리프 클러스터의 서버에 접근하는 데 사용할 수 있는 사용자 아이덴티티는 visitor 입니다. 따라서 환경을 준비하려면, 먼저 visitor 사용자를 생성하고 리프 클러스터의 서버에 로그인할 때 이 사용자 이름을 가질 수 있는 Teleport 역할을 만들어야 합니다.

신뢰할 수 있는 클러스터에 접근하기 위해 사용자와 역할을 추가하려면:

1. 리프 클러스터에서 Teleport 에이전트를 실행 중인 서버에서 터미널 셸을 엽니다.

2. 다음 명령어를 실행하여 로컬 visitor 사용자를 추가하고 사용자를 위한 홈 디렉토리를 생성합니다:

   sudo useradd --create-home visitor

   홈 디렉토리는 visitor 사용자가 서버에서 셸에 접근하는 데 필요합니다.

3. 다음 명령어를 실행하여 모든 사용자 로그인과 클러스터에서 로그아웃합니다:

   tsh logout

4. 관리 작업용 워크스테이션에서 Teleport 사용자 이름을 사용하여 리프 클러스터에 로그인합니다:

   tsh login --proxy=leafcluster.example.com --user=myuser

   leafcluster.example.com 을 Teleport 리프 클러스터 도메인으로, myuser 를 Teleport 사용자 이름으로 교체합니다.

5. 다음 내용을 가진 visitor.yaml 이라는 역할 정의 파일을 생성합니다:

   kind: role
   version: v5
   metadata:
     name: visitor
   spec:
     allow:
       logins:
         - visitor
       node_labels:
         "*": "*"
   

   SSH를 통해 Teleport 에이전트를 실행 중인 서버에 접근할 수 있도록 노드에 대한 접근을 명시적으로 허용해야 합니다. 이 예제에서는 visitor 로그인이 모든 서버에 접근할 수 있도록 허용합니다.

6. 다음 명령어를 실행하여 visitor 역할을 생성합니다:

   tctl create visitor.yaml

   이제 리프 클러스터에 visitor 역할이 있습니다. visitor 역할은 visitor 로그인이 있는 사용자가 리프 클러스터의 노드에 접근할 수 있도록 허용합니다. 다음 단계에서는 visitor 로그인을 사용자에 추가하여 역할의 조건을 충족하고 리프 클러스터의 서버에 접근해야 합니다.

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

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

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

1. 다음 명령어를 실행하여 모든 사용자 로그인과 클러스터에서 로그아웃합니다:

   tsh logout

2. 관리 작업용 워크스테이션에서 Teleport 사용자 이름을 사용하여 루트 클러스터에 로그인합니다:

   tsh login --proxy=rootcluster.example.com --user=myuser

   rootcluster.example.com 을 Teleport 루트 클러스터 도메인으로, myuser 를 Teleport 사용자 이름으로 교체합니다.

3. 다음과 유사한 명령어를 실행하여 사용자 리소스를 에디터에서 엽니다:

   tctl edit user/myuser

   myuser 를 Teleport 사용자 이름으로 교체합니다.

4. visitor 로그인을 추가합니다:

      traits:
        logins:
   +    - visitor
        - ubuntu
        - root
   

5. 에디터에서 파일을 저장하고 닫아 변경 사항을 적용합니다.

3/6단계. 클러스터 간의 신뢰 구축

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

클러스터 간의 신뢰를 설정하려면 먼저 루트 클러스터의 Teleport Auth Service를 사용하여 초대 토큰을 생성해야 합니다. 그런 다음 리프 클러스터의 Teleport Auth Service를 사용하여 초대 토큰이 포함된 trusted_cluster 리소스를 생성하여 루트 클러스터에 리프 클러스터가 등록하려는 클러스터임을 증명할 수 있습니다.

신뢰 관계를 구축하려면:

1. 다음 명령어를 실행하여 모든 사용자 로그인 및 클러스터에서 로그아웃합니다:

   tsh logout

2. 관리 작업 스테이션에서 Teleport 사용자 이름을 사용하여 루트 클러스터에 로그인합니다:

   tsh login --proxy=rootcluster.example.com --user=myuser

   rootcluster.example.com 을 Teleport 루트 클러스터 도메인으로, myuser 를 Teleport 사용자 이름으로 교체합니다.

3. 다음 명령어를 실행하여 초대 토큰을 생성합니다:

   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)

4. 다음 내용을 가진 리소스 구성 파일 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 Service의 리버스 터널 주소로 설정합니다.
   • spec.web_proxy_addr 를 루트 클러스터의 Teleport Proxy Service 주소로 설정합니다.
   • spec.role_map 을 사용하여 루트 클러스터의 Teleport 역할을 리프 클러스터의 역할에 매핑합니다.

   클러스터 주소 조회하기

   tunnel_addr 또는 web_proxy_addr 와 같은 클러스터 설정에 사용할 값을 확실하지 않은 경우, JSON 파일에서 기계 판독 가능한 데이터를 구문 분석하고 추출하는 명령줄 도구를 사용하여 정보를 조회할 수 있습니다. 이러한 도구 중 가장 일반적인 것 중 하나는 jq 입니다. 대부분의 운영 체제에서 jqlang 웹사이트에서 jq 를 다운로드할 수 있습니다.

   jq 를 사용하여 클러스터 주소를 알아내려면:

   1. 다음과 같이 Teleport 클러스터에 대한 정보를 검색하기 위해 PROXY 환경 변수를 설정합니다. teleport.example.com 을 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

   루트 클러스터 역할을 리프 클러스터 역할에 매핑하기

   trusted_cluster 리소스 구성의 role_map 설정을 사용하여 루트 클러스터의 역할을 리프 클러스터의 역할에 매핑합니다. 이 예제에서는 루트 클러스터에 access 역할이 할당된 사용자가 리프 클러스터의 서버에 로그인할 때 visitor 역할을 부여받습니다. 이 역할 매핑을 통해 리프 클러스터의 리소스에 대한 액세스를 제한할 수 있습니다.

   Teleport 사용자에게 루트 클러스터에서 access 역할이 지정되어 있는 경우, 이 역할 매핑을 사용하여 리프 클러스터의 서버에 대한 액세스를 테스트할 수 있습니다. 사용자에게 access 역할이 지정되어 있지 않으면 role_map 에서 access 를 사용자의 역할 중 하나로 변경하십시오.

   역할 매핑은 신뢰 클러스터에서 액세스를 관리하는 데 매우 강력할 수 있습니다. 리프 클러스터에 대한 액세스를 제한하는 방법과 허용된 구문 예제에 대한 자세한 내용은 역할 매핑 구문 및 표현식을 참조하십시오.

5. 다음 명령어를 실행하여 루트 클러스터에서 로그아웃합니다:

   tsh logout

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

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

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

1. 관리 워크스테이션에서 Teleport 사용자 이름을 사용하여 리프 클러스터에 로그인합니다:

   tsh login --proxy=leafcluster.example.com --user=myuser

   leafcluster.example.com 을 Teleport 리프 클러스터 도메인으로, myuser 를 당신의 Teleport 사용자 이름으로 교체하십시오.

2. 다음 명령을 실행하여 리소스 구성 파일에서 신뢰할 수 있는 클러스터 리소스를 생성합니다:

   tctl create trusted_cluster.yaml

   또한 Teleport 웹 UI에서 리프 클러스터를 직접 구성할 수 있습니다. 예를 들어, Management를 선택한 다음 Trusted Clusters를 클릭하여 새로운 trusted_cluster 리소스를 생성하거나 기존의 신뢰할 수 있는 클러스터를 관리할 수 있습니다.

3. 리프 클러스터에서 로그아웃한 후 루트 클러스터에 다시 로그인합니다.

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

   tsh clusters

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

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

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

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

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

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

1. 다음 명령을 실행하여 루트 클러스터에 Teleport 사용자로 로그인했는지 확인합니다:

   tsh status

2. 다음 명령을 실행하여 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
   

3. 다음과 유사한 명령을 실행하여 리프 클러스터에 라벨을 추가합니다:

   tctl update rc/leafcluster.example.com --set-labels=env=demo

   이 명령을 실행한 후, 당신은 방금 설정한 라벨이 있는 클러스터에 액세스할 수 있는 권한을 부여받아야 합니다. 신뢰할 수 있는 클러스터에 라벨이 있는 경우, Teleport Auth 서비스는 해당 라벨이 설정된 클러스터에 대한 정보는 액세스할 수 있는 역할이 할당되지 않으면 반환하지 않습니다.

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

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

5. 다음 명령을 실행하여 역할을 생성합니다:

   tctl create demo-cluster-access.yaml

6. demo-cluster-access 역할을 Teleport 사용자에게 할당하려면, 인증 제공자에 맞는 적절한 명령어를 실행하십시오:

   • 로컬 사용자
   • GitHub
   • SAML
   • OIDC

   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 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.

   1. 텍스트 편집기에서 github 인증 커넥터를 엽니다:

      tctl edit github/github

   2. github 커넥터를 수정하여 teams_to_roles 섹션에 demo-cluster-access 을 추가합니다.

      이 역할에 매핑해야 하는 팀은 조직의 역할 기반 액세스 제어(RBAC) 설계에 따라 다릅니다. 그러나 팀은 귀하의 사용자 계정을 포함해야 하며, 조직 내에서 가장 작은 팀이어야 합니다.

      예시는 다음과 같습니다:

        teams_to_roles:
          - organization: octocats
            team: admins
            roles:
              - access
      +       - demo-cluster-access
      

   3. 파일을 편집하고 저장하여 변경 사항을 적용합니다.

   4. Teleport 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.

   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 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.

   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 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.

7. 다음 명령을 실행하여 설정한 라벨로 리프 클러스터가 업데이트되었는지 확인합니다:

   tctl get rc

   이제 env: demo 라벨이 있는 클러스터에 대한 액세스 권한이 있는 역할이 있으므로, 이 명령은 업데이트된 리소스 정보를 표시합니다:

   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 리소스를 사용하여 루트 클러스터의 사용자로서 리프 클러스터의 서버에 로그인할 수 있습니다.

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

1. 다음 명령어를 실행하여 루트 클러스터에 Teleport 사용자로 로그인되어 있는지 확인하세요:

   tsh status

2. 다음과 유사한 명령어를 실행하여 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
   

3. visitor 로그인을 사용하여 보안 셸 연결을 엽니다:

   tsh ssh --cluster=leafcluster.example.com visitor@ip-172-3-2-205

4. 다음 명령어를 실행하여 리프 클러스터의 서버에서 visitor 사용자로 로그인되어 있는지 확인하세요:

   pwd
   /home/visitor
   uname -a
   Linux ip-172-3-2-205 5.15.0-1041-aws #46~20.04.1-Ubuntu SMP 수 7월 19 15:39:29 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

역할 매핑 구문 및 표현식

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

와일드카드 문자

역할 매핑에서 별표(*)는 문자열에서 0개 이상의 문자를 일치시키는 데 사용할 수 있는 와일드카드 문자입니다. 예를 들어, 루트 클러스터의 모든 사용자가 리프 클러스터에 연결할 수 있도록 하려면 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 Access Controls Reference를 참조하십시오.

역할 매핑 업데이트

신뢰할 수 있는 클러스터 리소스의 역할 매핑을 업데이트하려면 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 리소스 구성 파일을 편집하세요.

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

1. 관리 작업 공간에서 Teleport 사용자 이름을 사용하여 리프 클러스터에 로그인합니다:

   tsh login --proxy=leafcluster.example.com --user=myuser

   leafcluster.example.com 을 Teleport 리프 클러스터 도메인으로, myuser 를 Teleport 사용자 이름으로 바꿉니다.

2. 다음 명령을 실행하여 리소스 구성을 편집합니다:

   tctl edit trusted_cluster/rootcluster.example.com

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

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

4. 편집기에서 파일을 저장하고 닫아 신뢰할 수 있는 클러스터 구성을 업데이트합니다.

   이 명령은 리프 클러스터와 루트 클러스터 간의 리버스 터널을 닫습니다.
   또한 리프 클러스터에서 루트 클러스터의 인증서 기관을 비활성화합니다.

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

Kubernetes 클러스터에 대한 액세스 연합

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

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

여러 개의 신뢰할 수 있는 클러스터가 Teleport Proxy Service 뒤에 있는 경우, tsh login 으로 생성된 kubeconfig 에는 tsh login 명령에 대한 <cluster> 인수에 의해 결정된 Kubernetes API 엔드포인트가 포함됩니다.

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

• east 와 west 라는 두 개의 Teleport 클러스터와 동일한 이름을 가진 두 개의 Kubernetes 클러스터가 있습니다. 각 Teleport 클러스터는 cluster_name 필드에 자신의 이름이 지정된 구성 파일을 가지고 있습니다.
• east 와 west 클러스터는 example.teleport.sh 와 같은 Teleport 팀 또는 엔터프라이즈 클라우드 계정을 신뢰하는 리프 클러스터입니다.
• 사용자는 항상 example.teleport.sh 에 대해 인증하지만, 모든 세 클러스터에서 SSH 노드와 Kubernetes API에 접근하기 위해 자신의 인증서를 사용합니다.

이 시나리오에서 사용자는 보통 다음 명령어를 사용하여 로그인이 가능합니다:

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

"east"의 인증서 수신
tsh --proxy=mytenant.teleport.sh login east

동일한 이름을 가진 Teleport 클러스터에 있는 "east"라는 Kubernetes 클러스터에 로그인
tsh kube login --proxy=mytenant.teleport.sh --cluster=east east

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

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

리프 클러스터를 완전히 제거하고 나중에 복원할 수 없는 경우, 리프 클러스터와 루트 클러스터 모두에서 명령을 실행해야 합니다.

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

1. 관리 워크스테이션에서 Teleport 사용자 이름을 사용하여 리프 클러스터에 로그인합니다:

   tsh login --proxy=leafcluster.example.com --user=myuser

   leafcluster.example.com 을 Teleport 리프 클러스터 도메인으로, myuser 를 Teleport 사용자 이름으로 바꿉니다.

2. 다음 명령을 실행하여 리프 클러스터를 비활성화하고 제거합니다:

   tctl rm trusted_cluster/rootcluster.example.com

   이 명령은 trusted_cluster 리소스의 spec.enabled 를 false 로 설정하고 Teleport Auth Service 백엔드에서 신뢰할 수 있는 클러스터 리소스를 제거합니다.

3. 관리 워크스테이션에서 Teleport 사용자 이름을 사용하여 루트 클러스터에 로그인합니다:

   tsh login --proxy=rootcluster.example.com --user=myuser

   rootcluster.example.com 을 Teleport 루트 클러스터 도메인으로, myuser 를 Teleport 사용자 이름으로 바꿉니다.

4. 원격 클러스터에 연결된 인증 기관을 삭제하고 Teleport Auth Service 백엔드에서 remote_cluster 리소스를 제거하려면 다음 명령을 실행합니다:

   tctl rm rc/leafcluster.example.com

   이 명령을 리프 클러스터에서 신뢰 관계를 제거하지 않고 실행하면, 리프 클러스터는 루트 클러스터에 계속 ping을 시도하지만 연결할 수 없습니다. 신뢰할 수 있는 클러스터 관계를 다시 설정하려면 리프 클러스터에서 신뢰할 수 있는 클러스터를 다시 생성해야 합니다.

문제 해결

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

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

HTTPS 구성 문제

가장 일반적인 HTTPS 구성 문제는 루트 클러스터가 자체 서명된 또는 유효하지 않은 HTTPS 인증서를 사용하는 경우 발생합니다. 루트 클러스터의 web_proxy_addr 엔드포인트가 자체 서명된 또는 유효하지 않은 HTTPS 인증서를 사용하는 경우, 다음과 유사한 오류 메시지를 볼 수 있습니다: 신뢰할 수 있는 클러스터가 잘못 구성된 HTTP/TLS 인증서를 사용합니$1 .

테스트를 용이하게 하기 위해, 리프 클러스터에서 --insecure 명령줄 옵션으로 teleport 데몬을 시작하여 자체 서명된 인증서를 허용할 수 있습니다. 그러나 문제를 해결하기 위해 HTTPS를 적절하게 구성한 후에는 생산 환경에서 Teleport를 실행하기 전에 --insecure 를 제거해야 합니다.

연결 문제

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

연결 문제를 해결하기 위해, 루트 및 리프 클러스터 모두에서 Teleport Auth 서비스의 상세 출력을 활성화하십시오. 일반적으로, teleport 서비스를 시작하는 명령에 --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에서의 네트워크 보안 그룹 구성 문제로 인해 발생합니다.

액세스 문제

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

• tsh login 명령으로 로그인할 때 루트 클러스터에서 사용자에게 할당된 역할. 클라이언트에서 tsh status 명령을 실행하여 인증서와 할당된 역할을 검사할 수 있습니다.

• 역할 매핑이 이루어질 때 리프 클러스터에서 사용자에게 할당된 역할. Teleport 감사 로그에서 역할 매핑을 확인할 수 있습니다.

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

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