InfoGrab Docs

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

요약

신뢰할 수 있는 클러스터는 자체 호스팅 Teleport 클러스터에서만 사용할 수 있습니다. 핵심 개념에서 배운 것처럼, Teleport 클러스터는 Teleport Auth Service, Teleport Proxy Service, 그리고 인프라의 리소스에 대한 접근을 관리하는 Teleport 서비스로 구성됩니다.

참고

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

핵심 개념에서 배운 것처럼, Teleport 클러스터는 Teleport Auth Service, Teleport Proxy Service, 그리고 인프라의 리소스에 대한 접근을 관리하는 Teleport 서비스로 구성됩니다. Teleport를 사용하면 인프라를 여러 연결된 클러스터로 분할하여 하나의 클러스터(루트 클러스터)의 사용자가 단일 Teleport Auth Service로 인증된 채로 다른 클러스터(리프 클러스터)의 리소스에 연결할 수 있습니다.

루트 클러스터와 리프 클러스터 간에 신뢰 관계를 설정한 후, 리프 클러스터는 인바운드 포트를 열지 않고 방화벽 뒤에서 실행될 수 있습니다. 리프 클러스터는 루트 클러스터로의 아웃바운드 역방향 SSH 터널을 생성하고 터널을 열린 상태로 유지합니다. 사용자가 리프 클러스터의 리소스에 연결하려고 할 때, 리프 클러스터의 Teleport Auth Service는 루트 클러스터에서 실행 중인 Teleport Proxy Service 인스턴스를 사용하여 역방향 터널을 통해 루트 클러스터에 연결합니다.

경고

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

작동 방식#

다음 예시에서, 관리 서비스 제공업체(MSP)는 서로 다른 지역의 고객에게 접근을 제공하기 위해 세 개의 독립적인 클러스터를 사용합니다:

  • 클러스터 msp-root.example.com은 루트 클러스터입니다. 이 클러스터는 자체 리소스를 가지거나 감사 로그 수집 및 사용자 인증 전용으로 사용될 수 있습니다.
  • 클러스터 leaf-east.example.com과 leaf-west.example.com은 서로 다른 지역의 고객에게 서비스를 제공하는 두 개의 독립적인 리프 클러스터입니다.
  • 각 클러스터는 독립적인 x.509 및 SSH 인증 기관으로 자율적으로 운영될 수 있습니다.
  • 각 리프 클러스터는 루트 클러스터로 역방향 터널을 다이얼백합니다. 여러 Proxy Service 인스턴스가 있는 경우 고가용성을 위해 여러 터널이 있습니다.

다음 다이어그램은 아키텍처의 단순화된 뷰를 제공합니다:

신뢰할 수 있는 클러스터

이 다이어그램에서 보여주듯이, 사용자는 루트 클러스터에 로그인하여 루트 클러스터 인증 기관이 서명한 인증서를 받을 수 있습니다. 그런 다음 직접 또는 루트 클러스터를 배스천 호스트로 사용하여 리프 클러스터에 연결할 수 있습니다. 사용자가 로그인하면 인증서의 정보와 루트 클러스터의 역할이 리프 클러스터의 역할에 매핑되는 방식을 기반으로 리프 클러스터에서 인식되고 신뢰받을 수 있습니다.

리프 클러스터의 Teleport Auth Service는 다음 정보를 인증서에서 확인하여 사용자가 접근 권한을 가진 리소스를 결정합니다:

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

인증서의 정보를 기반으로, Teleport Auth Service는 다음 작업을 수행합니다:

  • 인증서 서명이 신뢰할 수 있는 루트 클러스터 중 하나와 일치하는지 확인합니다.
  • 역할 매핑을 적용하여 루트 클러스터에서 사용자에게 할당된 역할 중 하나와 리프 클러스터의 역할을 연결합니다.
  • 로컬 역할이 요청된 아이덴티티(Unix 로그인)의 접근을 허용하는지 확인합니다.
  • 인증서가 만료되지 않았는지 확인합니다. TTL은 루트 클러스터에 의해 설정됩니다.

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

신뢰할 수 있는 클러스터에서의 서비스 상호 작용

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

