인포레터에서 최신 DevOps 트렌드를 격주로 만나보세요!
API 아키텍처
이 가이드는 Teleport gRPC API의 아키텍처를 설명합니다. 이는 tctl , Teleport Terraform 공급자, 그리고 Teleport Kubernetes 운영자와 같은 클라이언트가 Teleport 클러스터의 동적 리소스를 관리할 수 있도록 합니다. Teleport gRPC API가 처음이라면, 시작하기를 읽어보십시오.
인증
Auth API는 mTLS를 사용하여 클라이언트-서버 연결을 인증합니다. 따라서 클라이언트는 API에 접근하기 위해 Auth 서버에 의해 서명된 TLS 인증서를 제공해야 합니다. 이러한 인증서는 Credential loaders를 사용하여 쉽게 생성하고 제공할 수 있습니다.
인가
Auth 서버에 의해 서명된 클라이언트 인증서는 특정 사용자와 연관됩니다. 이 사용자는 클라이언트가 수행하는 API 요청을 인가하는 데 사용됩니다.
모든 클라이언트에 대해 새로운 사용자와 역할을 만드는 것이 좋습니다. 이렇게 하면 클라이언트 작업 추적이 용이해지고 클라이언트 권한을 신중하게 제어할 수 있습니다.
예를 들어 클라이언트가 client.GetRole()를 사용해야 한다면, 사용자는 role 리소스에 대한 read 작업을 수행할 수 있는 권한을 가져야 합니다. 필요한 최소 권한으로 사용자와 역할을 생성해야 합니다.
Teleport를 운영 환경에서 실행할 때 보안 사고를 피하기 위해 다음의 모범 사례를 준수해야 합니다:
- 필요하지 않는 한 운영 환경에서
sudo사용을 피하십시오. - 새로운 비루트 사용자를 생성하고 Teleport 실험을 위해 테스트 인스턴스를 사용하십시오.
- 필요하지 않은 한 비루트 사용자로 Teleport의 서비스를 실행하십시오. SSH 서비스만 루트 액세스를 요구합니다. Teleport가 <
1024(예:443)로 번호 매겨진 포트에서 수신 대기하도록 하려면 루트 권한(또는CAP_NET_BIND_SERVICE권한)이 필요합니다. - 최소 권한 원칙을 따르십시오. 더 제한적인 역할로도 충분할 때 사용자에게 허용적인 역할을 부여하지 마십시오.
예를 들어, 클러스터 리소스에 액세스하고 편집할 수 있는 권한을 부여하는 내장된
access,editor역할을 사용자에게 할당하지 마십시오. 대신 각 사용자에 대해 최소한의 필수 권한을 가진 역할을 정의하고 액세스 요청을 구성하여 일시적으로 상승된 권한을 부여하십시오. - 새로운 데이터베이스나 애플리케이션과 같은 Teleport 리소스를 등록할 때 초대 토큰을 파일에 저장해야 합니다.
명령줄에 직접 토큰을 입력하면 악성 사용자가 손상된 시스템에서
history명령을 실행하여 이를 볼 수 있습니다.
이러한 관행이 문서에서 사용된 예제에 반드시 반영되는 것은 아닙니다. 문서의 예제는 주로 데모 및 개발 환경을 위한 것입니다.
아래 내용을 복사하여 Teleport Auth 서버에서 실행합니다.
cat > api-role.yaml <<EOFkind: rolemetadata: name: api-rolespec: allow: rules: - resources: ['role'] verbs: ['read'] deny: node_labels: '*': '*'version: v5EOF역할 생성
tctl create -f api-role.yaml사용자 추가 및 웹 프록시를 통한 로그인
tctl users add api-user --roles=api-role
역할 기반 액세스 제어에 대한 자세한 내용은 roles 문서를 참조하십시오.
자격 증명
Teleport Go 클라이언트는 Teleport 클러스터와 인증하기 위해 자격 증명이 필요합니다.
자격 증명은 Credential loaders를 사용하여 생성됩니다. 이러한 Credential loaders는 Teleport CLIs에서 생성된 인증서와 데이터를 수집합니다.
여러 Credential loaders가 각각의 장점으로 제공되므로, 간단한 개요는 다음과 같습니다:
- 프로필 자격 증명은 시작하기 가장 쉬운 방법입니다. 장치에서
tsh login으로 로그인하기만 하면 됩니다. Teleport 프록시 주소와 자격 증명이 자동으로 찾아지고 사용됩니다. - Identity File 자격 증명은 사용성, 기능성 및 사용자 정의 가능성 측면에서 가장 균형 잡혀 있습니다. Identity 파일은
tsh login,tctl auth sign, 또는 Machine ID를 통해 생성할 수 있습니다. - Dynamic Identity File 자격 증명은 디스크에서 자격 증명을 다시 로드하는 기능을 지원하는 Identity File 자격 증명입니다. 이는 Machine ID 통합에 적합하므로 Machine ID가 기본 Identity 파일을 회전할 때 자격 증명을 다시 로드할 수 있습니다.
- Key pair 자격 증명은 다른 자격 증명보다 구현이 훨씬 간단하며 더 익숙한 느낌을 줄 수 있습니다. 이러한 자격 증명은 Auth 서버에 직접 호스팅되는 클라이언트 인증에 적합합니다.
- TLS 자격 증명은 모든 것을 클라이언트 사용자에게 맡깁니다. 이는 주로 내부에서 사용되지만 일부 고급 사용자는 유용하다고 느낄 수 있습니다.
여기에 몇 가지 세부 정보를 더하여 구분할 수 있습니다:
| 유형 | 프로필 자격 증명 | Identity 자격 증명 | Key Pair 자격 증명 | TLS 자격 증명 |
|---|---|---|---|---|
| 사용 용이성 | 쉬움 | 쉬움 | 중간 | 어려움 |
| 장기 인증서 지원 | 예, 하지만 서버 측에서 구성해야 함 | 예 | 예 | 예 |
| SSH 연결 지원 | 예 | 예 (6.1+) | 아니오 | 아니오 |
| 자동 프록시 주소 검색 | 예 | 아니오 | 아니오 | 아니오 |
| 사용되는 CLI | tsh | tctl/tsh | tctl | - |
| 제공되는 버전 | 6.1+ | 6.0+ | 6.0+ | 6.0+ |
자격 증명 및 Credential Loaders에 대한 더 많은 정보와 예시는 Credentials type에서 확인하십시오.
클라이언트 연결
API 클라이언트는 Teleport Auth 서버에 대한 열린 연결을 통해 요청을 수행합니다.
Auth 서버가 프록시 서버 뒤에 격리되어 있는 경우, 인증 서버에 의해 서명된 SSH 인증서를 사용하여 리버스 터널 연결을 만들 수 있습니다. 서버의 리버스 터널 주소를 직접 제공하거나 웹 프록시 주소를 제공하여 클라이언트가 자동으로 리버스 터널 주소를 검색하도록 할 수 있습니다.
Note
모든 자격 증명 로더는 mTLS 연결을 지원하지만, 일부만 SSH 연결을 지원합니다(위의 차트를 참조하세요).
클라이언트 생성자 예시를 살펴보면 이러한 연결 옵션이 어떻게 생겼는지 확인할 수 있습니다.