Teleport 가이드

Auth Service

인증 기관 CA(Certificate Authority)로서 호스트와 사용자 인증서를 서명합니다. 역할, 사용자, 등록된 리소스 같은 클러스터 설정을 보관하고 감사 이벤트와 세션 기록을 수집합니다. 사설망에 두는 것이 기본 구성입니다.

Proxy Service

사용자의 단일 진입점입니다. Web UI(웹 관리 화면)를 제공하고 SSH, Kubernetes, 데이터베이스, 웹 앱 트래픽을 중계하며 Agent가 맺은 리버스 터널의 종단 역할을 합니다. 공중망에서 주소를 지정할 수 있어야 하는 구성 요소는 Proxy Service 하나입니다.

Agent (Service)

teleport 바이너리 인스턴스이며 물리 서버, 가상 머신, 컨테이너, Kubernetes Pod 어디에서나 동작합니다. SSH, Kubernetes, Database, Application, Desktop 5종 서비스로 나뉘고, 리소스를 자동으로 찾아 등록하는 Discovery Service가 더해집니다.

비밀번호 금고가 아닙니다

대상 시스템의 비밀번호를 보관했다가 대신 입력하는 방식이 아닙니다. 접속할 때마다 수명이 짧은 인증서를 새로 발급하므로, 교체하거나 보관해야 할 상시 자격 증명이 대상 시스템에 남지 않습니다.

네트워크 방화벽을 대체하지 않습니다

접근 경로를 하나로 모으고 그 경로에 신원과 권한을 붙이는 계층입니다. 망 분리, 방화벽 정책, 네트워크 구간 설계는 그대로 유지합니다.

별도 접속 도구를 강제하지 않습니다

kubectl, psql, 브라우저 같은 기존 도구를 그대로 씁니다. 인증과 경로만 Teleport를 지나며, 사용자는 자격 증명 파일을 따로 받지 않습니다.

단일 노드 셀프호스팅

Auth Service와 Proxy Service를 한 프로세스로 올립니다. 기능 검증과 PoC(Proof of Concept)에 적합합니다. 클러스터 상태와 감사 기록, 세션 기록을 로컬 디스크에 두므로 디스크 용량을 넉넉히 잡습니다.

Kubernetes Helm 차트

teleport-cluster 차트로 컨트롤 플레인을, teleport-kube-agent 차트로 에이전트를 배포합니다. 규모가 커지는 셀프호스팅 구성에서 공식 문서가 권장하는 방식입니다.

Teleport Cloud

Auth Service와 Proxy Service를 Teleport가 운영합니다. 고객은 에이전트만 설치하며 컨트롤 플레인의 이중화, 백업, 업그레이드를 직접 다루지 않습니다.

기본 도메인과 와일드카드

Proxy Service 주소로 쓸 이름 하나가 필요합니다. 웹 앱 접근(Application Access)을 쓰면 와일드카드 이름 *.teleport.example.com이 추가로 필요합니다. Teleport가 앱마다 <앱 이름>.<도메인> 주소를 부여하기 때문이며, 와일드카드를 쓰면 앱 수와 상관없이 DNS 레코드 하나와 인증서 한 장으로 처리됩니다. 와일드카드를 쓸 수 없으면 앱마다 public_addr로 개별 레코드를 지정하는 대안이 있습니다.

인증서는 Proxy가 보유합니다

위 두 이름을 SAN(Subject Alternative Name)에 포함한 인증서 한 장을 준비합니다. 앞단에 로드밸런서를 두는 경우 TLS를 종단하지 않고 그대로 통과시키는 L4(Layer 4) 구성이어야 합니다. 앞단이 TLS를 종단하면 Kubernetes 접근의 SNI(Server Name Indication) 라우팅과 프로토콜 분기가 깨집니다. 고가용성 구성에서는 Teleport 내장 자동 발급 기능을 쓰지 않고 별도 발급 경로를 둡니다.

SSO 그룹과 역할 연결

OIDC groups 클레임을 Teleport 역할로 연결해 조직 기준 권한을 그대로 유지합니다. 사용자 목록을 Teleport에 따로 만들지 않으므로 입사와 퇴사 처리가 IdP 한 곳에서 끝납니다.

Kubernetes 중심 제어

클러스터, 네임스페이스, Pod 접근을 역할과 라벨로 나눕니다. kubernetes_labels로 어느 클러스터인지 정하고, kubernetes_resources로 종류, 네임스페이스, 이름, 동사 범위를 정합니다.

감사와 세션 증적

JSON 감사 이벤트와 kubectl exec 세션 기록이 남습니다. 세션은 tsh play와 Web UI에서 재생하고, 감사 이벤트는 외부 로그 플랫폼으로 내보내 보관할 수 있습니다.

JIT(Just In Time) 승인

상시 권한 대신 필요한 때만 권한을 올립니다. Access Request로 역할이나 개별 리소스를 요청하고, 승인자 수와 유효 시간을 요청 종류마다 정합니다. 두 명 승인도 설정할 수 있습니다.

두 층 RBAC

Teleport 역할과 클러스터 RBAC 중 좁은 쪽이 남습니다. 어느 쪽도 우선하지 않고 두 범위의 교집합이 실효 권한이 됩니다. Teleport에는 누가 어디까지 닿는지를, 클러스터에는 닿은 다음 무엇을 할 수 있는지를 둡니다.

고객이 준비하는 것

• 대상 Kubernetes 클러스터 1개. 개발 성격 클러스터를 권장하며 Helm 설치 권한이 필요합니다.
• IdP 그룹 예시. 요청자와 승인자 역할에 해당하는 그룹 각각 1개 이상과 테스트 사용자 2명입니다.
• DNS 이름과 TLS 인증서 발급 방식. 기본 도메인 1개, 웹 앱 검증이 범위에 들어가면 와일드카드 1개를 더 준비합니다.
• 네트워크 경로 승인. 3장 네트워크 요건 표의 1번에서 3번 항목입니다.

인포그랩이 제공하는 것

• 평가용 Enterprise 라이선스와 설치 패키지. 폐쇄망이면 오프라인 번들로 준비합니다.
• 구성 파일 초안. teleport.yaml, SSO 커넥터, 역할 세트, 자동 검색 설정을 포함합니다.
• 시나리오별 측정 시트와 결과 보고서. 주차별 산출물을 재현 가능한 형태로 남깁니다.