인증
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
역할 기반 접근 제어에 대한 더 많은 세부정보는 역할 문서를 참조하세요.
자격 증명
Teleport Go 클라이언트는 Teleport 클러스터와 인증하기 위해 자격 증명이 필요합니다.
자격 증명은 Teleport CLIs에서 생성된 인증서와 데이터를 수집하는 Credential loaders를 사용하여 생성됩니다.
여러 가지 이점이 있는 다양한 Credential loaders가 있으므로 다음은 빠른 분석입니다:
- 프로파일 자격 증명은 시작하기에 가장 쉽습니다.
tsh login을 통해 장치에 로그인하기만 하면 됩니다. Teleport 프록시 주소와 자격 증명이 자동으로 검색되어 사용됩니다. - 신원 파일 자격 증명은 사용성, 기능성 및 사용자 정의 가능성 측면에서 가장 균형 잡힌 것입니다. 신원 파일은
tsh login,tctl auth sign또는 Machine ID를 통해 생성할 수 있습니다. - 동적 신원 파일 자격 증명은 디스크에서 자격 증명을 다시 로드하는 기능이 있는 신원 파일 자격 증명입니다. 따라서 기계 ID 통합에 적합하며, 기계 ID가 기본 신원 파일을 회전할 때 자격 증명을 다시 로드할 수 있습니다.
- 키 쌍 자격 증명은 나열된 다른 자격 증명보다 구현이 훨씬 간단하며, 더 친숙하게 느껴질 수 있습니다. 이는 auth 서버에 직접 호스팅된 클라이언트를 인증하는 데 좋습니다.
- TLS 자격 증명은 모든 것을 클라이언트 사용자에게 맡깁니다. 이것은 주로 내부적으로 사용되지만 일부 고급 사용자에게 유용할 수 있습니다.
다음은 자격 증명을 구별하기 위한 더 구체적인 세부정보입니다:
| 유형 | 프로파일 자격 증명 | 신원 자격 증명 | 키 쌍 자격 증명 | TLS 자격 증명 |
|---|---|---|---|---|
| 사용 용이성 | 쉬움 | 쉬움 | 보통 | 어려움 |
| 장기 생존 인증서 지원 | 예, 하지만 서버 측에서 구성해야 함 | 예 | 예 | 예 |
| SSH 연결 지원 | 예 | 예 (6.1+) | 아니오 | 아니오 |
| 자동 프록시 주소 검색 | 예 | 아니오 | 아니오 | 아니오 |
| 사용 CLI | tsh | tctl/tsh | tctl | - |
| 사용 가능 버전 | 6.1+ | 6.0+ | 6.0+ | 6.0+ |
자격 증명 및 자격 증명 로더에 대한 더 많은 정보와 예제를 보려면 Credentials type 링크를 참조하세요.
클라이언트 연결
API 클라이언트는 Teleport Auth 서버에 대한 열린 연결을 통해 요청을 보냅니다.
Auth 서버가 프록시 서버 뒤에 격리된 경우, Auth 서버에 의해 서명된 SSH 인증서를 사용하여 리버스 터널 연결을 만들 수 있습니다. 서버의 리버스 터널 주소를 직접 제공하거나 웹 프록시 주소를 제공하고 클라이언트가 자동으로 리버스 터널 주소를 검색하도록 할 수 있습니다.
모든 Credential loaders가 mTLS 연결을 지원하는 반면, 일부만 SSH 연결을 지원합니다(위의 차트 참조).
이 클라이언트 생성자 예제를 살펴보면 이러한 연결 옵션이 어떻게 생겼는지 확인할 수 있습니다.