1. 구조의 변경
기존 구조는 AI가 잘 그려줬는데,
당시에는 Mesh VPN(Tailscale) 이 네트워크 연결을 담당하고, Teleport가 사용자 인증과 세션 관리를 담당하는 구조를 구상했습니다.
역할을 명확하게 분리하면 운영도 단순해질 것이라고 생각했습니다만 실제로 구현을 진행하면서 두 시스템을 함께 운영하는 것이 생각보다 쉽지 않다는 것을 알게 되었습니다.
가장 큰 문제는 접속 승인과 접속 종료의 기준이 서로 달랐다는 점입니다.
Tailscale은 네트워크 접근을 제어하는 도구이고, Teleport는 사용자와 SSH 세션을 관리하는 도구입니다. 즉, 네트워크 연결 상태와 실제 SSH 세션의 생명주기가 서로 일치하지 않았습니다.
특히 승인 시간이 끝났을 때 이미 연결되어 있는 세션을 어떻게 종료할 것인가가 가장 큰 고민이었습니다. Teleport Enterprise에서는 세션 관리 기능이 더 다양하게 제공되지만, Community Edition을 자체 호스팅하는 환경에서는 선택지가 많지 않았습니다.
여러 방법을 검토한 결과, 사용자의 접근을 가장 확실하게 제어할 수 있는 방법은 Lock 기능을 사용하는 것이었습니다. 그래서 기존 구조를 조금 단순하게 변경하기로 했습니다.
Mesh VPN에 의존하여 접근을 제어하는 대신, Teleport를 중심으로 사용자 인증과 접근 제어를 수행하는 구조로 변경했습니다.
변경 과정에서 중요하게 생각한건 기존에 요구했던 관리자의 요구사항을 충족할 수 있냐는 것이었는데, 관리자의 핵심 요구사항은
- 시간제한
- 허가시 접속
- 강제 접속 차단
이었는데 이 요구사항을 모두 충족할 수 있어 변경을 진행했습니다.
2. Teleport는 어떻게 동작할까요?
Teleport를 이해할 때 핵심은 세 가지입니다.
- Proxy Service
- Auth Service
- Teleport Agent
Proxy Service
Proxy Service는 외부 사용자가 처음 만나는 진입점입니다. 사용자는 대상 서버에 직접 SSH로 접속하지 않습니다. 먼저 Teleport Proxy로 접속하고, Proxy가 인증된 사용자의 요청을 내부 리소스로 전달합니다.
즉, Proxy는 외부에 노출되는 유일한 관문입니다.
Auth Service
Auth Service는 사용자가 누구인지, 어떤 권한을 가지고 있는지 판단합니다.
여기서 MFA, Role, RBAC, 인증서 발급 같은 처리가 이루어집니다.
간단히 말하면,
Proxy가 문이라면, Auth Service는 출입 허가를 판단하는 곳입니다.
Teleport Agent
Teleport Agent는 실제 접속 대상이 되는 서버나 PC에 설치됩니다. Agent는 대상 장비를 Teleport Cluster에 등록하고, Proxy와 연결되어 사용자의 SSH 요청을 받아줍니다.
특히 Agent가 Reverse Tunnel 방식으로 연결되면, 대상 PC가 외부에서 직접 접근 가능하지 않아도 Teleport를 통해 접속할 수 있습니다.
이 점이 기존 VPN이나 단순 SSH 포트 개방과 가장 다른 부분이었습니다.
정리하면 Teleport의 기본 흐름은 아래와 같습니다.
사용자
↓
Teleport Proxy
↓
Teleport Auth
↓
Teleport Agent
↓
대상 서버 / PC사용자는 서버에 직접 접속하지 않고, Teleport를 통해 인증·권한 확인·세션 기록을 거친 뒤 대상 장비에 접근합니다.
이 구조 덕분에 단순한 SSH 접속이 아니라, 누가 언제 어떤 장비에 접속했는지 관리 가능한 원격접속 구조를 만들 수 있었습니다.
3. 변경은 고통의 연속
이번에도 AI가 노력해줬는데, 실제 구조는 위 구조와 크게 다르지 않은 구조인데 이보다 나은 그림을 AI가 그리지 못해 이 그림으로 설명하겠습니다.
만들면서 다양한 고민을 하게 됐는데
- 정말 신청한 사용자가 접속한 것이 맞을까?
Lock만 적용하면 승인된 사용자는 접속할 수 있습니다. 하지만 또 다른 문제가 남아 있었습니다.
정말 신청한 사용자가 접속한 것이 맞을까?
예를 들어 A 사용자가
node-01에 대한 접근을 신청했다고 가정해 보겠습니다. 만약 실제 Teleport 로그에는 A 사용자가 node-02에 접속한 기록이 남는다면 어떻게 해야 할까요?관리자가 모든 세션 로그를 실시간으로 확인하는 것은 현실적으로 불가능합니다. 그래서 Teleport의 Session Start 로그를 주기적으로 수집하고,
신청 정보(DB)와 비교하는 감사 엔진을 추가했습니다.
비교 결과가 일치하면 정상 접근으로 처리하고,
신청 정보와 다른 사용자나 Node가 감지되면 즉시 해당 계정을 Lock하고 관리자에게 알림을 보내도록 구현했습니다.
Teleport 컨테이너의 로그 노이즈가 심해서 곤란한 상황이 몇 번 있었지만 몇 가지 확정적인 값(Session Start Event 등) 을 기반으로 원하는 목표를 달성할 수 있었습니다.
- 접속 권한을 계정 Lock이 풀리는 시간에 할당할 수는 없을 까?
처음에는 Lock/Unlock만으로는 조금 아쉽다는 생각이 들었습니다.
조금 더 자연스러운 방법은 승인 시간이 되었을 때 접속 권한 자체를 부여하고, 종료 시간이 되면 다시 회수하는 것이었습니다.
10:00 Teleport User에 login 권한 추가, os 할당
12:00 login, os 권한 제거이런 구조라면 Lock을 사용하지 않아도 승인 시간을 표현할 수 있을 것 같았습니다. 실제로 Teleport에서는 사용자에게 접속 가능한 Linux 계정을
traits.logins를 통해 관리합니다.그래서 처음에는 이 값을 동적으로 변경하는 방식을 검토했습니다.
가장 큰 문제는 이미 인증된 세션에는 즉시 반영되지 않는 경우가 가끔식 있다는 점이었습니다.
사용자의
traits.logins를 제거했다고 해서 이미 연결된 SSH 세션이 바로 종료되는 것은 아니었습니다.이 문제는 신규 신청 시, 문제 발생 시 재로그인하는 것을 안내하는 것으로 마무리했습니다.
- Teleport Node
연결을 해제하기 위해 또 다른 방법도 시도했습니다. 그렇다면 Node 자체를 삭제하면 어떨까?
Node가 없어지면 더 이상 접속할 수 없을 것이라고 생각했습니다. 실제로 Node 삭제도 테스트해 보았습니다. 하지만 결과는 기대와 달랐습니다. Node를 삭제해도 이미 연결되어 있는 세션은 그대로 유지되었습니다.
Node 등록 상태와 현재 열려 있는 SSH 세션은 별개의 개념이었던 것입니다. 결국 권한을 동적으로 추가·삭제하는 방식도, Node를 등록·삭제하는 방식도 운영 정책을 구현하기에는 적합하지 않았습니다.
이 시점에서 Teleport의 Lock 기능을 중심으로 접근 제어를 구현하기로 결정했습니다.
또 하나 고민했던 것은 Node 관리였습니다. 처음에는 승인이 끝나면 Node 자체를 삭제하는 방법도 고려했습니다. 하지만 실제로 테스트해 보니 기대했던 방식으로 동작하지 않았습니다.
Teleport Node는 단순한 등록 정보가 아니라, 등록된 PC에서 실행 중인 Teleport Agent가 지속적으로 관리하는 리소스였습니다. 따라서 서버에서 Node를 삭제하더라도, 해당 PC에서 Agent가 계속 실행 중이라면 다시 Node가 등록되었습니다.
결국 Node를 삭제하는 방식은 접근 제어 수단으로 적합하지 않았습니다. 오히려 등록된 PC는 지속적으로 클러스터에 참여하도록 두고, 사용자 권한과 접근 정책만 관리하는 구조가 운영 측면에서 훨씬 안정적이었습니다.
이 때문에 Node는 삭제와 생성을 반복하는 대상이 아니라, 태그(Tag)와 메타데이터를 통해 지속적으로 관리해야 하는 리소스라는 결론을 내렸습니다.
Node 삭제 방법
Teleport Node는 tctl command만으로 삭제가 불가능하여, 반드시 등록된 Node의 PC에 직접 들어가 Agent 자체를 삭제해야 삭제 됩니다.
4. 결국 Teleport를 구축한 것은 아니었습니다만..
여기까지 오면서 정말 많은 방법을 시도했습니다. Tailscale ACL로 접근을 제어하는 방법도 고민했고,
traits.logins를 동적으로 변경하는 방법도 테스트했습니다. Node를 삭제해서 연결을 차단하는 방법도 검토했습니다. Teleport 로그를 분석하며 세션 이벤트를 추적했고, Docker 로그에서 필요한 정보만 추출하기 위해 여러 번 필터링도 수정했습니다.
Teleport는 단지 하나의 구성 요소였고.. 실제로는
- 사용자가 접속을 신청하고
- 관리자가 승인하고
- 승인 시간에 맞춰 자동으로 Lock/Unlock이 이루어지고
- 실제 접속 로그를 신청 정보와 비교하고
- 정책과 다른 접근이 감지되면 즉시 Lock과 알림이 수행되는
원격접속 플랫폼을 만들게 됐습니다.
물론 아직 아쉬운 부분도 있습니다.
Community Edition에서는 Enterprise에서 제공하는 일부 기능을 사용할 수 없었고, Teleport의 이벤트 처리 방식도 운영 정책을 구현하기에는 직접 보완해야 하는 부분이 있었습니다.
또한 현재는 Session Start를 중심으로 검증하고 있지만, 향후에는 Session End, Command Audit, 파일 전송까지 포함한 정책도 검토해 볼 생각입니다.
Q. 왜 Teleport인가요?
무료주제애 기능도 많아서.
Q. VPN만으로는 안 되나요?
- VPN = Network
- Teleport = Identity & Session
Q. Community Edition으로 충분한가요?
저는 충분 했는데 충분하지 않을 수도 있으니, 검색 권장
Q. 가장 곤란한 문제는?
승인 정책과 실제 SSH 세션을 일치시키는 것, 정책은 종료되었는데 실제 접속은 계속 유지되는 상황이 발생할 수 있었습니다. 그리고 사용자를 빌런으로 규정하고 신뢰하기 어렵다고 생각하는 관점으로 만드는 것이 어려웠습니다.
Q. 구현하면서 가장 놀랐던 점은?
- Node 삭제해도 다시 생김
- Mesh VPN과 함께 쓸 때 테스트할 때는 잘 끊겼는데, Teleport Node 기반 SSH쓰니 안끊긴 점 테스트 잘못 진행한 나의 잘못
Q. 어떤 기업에게 추천하나요?
이 플랫폼은 모든 회사에 필요한 솔루션은 아닙니다. 개인 프로젝트나 소규모 팀이라면 VPN과 SSH만으로도 충분할 수 있습니다. 하지만 아래와 같은 환경이라면 충분히 검토해볼 가치가 있다고 생각합니다.
- 여러 고객사의 서버나 장비를 원격으로 운영하는 기업
- 개발자의 원격접속 이력을 관리해야 하는 기업
- MFA, Session Recording, Audit이 필요한 환경
- 승인 기반의 일시적인 원격접속이 필요한 조직
- 운영자와 개발자의 역할이 명확하게 분리된 조직
- Zero Trust 기반의 원격접속을 고려하는 기업
반대로 이런 환경이라면 조금 과할 수도 있습니다.
- 개발자가 2~3명 정도인 소규모 조직 - 헉 나잖아?
- 사내망에서만 개발하는 환경 (외부 출장 및 재택이 없는..)
- 접속 이력이나 감사 요구사항이 거의 없는 조직
- 단순 VPN만으로도 충분한 환경
Q. 이번 프로젝트를 통해 얻은 가장 큰 배움은 무엇인가요?
쉽게 할 수 있다고 하지 말 것.
Share article