신뢰할 수 있는 클러스터를 사용하는 사람#

대부분의 조직은 신뢰할 수 있는 클러스터를 구성할 필요가 없습니다. 대부분의 경우, 새로운 클러스터를 만들지 않고도 여러 Teleport Proxy Service 인스턴스를 추가하여 수천 개의 리소스를 등록하고 관리할 수 있습니다.

그러나 신뢰할 수 있는 클러스터가 특히 유용할 수 있는 몇 가지 특정 시나리오가 있습니다. 예를 들어, 대규모이고 광범위하게 분산된 인프라를 보유하고 있거나 외부 기관, 계약업체 또는 고객을 위한 리소스 접근을 제공해야 하는 경우 신뢰할 수 있는 클러스터를 설정하면 이점을 얻을 수 있습니다. 신뢰할 수 있는 클러스터의 가장 일반적인 사용 사례는 다음과 같습니다:

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

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

리프 클러스터는 자체 상태, 역할 및 로컬 사용자를 갖는다는 점에서 자율적입니다. 이 자율성은 리프 클러스터 관리자가 외부 사용자의 아이덴티티를 로컬 클러스터 역할에 매핑하는 방법을 결정할 수 있게 합니다. 다음 다이어그램은 msp-root.example.com을 루트 클러스터로, leaf-east.example.com을 리프 클러스터로 사용하는 동일한 신뢰할 수 있는 클러스터에서 역할 매핑이 작동하는 방식을 단순화된 뷰로 제공합니다:

신뢰할 수 있는 클러스터에서의 역할 매핑

이 예시에서, 사용자 Alice는 msp-root.example.com 루트 클러스터에 로그인합니다. 루트 클러스터는 그녀의 아이덴티티와 그룹 멤버십을 인증하는 단일 사인온 아이덴티티 제공자로 구성되어 있습니다. 아이덴티티 제공자의 정보를 기반으로 루트 클러스터는 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은 루트 클러스터의 full-access 역할이 이 리프 클러스터의 stage-access 역할로 매핑되기 때문에 Alice의 mongodb.prod.example.com 리소스 접근을 거부합니다. 역할 매핑을 통해 리프 클러스터 관리자는 외부 사용자에게 부여되는 권한을 제어할 수 있습니다. 역할 매핑은 루트 클러스터와 리프 클러스터에서 동일한 역할에 사용자를 할당하는 것만큼 간단할 수 있지만, 매핑을 사용하여 사용자의 권한을 다운그레이드하거나 특정 리소스에 대한 접근을 제한할 수도 있습니다.

신뢰할 수 있는 클러스터가 무엇인지, 어떻게 작동하는지 이제 알았으므로 이 가이드를 사용하여 다음 방법을 배울 수 있습니다:

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

사전 요구사항#

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

  • Proxy Peering이 비활성화되어 있어야 합니다. Proxy Peering과 신뢰할 수 있는 클러스터는 호환되지 않습니다.

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

    두 클러스터는 동일한 버전이거나, 최대 리프 클러스터가 루트 클러스터 버전보다 한 메이저 버전 이하일 수 있습니다.

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

    다음 명령을 실행하여 설치된 도구를 확인할 수 있습니다:

    $ tctl version
# Teleport v(=teleport.version=) go(=teleport.golang=)

$ tsh version
# Teleport v(=teleport.version=) go(=teleport.golang=)

    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= --user=

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

  5. 다음 내용으로 visitor.yaml이라는 역할 정의 파일을 만듭니다:

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

    에이전트를 실행하는 서버에 SSH로 접속하려면 레이블이 있는 노드에 대한 접근을 명시적으로 허용해야 합니다. 이 예시에서는 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= --user=

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

  3. 다음과 유사한 명령을 실행하여 편집기에서 사용자 리소스를 엽니다:

    $ tctl edit user/

    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= --user=

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

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

    $ tctl tokens add --type=trusted_cluster --ttl=5m
