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 작업을 수행할 권한이 있어야 합니다. 필요한 최소 권한으로 사용자와 역할을 만들어야 합니다. Best practices for production security When running Teleport in production, you should adhere to the following best practices to avoid security incidents: Avoid using sudo in production environments unless it's necessary. Create new, non-root, users and use test instances for experimenting with Teleport. Run Teleport's services as a non-root user unless required. Only the SSH Service requires root access. Note that you will need root permissions (or the CAP_NET_BIND_SERVICE capability) to make Teleport listen on a port numbered < 1024 (e.g. 443 ). Follow the principle of least privilege . Don't give users permissive roles when more a restrictive role will do. For example, don't assign users the built-in access,editor roles, which give them permissions to access and edit all cluster resources. Instead, define roles with the minimum required permissions for