API 아키텍처

Teleport gRPC API의 아키텍처 개요.

이 가이드에서는 tctl , Teleport Terraform 공급자, Teleport Kubernetes 오퍼레이터와 같은 클라이언트가 Teleport 클러스터의 동적 리소스를 관리할 수 있도록 하는 Teleport gRPC API의 아키텍처를 설명합니다. Teleport gRPC API가 처음이라면 시작하기 를 읽어보세요. 인증 # Auth API는 클라이언트-서버 연결을 인증하기 위해 mTLS를 사용합니다. 따라서 클라이언트는 API에 접근하기 위해 Auth 서비스가 서명한 TLS 인증서를 제공해야 합니다. 이는 자격 증명 로더 를 사용하여 쉽게 생성하고 제공할 수 있습니다. 권한 부여 # Auth 서비스가 서명한 클라이언트 인증서는 특정 사용자와 연결됩니다. 이 사용자는 클라이언트가 만든 API 요청을 권한 부여하는 데 사용됩니다. 각 클라이언트마다 새 사용자와 역할을 만드는 것이 좋습니다. 이를 통해 클라이언트 작업을 더 쉽게 추적할 수 있으며, 클라이언트 권한을 신중하게 제어할 수 있습니다. 예를 들어, 클라이언트가 client.GetRole() 을 사용해야 한다면, 사용자는 role 리소스에서 read 작업을 수행할 권한이 있어야 합니다. 필요한 최소 권한으로 사용자와 역할을 만들어야 합니다. 프로덕션 보안 모범 사례 Teleport를 프로덕션 환경에서 실행할 때는 보안 사고를 방지하기 위해 다음 모범 사례를 준수해야 합니다: 꼭 필요한 경우가 아니면 프로덕션 환경에서 sudo 사용을 피하십시오. 새로운 non-root 사용자를 생성하고, Teleport를 테스트할 때는 테스트 인스턴스를 사용하십시오. 필요한 경우가 아니면 Teleport의 서비스를 non-root 사용자로 실행하십시오. root 접근이 필요한 것은 SSH Service뿐입니다. Teleport가 1024 보다 작은 번호의 포트(예: 443 )에서 수신 대기하도록 하려면 root 권한(또는 CAP_NET_BIND_SERVICE 기능)이 필요하다는 점에 유의하십시오. 최소 권한의 원칙 을 따르십시오. 더 제한적인 역할로 충분한 경우 사용자에게 허용 범위가 넓은 역할을 부여하지 마십시오. 예를 들어, 모든 클러스터 리소스에 접근하고 편집할 수 있는 권한을 부여하는 내장 access,editor 역할을 사용자에게 할당하지 마십시오. 대신 각 사용자에게 필요한 최소한의 권한으로 역할을 정의하고, 일시적으로 상승된 권한을 제공하기 위해 Access Request 를 구성하십시오. Teleport 리소스(예: 새 데이터베이스나 애플리케이션)를 등록할 때는 초대 토큰을 파일에 저장해야 합니다. 토큰을 명령줄에 직접 입력하면, 악의적인 사용자가 침해된 시스템에서 history 명령을 실행하여 이를 볼 수 있습니다. 이러한 사례가 문서에서 사용된 예시에 반드시 반영되어 있는 것은 아니라는 점에 유의하십시오. 문서의 예시는 주로 시연 및 개발 환경을 위한 것입니다. 아래를 복사하여 Teleport Auth 서비스에서 실행하세요: # 역할 구성 생성 $ cat > api-rol