The cluster invite token: (=presets.tokens.first=)

    이 명령은 리프 클러스터의 인바운드 연결을 허용하는 신뢰할 수 있는 클러스터 초대 토큰을 생성합니다. 토큰은 여러 번 사용할 수 있습니다. 이 명령 예시에서 토큰의 만료 시간은 5분입니다.

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

    나중에 사용하기 위해 토큰을 복사할 수 있습니다. 토큰을 다시 표시해야 하는 경우 루트 클러스터에 대해 다음 명령을 실행합니다:

    $ tctl tokens ls
Token                                                    Type            Labels   Expiry Time (UTC)
-------------------------------------------------------- --------------- -------- ---------------------------
(=presets.tokens.first=)                         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: (=presets.tokens.first=)
  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. 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 역할이 할당된 경우, 이 역할 매핑을 사용하여 리프 클러스터의 서버에 대한 접근을 테스트할 수 있습니다. Teleport 사용자에게 access 역할이 할당되지 않은 경우, role_map의 access를 사용자의 역할 중 하나로 변경합니다.

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

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

    $ tsh logout

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

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

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

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

    $ tsh login --proxy= --user=

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

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

    $ tctl create trusted_cluster.yaml

    Teleport Web UI에서 직접 리프 클러스터를 구성할 수도 있습니다. 예를 들어 왼쪽 창에서 Zero Trust Access를 선택한 다음 Manage Clusters를 클릭하여 새 trusted_cluster 리소스를 만들거나 기존 신뢰할 수 있는 클러스터를 관리할 수 있습니다.

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

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

    $ tsh clusters

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

    Cluster Name                Status Cluster Type Labels Selected
--------------------------- ------ ------------ ------ --------
rootcluster.example.com     online root                *
leafcluster.example.com     online leaf

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

리프 클러스터에서 trusted_cluster 리소스를 생성하면, 리프 클러스터의 Teleport Auth Service가 루트 클러스터의 Teleport Proxy Service에 요청을 보내 신뢰할 수 있는 클러스터를 검증합니다. 요청을 검증한 후 루트 클러스터는 신뢰할 수 있는 리프 클러스터를 나타내는 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 Service는 설정된 레이블이 있는 클러스터에 대한 접근을 허용하는 역할이 할당되지 않으면 클러스터에 대한 정보를 반환하지 않습니다.

  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 역할을 추가합니다.

  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=

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

    Node Name       Address        Labels
--------------- -------------- ------------------------------------
ip-172-3-1-242  127.0.0.1:3022 hostname=ip-172-3-1-242
ip-172-3-2-205  ⟵ Tunnel      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 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 역할에서 변수 확장이 작동하는 방식에 대한 자세한 내용은 접근 제어 참조를 참조하세요.

역할 매핑 업데이트#

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= --user=

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

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

    $ tctl edit trusted_cluster/

  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 클러스터는 자체 호스팅 Teleport 클러스터(예: teleport.example.com)를 신뢰하는 리프 클러스터입니다.
  • 사용자는 항상 teleport.example.com에 대해 인증하지만 세 클러스터 모두에서 SSH 노드와 Kubernetes API에 접근하기 위해 인증서를 사용합니다.

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

# Log in to the root cluster
$ tsh --proxy=teleport.example.com login

# Receive a certificate for "east"
$ tsh --proxy=teleport.example.com login east

# Log in to the Kubernetes cluster called "east" in the Teleport cluster with
# the same name
$ tsh kube login --proxy=teleport.example.com --cluster=east east

# The user's kubeconfig now contains the entry for the "east" Kubernetes
# endpoint, i.e. east.teleport.example.com

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

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

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

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

    $ tsh login --proxy= --user=

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

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

    $ tctl rm trusted_cluster/

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

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

    $ tsh login --proxy= --user=

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

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

    $ tctl rm rc/

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

문제 해결#

신뢰 관계를 구성할 때 발생할 수 있는 가장 일반적인 문제는 다음 범주에 속합니다:

  • HTTPS 구성 문제.
  • 연결 문제.
  • 접근 문제.

HTTPS 구성 문제#

