Teleport 거쳐서 사용자 리소스(VM) 연결하기

 

이전 단계(Provisioning flow)에서 프로비저닝 부분을 개발하면서, 사용자가 웹 UI로 인스턴스 생성 요청하면 Proxmox(실제 인프라 관리 도구)에서 리소스를 생성해주고 이후에 post-provisioning 스크립트를 실행해주는 걸 볼 수 있었다.

(관련 글 인덱스 : https://miiml.tistory.com/18)

 

이제 이전에 Core에 구성했던 PAM (Teleport)을 사용해서 생성된 리소스들에 접근할 수 있게 해줘야 한다.

(Teleport 구성 글 : https://miiml.tistory.com/8)

 

설계에 앞서 기획 단계에서 작성해뒀던 몇 가지 요구사항들이 있는 데 좀 정리해보면

 

일단 사용자는 우리 서비스가 Core 레이어에서 어떤 툴들을 사용하는지 몰라야 한다. (정확히는 상관없어야 됨)

• 시스템 요구사항에선 REQ-SYS-002 부분이 해당 내용과 겹치는 거 같고 (근데 사실 이건 BFF 패턴 등 프론트 영역과 더 가까운 듯)
• 사용자 요구사항의 REQ-USR-002 부분도 맥락이 같다.

그리고 사용 과정에서 별도의 수동 작업 (설정 등) 없이 리소스에 접근하게 할 수 있어야 한다. 

• 이 부분도 REQ-USR-001 이랑 같은 기능인 것 같다.

 

아무튼 저런 요구사항들을 최대한 고려해서 설계를 해보긴했는데, 사실 Teleport와 연동하는 방법은 어느정도 정해져있다. (특히 JAVA Spring Boot는 SDK 지원이 안되서 옵션이 좀 더 적음)

 

우선 OpenCSP에서 Teleport 연동에 신경써야 할 건 크게 2가지다. 

1. Teleport 인증 
2. SSH 트래픽 중계 (SSL handshake, SSH real-time relaying)

인증은 tbot과 봇계정을 사용하면 되지만 실제 리소스에 SSH 접근하는 건 ssh 라이브러리 등으로 직접 구현하긴 어렵고 (Teleport는 SSH 연결에 자체 프로토콜 등을 사용하기 때문에) 이렇게 할 경우 오픈소스 버전 업그레이드에 맞게 계속 수정도 해줘야 된다.

그래서 공식 도구인 tsh, tbot 그리고 Teleport가 가장 잘 지원하는 Go SDK를 잘 활용해서 개발해주기로 했다.

 

구현 난이도에 따라 아래 3가지 정도로 정리해봄

 

옵션 1. BE에서 tsh(Teleport 전용 쉘 도구) 호출하기 (MVP 초기 방식)

제일 쉬운 방식이지만 백엔드에서 CLI로 외부 툴을 호출해야한다.

이런 개발 방식을 별로 선호하진 않지만 우선 빠르게 동작을 테스트한다는 관점에선 나쁘지 않았다.

 

구현은 백엔드랑 같은 공간에 tsh 바이너리를 같이 넣어주고, 명령어를 직접 호출해서 인증 후 중계 해주면 되지만 이렇게 할 경우 직접 tsh 명령어를 호출해서 인증서를 받아와야 하는데 인증서 자체의 유효기간이 짧고, 인증 과정에 MFA가 강제된다. (텔레포트 정책)

그래서 테스트할 땐 인증 부분을 직접 수동으로 갱신해줬었다.

 

 

 

옵션 2. 인증은 tbot, 중계는 tsh 활용 (현재 배포된 MVP에 적용된 방식) 

Teleport는 Bot 계정을 제공해주는데, 해당 계정과 Role을 설정하고 tbot으로 등록해주면 인증서를 자동으로 갱신해서 관리해준다. 

 

 

컨테이너로 BE를 빌드하고 쿠버네티스에 배포도 할 거니까 BE 컨테이너 내부에 tsh 바이너리를 똑같이 넣어주고, 중계할 때 파라미터로 identity 옵션으로 인증서를 지정해주면 된다. 

 

쿠버네티스 환경에서 인증서를 공유하는 방법은 2가지 정도 있는데

 

우선 위에 그림에 있는대로 공유 볼륨을 마운트하는 방식이 많이 쓰이지만 컨테이너가 다르므로 (사이드카) fsGroup을 같게 지정하고 그룹 읽기 권한을 주거나 (440), 컨테이너간 UID를 맞춰줘야 한다.

 

이렇게 해두면 BE에서도 딜레이없이 거의 실시간으로 인증이 갱신된다. 

근데 보안 좀 신경쓰면서(?) 구성 편하게 하고 싶으면 tbot이 Kubernetes Secret에 인증서를 배포하게 해두고,

그걸 BE가 읽어오게 하면 되는데 이 경우에도 인증서 자체의 값을 별도로 암호화를 해두는 게 권장된다.

 

 

옵션 3. Go SDK로 Teleport 인증/ 중계용 백엔드를 내부에 배포하고 tbot 사이드카로 인증 

3번이 내가 생각하는 제일 이상적인 방법인데 Teleport와 같은 Namespace에 별도의 Go 백엔드를 개발해서 파드로 배포해두고

인증은 tbot이 하고, ssh 릴레이는 SDK를 사용해서 개발해주는 방식임

 

이렇게 할 경우 goroutine을 활용하면 대량의 세션 처리도 어느정도 가능할 거 같다. (파드로 배포되어서 파드 자체의 scale-out도 가능)

 

 

 

현재 시점 기준으론 옵션 2로 개발되어 있고 tbot을 사용해 인증할 때 봇 자체(be 시스템)의 인증은 잘 갱신이 되지만 각 사용자의 Audit이 남지 않는다는 문제가 있다. (Teleport 입장에선 다 bot 이 요청한 거니까)

 

그래서 IAM과 Teleport의 사용자 목록을 동기화하고 teleport-impersonate (https://goteleport.com/docs/zero-trust-access/authentication/impersonation/) 기능을 활용해서 Audit을 남기게 해주려고 한다.

 

ssh 릴레이 방식도 지금은 컨테이너 내에서 tsh 프로세스를 사용하니까 동시 처리가 버거울 거 같아서 이것도 같이 고민 중임

 

---

관련 글: 2026.03.20 - [프로젝트/OpenCSP] - k3s에 Teleport 올리고 리소스 연결하기