가장 일반적인 HTTPS 구성 문제는 자체 서명 또는 잘못된 HTTPS 인증서를 사용하는 루트 클러스터에서 발생합니다. 루트 클러스터의 web_proxy_addr 엔드포인트가 자체 서명 또는 잘못된 HTTPS 인증서를 사용하는 경우 다음과 유사한 오류가 표시될 가능성이 높습니다: The trusted cluster uses misconfigured HTTP/TLS certificate.

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

연결 문제#

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

연결 문제를 해결하려면 루트 클러스터와 리프 클러스터 모두의 Teleport Auth Service에서 상세 출력을 활성화합니다. 일반적으로 teleport 서비스를 시작하는 명령에 --debug 플래그를 추가하면 됩니다:

teleport start --debug`

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

# Snippet from /etc/teleport.yaml
teleport:
  log:
    output: stderr
    severity: DEBUG

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

$ journalctl -fu teleport

대부분의 경우 초대 토큰이 일치하지 않거나 만료되었거나, 기존 방화벽 규칙이나 AWS에서 네트워크 보안 그룹이 구성된 방식으로 인해 tunnel_addr 또는 web_proxy_addr에 대한 네트워크 주소에 도달할 수 없다는 것을 알게 될 것입니다.

접근 문제#

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

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

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

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

    Teleport를 관리형 클라우드 기반 서비스로 사용하는 경우, 감사 로그는 event 리소스에 대한 권한이 있는 사용자의 Web UI 왼쪽 창에서 Audit를 통해 볼 수 있습니다.

신뢰할 수 있는 클러스터 내의 애플리케이션 접근#

루트 및 리프를 포함한 전체 클러스터에서 고유한 애플리케이션 이름을 갖는 것이 권장됩니다. 리프 클러스터가 제공하는 애플리케이션은 루트 클러스터에서 app_name.root_proxy_public_addr를 통해 접근합니다. FQDN만으로 앱에 접근하는 경우 모호한 해석이 발생할 수 있습니다. 앱이 여러 클러스터에서 동일한 이름을 포함해야 하는 경우, 올바른 앱에 접근하는 가장 확실한 방법은 Web UI의 리소스 페이지를 통하는 것입니다.

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

원문 보기
요약

신뢰할 수 있는 클러스터는 자체 호스팅 Teleport 클러스터에서만 사용할 수 있습니다. 핵심 개념에서 배운 것처럼, Teleport 클러스터는 Teleport Auth Service, Teleport Proxy Service, 그리고 인프라의 리소스에 대한 접근을 관리하는 Teleport 서비스로 구성됩니다.

참고

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

핵심 개념에서 배운 것처럼, Teleport 클러스터는 Teleport Auth Service, Teleport Proxy Service, 그리고 인프라의 리소스에 대한 접근을 관리하는 Teleport 서비스로 구성됩니다. Teleport를 사용하면 인프라를 여러 연결된 클러스터로 분할하여 하나의 클러스터(루트 클러스터)의 사용자가 단일 Teleport Auth Service로 인증된 채로 다른 클러스터(리프 클러스터)의 리소스에 연결할 수 있습니다.

루트 클러스터와 리프 클러스터 간에 신뢰 관계를 설정한 후, 리프 클러스터는 인바운드 포트를 열지 않고 방화벽 뒤에서 실행될 수 있습니다. 리프 클러스터는 루트 클러스터로의 아웃바운드 역방향 SSH 터널을 생성하고 터널을 열린 상태로 유지합니다. 사용자가 리프 클러스터의 리소스에 연결하려고 할 때, 리프 클러스터의 Teleport Auth Service는 루트 클러스터에서 실행 중인 Teleport Proxy Service 인스턴스를 사용하여 역방향 터널을 통해 루트 클러스터에 연결합니다.

경고

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

작동 방식#

다음 예시에서, 관리 서비스 제공업체(MSP)는 서로 다른 지역의 고객에게 접근을 제공하기 위해 세 개의 독립적인 클러스터를 사용합니다:

  • 클러스터 msp-root.example.com은 루트 클러스터입니다. 이 클러스터는 자체 리소스를 가지거나 감사 로그 수집 및 사용자 인증 전용으로 사용될 수 있습니다.
  • 클러스터 leaf-east.example.com과 leaf-west.example.com은 서로 다른 지역의 고객에게 서비스를 제공하는 두 개의 독립적인 리프 클러스터입니다.
  • 각 클러스터는 독립적인 x.509 및 SSH 인증 기관으로 자율적으로 운영될 수 있습니다.
  • 각 리프 클러스터는 루트 클러스터로 역방향 터널을 다이얼백합니다. 여러 Proxy Service 인스턴스가 있는 경우 고가용성을 위해 여러 터널이 있습니다.

다음 다이어그램은 아키텍처의 단순화된 뷰를 제공합니다:

신뢰할 수 있는 클러스터

이 다이어그램에서 보여주듯이, 사용자는 루트 클러스터에 로그인하여 루트 클러스터 인증 기관이 서명한 인증서를 받을 수 있습니다. 그런 다음 직접 또는 루트 클러스터를 배스천 호스트로 사용하여 리프 클러스터에 연결할 수 있습니다. 사용자가 로그인하면 인증서의 정보와 루트 클러스터의 역할이 리프 클러스터의 역할에 매핑되는 방식을 기반으로 리프 클러스터에서 인식되고 신뢰받을 수 있습니다.

리프 클러스터의 Teleport Auth Service는 다음 정보를 인증서에서 확인하여 사용자가 접근 권한을 가진 리소스를 결정합니다:

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

인증서의 정보를 기반으로, Teleport Auth Service는 다음 작업을 수행합니다:

  • 인증서 서명이 신뢰할 수 있는 루트 클러스터 중 하나와 일치하는지 확인합니다.
  • 역할 매핑을 적용하여 루트 클러스터에서 사용자에게 할당된 역할 중 하나와 리프 클러스터의 역할을 연결합니다.
  • 로컬 역할이 요청된 아이덴티티(Unix 로그인)의 접근을 허용하는지 확인합니다.
  • 인증서가 만료되지 않았는지 확인합니다. TTL은 루트 클러스터에 의해 설정됩니다.

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

신뢰할 수 있는 클러스터에서의 서비스 상호 작용

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

신뢰할 수 있는 클러스터를 사용하는 사람#

대부분의 조직은 신뢰할 수 있는 클러스터를 구성할 필요가 없습니다. 대부분의 경우, 새로운 클러스터를 만들지 않고도 여러 Teleport Proxy Service 인스턴스를 추가하여 수천 개의 리소스를 등록하고 관리할 수 있습니다.

그러나 신뢰할 수 있는 클러스터가 특히 유용할 수 있는 몇 가지 특정 시나리오가 있습니다. 예를 들어, 대규모이고 광범위하게 분산된 인프라를 보유하고 있거나 외부 기관, 계약업체 또는 고객을 위한 리소스 접근을 제공해야 하는 경우 신뢰할 수 있는 클러스터를 설정하면 이점을 얻을 수 있습니다. 신뢰할 수 있는 클러스터의 가장 일반적인 사용 사례는 다음과 같습니다:

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

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

리프 클러스터는 자체 상태, 역할 및 로컬 사용자를 갖는다는 점에서 자율적입니다. 이 자율성은 리프 클러스터 관리자가 외부 사용자의 아이덴티티를 로컬 클러스터 역할에 매핑하는 방법을 결정할 수 있게 합니다. 다음 다이어그램은 msp-root.example.com을 루트 클러스터로, leaf-east.example.com을 리프 클러스터로 사용하는 동일한 신뢰할 수 있는 클러스터에서 역할 매핑이 작동하는 방식을 단순화된 뷰로 제공합니다:

신뢰할 수 있는 클러스터에서의 역할 매핑

이 예시에서, 사용자 Alice는 msp-root.example.com 루트 클러스터에 로그인합니다. 루트 클러스터는 그녀의 아이덴티티와 그룹 멤버십을 인증하는 단일 사인온 아이덴티티 제공자로 구성되어 있습니다. 아이덴티티 제공자의 정보를 기반으로 루트 클러스터는 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은 루트 클러스터의 full-access 역할이 이 리프 클러스터의 stage-access 역할로 매핑되기 때문에 Alice의 mongodb.prod.example.com 리소스 접근을 거부합니다. 역할 매핑을 통해 리프 클러스터 관리자는 외부 사용자에게 부여되는 권한을 제어할 수 있습니다. 역할 매핑은 루트 클러스터와 리프 클러스터에서 동일한 역할에 사용자를 할당하는 것만큼 간단할 수 있지만, 매핑을 사용하여 사용자의 권한을 다운그레이드하거나 특정 리소스에 대한 접근을 제한할 수도 있습니다.

신뢰할 수 있는 클러스터가 무엇인지, 어떻게 작동하는지 이제 알았으므로 이 가이드를 사용하여 다음 방법을 배울 수 있습니다:

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

사전 요구사항#

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

  • Proxy Peering이 비활성화되어 있어야 합니다. Proxy Peering과 신뢰할 수 있는 클러스터는 호환되지 않습니다.

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

    두 클러스터는 동일한 버전이거나, 최대 리프 클러스터가 루트 클러스터 버전보다 한 메이저 버전 이하일 수 있습니다.

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

    다음 명령을 실행하여 설치된 도구를 확인할 수 있습니다:

    $ tctl version
# Teleport v(=teleport.version=) go(=teleport.golang=)

$ tsh version
# Teleport v(=teleport.version=) go(=teleport.golang=)

    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= --user=

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

  5. 다음 내용으로 visitor.yaml이라는 역할 정의 파일을 만듭니다:

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

    에이전트를 실행하는 서버에 SSH로 접속하려면 레이블이 있는 노드에 대한 접근을 명시적으로 허용해야 합니다. 이 예시에서는 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= --user=

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

  3. 다음과 유사한 명령을 실행하여 편집기에서 사용자 리소스를 엽니다:

    $ tctl edit user/

    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= --user=

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

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

    $ tctl tokens add --type=trusted_cluster --ttl=5m
The cluster invite token: (=presets.tokens.first=)

    이 명령은 리프 클러스터의 인바운드 연결을 허용하는 신뢰할 수 있는 클러스터 초대 토큰을 생성합니다. 토큰은 여러 번 사용할 수 있습니다. 이 명령 예시에서 토큰의 만료 시간은 5분입니다.

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

    나중에 사용하기 위해 토큰을 복사할 수 있습니다. 토큰을 다시 표시해야 하는 경우 루트 클러스터에 대해 다음 명령을 실행합니다:

    $ tctl tokens ls
Token                                                    Type            Labels   Expiry Time (UTC)
-------------------------------------------------------- --------------- -------- ---------------------------
(=presets.tokens.first=)                         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: (=presets.tokens.first=)
  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. 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 역할이 할당된 경우, 이 역할 매핑을 사용하여 리프 클러스터의 서버에 대한 접근을 테스트할 수 있습니다. Teleport 사용자에게 access 역할이 할당되지 않은 경우, role_map의 access를 사용자의 역할 중 하나로 변경합니다.

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

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

    $ tsh logout

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

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

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

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

    $ tsh login --proxy= --user=

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

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

    $ tctl create trusted_cluster.yaml

    Teleport Web UI에서 직접 리프 클러스터를 구성할 수도 있습니다. 예를 들어 왼쪽 창에서 Zero Trust Access를 선택한 다음 Manage Clusters를 클릭하여 새 trusted_cluster 리소스를 만들거나 기존 신뢰할 수 있는 클러스터를 관리할 수 있습니다.

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

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

    $ tsh clusters

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

    Cluster Name                Status Cluster Type Labels Selected
--------------------------- ------ ------------ ------ --------
rootcluster.example.com     online root                *
leafcluster.example.com     online leaf

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

리프 클러스터에서 trusted_cluster 리소스를 생성하면, 리프 클러스터의 Teleport Auth Service가 루트 클러스터의 Teleport Proxy Service에 요청을 보내 신뢰할 수 있는 클러스터를 검증합니다. 요청을 검증한 후 루트 클러스터는 신뢰할 수 있는 리프 클러스터를 나타내는 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 Service는 설정된 레이블이 있는 클러스터에 대한 접근을 허용하는 역할이 할당되지 않으면 클러스터에 대한 정보를 반환하지 않습니다.

  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 역할을 추가합니다.

  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=

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

    Node Name       Address        Labels
--------------- -------------- ------------------------------------
ip-172-3-1-242  127.0.0.1:3022 hostname=ip-172-3-1-242
ip-172-3-2-205  ⟵ Tunnel      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 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 역할에서 변수 확장이 작동하는 방식에 대한 자세한 내용은 접근 제어 참조를 참조하세요.

역할 매핑 업데이트#

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= --user=

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

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

    $ tctl edit trusted_cluster/

  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 클러스터는 자체 호스팅 Teleport 클러스터(예: teleport.example.com)를 신뢰하는 리프 클러스터입니다.
  • 사용자는 항상 teleport.example.com에 대해 인증하지만 세 클러스터 모두에서 SSH 노드와 Kubernetes API에 접근하기 위해 인증서를 사용합니다.

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

# Log in to the root cluster
$ tsh --proxy=teleport.example.com login

# Receive a certificate for "east"
$ tsh --proxy=teleport.example.com login east

# Log in to the Kubernetes cluster called "east" in the Teleport cluster with
# the same name
$ tsh kube login --proxy=teleport.example.com --cluster=east east

# The user's kubeconfig now contains the entry for the "east" Kubernetes
# endpoint, i.e. east.teleport.example.com

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

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

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

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

    $ tsh login --proxy= --user=

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

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

    $ tctl rm trusted_cluster/

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

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

    $ tsh login --proxy= --user=

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

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

    $ tctl rm rc/

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

문제 해결#

신뢰 관계를 구성할 때 발생할 수 있는 가장 일반적인 문제는 다음 범주에 속합니다:

  • HTTPS 구성 문제.
  • 연결 문제.
  • 접근 문제.

HTTPS 구성 문제#

가장 일반적인 HTTPS 구성 문제는 자체 서명 또는 잘못된 HTTPS 인증서를 사용하는 루트 클러스터에서 발생합니다. 루트 클러스터의 web_proxy_addr 엔드포인트가 자체 서명 또는 잘못된 HTTPS 인증서를 사용하는 경우 다음과 유사한 오류가 표시될 가능성이 높습니다: The trusted cluster uses misconfigured HTTP/TLS certificate.

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

연결 문제#

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

연결 문제를 해결하려면 루트 클러스터와 리프 클러스터 모두의 Teleport Auth Service에서 상세 출력을 활성화합니다. 일반적으로 teleport 서비스를 시작하는 명령에 --debug 플래그를 추가하면 됩니다:

teleport start --debug`

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

# Snippet from /etc/teleport.yaml
teleport:
  log:
    output: stderr
    severity: DEBUG

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

$ journalctl -fu teleport

대부분의 경우 초대 토큰이 일치하지 않거나 만료되었거나, 기존 방화벽 규칙이나 AWS에서 네트워크 보안 그룹이 구성된 방식으로 인해 tunnel_addr 또는 web_proxy_addr에 대한 네트워크 주소에 도달할 수 없다는 것을 알게 될 것입니다.

접근 문제#

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

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

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

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

    Teleport를 관리형 클라우드 기반 서비스로 사용하는 경우, 감사 로그는 event 리소스에 대한 권한이 있는 사용자의 Web UI 왼쪽 창에서 Audit를 통해 볼 수 있습니다.

신뢰할 수 있는 클러스터 내의 애플리케이션 접근#

루트 및 리프를 포함한 전체 클러스터에서 고유한 애플리케이션 이름을 갖는 것이 권장됩니다. 리프 클러스터가 제공하는 애플리케이션은 루트 클러스터에서 app_name.root_proxy_public_addr를 통해 접근합니다. FQDN만으로 앱에 접근하는 경우 모호한 해석이 발생할 수 있습니다. 앱이 여러 클러스터에서 동일한 이름을 포함해야 하는 경우, 올바른 앱에 접근하는 가장 확실한 방법은 Web UI의 리소스 페이지를 통하는 것입니다.