▲

Octelium - 오픈 소스 Teleport, Cloudflare, Tailscale, Ngrok 대체제

 (github.com/octelium)
11P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • Octelium은 원격 액세스 VPN, ZTNA, API/AI 게이트웨이 등을 통합 지원하는 차세대 오픈 소스 자체 호스팅 플랫폼
  • 자체 호스팅 및 단일 테넌트로 모든 내부·공개 자원에 대한 정체성 기반, 응용계층(레이어 7) 보안 접속 제공
  • 비밀 없는(secret-less) 접근, 세분화 정책 기반 제어, 중앙 관리 및 감사 등 최신 보안 요구 충족 기능 포함
  • 기존 Kubernetes, OpenVPN, Tailscale, Cloudflare Access 등 다양한 상용/오픈 소스 솔루션과 경쟁 우위 제공 및 대체 가능
  • 오픈 소스 모델을 채택하고 상용 기능 지원 및 라이선싱으로 사업 기반을 마련하며, 풀 기능 자체 호스팅 제공에 중점 둠

Octelium 프로젝트 중요성 및 개요

  • Octelium은 Teleport, Cloudflare, Tailscale, Ngrok과 같은 상용 솔루션을 대체할 수 있는 차세대 오픈 소스 통합 Zero Trust 자체 호스팅 보안 접속 플랫폼임.
  • 기존 오픈 소스/상용 솔루션 대비 전체 기능을 손상 없이 자체적으로 호스팅 가능, 추가 비용·벤더 종속에서 자유로운 것이 큰 장점임.

Octelium이란 무엇인가

  • Octelium은 정체성 기반·레이어 7 알고리듬을 적용한 통합 접속 관리 플랫폼
  • 원격 액세스 VPN(OpenVPN Access Server, Twingate, Tailscale 등)의 대안이면서 ZTNA, BeyondCorp(Google BeyondCorp, Cloudflare Access, Teleport 등), ngrok(리버스 프록시), API/AI 게이트웨이, 자가 PaaS 인프라, Kubernetes 인그레스 대체, Homelab 인프라 등 다양한 역할에 대응함
  • 사용자(사람, 워크로드 모두)·조직·애플리케이션 접근을 위해 WireGuard/QUIC 터널 기반의 클라이언트 방식과 BeyondCorp 방식의 클라이언트 없는 브라우저 접근 모두 지원함
  • 정책을 코드로 정의하는 policy-as-code 및 세부 컨텍스트·정체성 기반 보안·비밀 없는 인증 및 권한 부여가 핵심임

주요 사용 사례

  • 현대적 원격 액세스 VPN: WireGuard/QUIC 기반, 동적·정체성 인식·응용 계층 보안
  • 통합 ZTNA/BeyondCorp 접근 구성
  • 자체 호스팅 안전 터널/리버스 프록시(ngrok, Cloudflare Tunnel 대체)
  • 자체 호스팅 PaaS(컨테이너 앱 배포·확장·익명 공개 호스팅)
  • API 게이트웨이(Kong Gateway, Apigee 대체)
  • AI 게이트웨이(LLM 프로바이더 연결·정체성 기반 제어)
  • 통합 비밀 없는 SaaS API 접근
  • MCP/A2A(모델 컨텍스트 및 에이전트 간 표준) 게이트웨이 인프라 제공
  • Kubernetes 인그레스/로드밸런서 고도화 대체
  • Homelab(개인 자원·IoT·클라우드 등 통합 안전 원격 관리)

주요 특징

현대적 통합 아키텍처

  • 모든 자원(내부/NAT 뒤, 공개)·모든 사용자(사람/워크로드)에 대응하는 정체성 인식, 응용 계층 단위 제어
  • VPN 기반 원격 접속과 BeyondCorp 클라이언트 없는 접근 모두 제공
  • Kubernetes 상에 동작, 수평 확장·가용성 자동 내장

동적 비밀 없는(secret-less) 접근

  • HTTP/gRPC API, 웹앱, SSH, Kubernetes, PostgreSQL/MySQL 등 다수 앱/DB에 비밀 키 관리·공유 없이 안전한 접근 지원
  • mTLS 등도 PKI/인증서 공유 없이 접근 가능

컨텍스트 인식·정체성 기반·레이어 7 접근 제어

  • 중앙 모듈형, 컴포저블 정책 시스템(ABAC) 내장
  • CEL, OPA 등 정책 언어 지원, 모든 요청 단위 세밀한 제어 가능

동적 라우팅/구성

  • 정책 기반 동일한 자원에 대해 각기 다른 상위 컨텍스트·계정·조건부 라우팅 가능

지속적 강력 인증

  • OpenID Connect, SAML2.0 등 표준 IdP 연동
  • 워크로드는 OIDC 토큰으로 무비밀 인증
  • NIST 인증수준·MFA·피싱 방지(Passkey, Yubikey 등) 지원

응용 계층 심층 가시성 및 감사

  • OpenTelemetry 통합, 모든 요청 실시간 로그화 및 외부 OTLP 수집기로 전송

서버리스 SSH 및 컨테이너 앱 배포

  • 루트 권한 필요 없이 컨테이너·IoT·비SSH 호스트에도 SSH 접근
  • PaaS와 유사한 컨테이너 앱 배포·확장·보안 접근 지원

중앙집중적 선언적 관리 및 코딩 가능

  • Kubernetes처럼 선언적으로 관리, 단일 명령/코드로 클러스터 상태 재현 가능
  • octeliumctl CLI 및 gRPC API로 DevOps/GitOps 친화적 운영

네트워크 변경 불필요 및 VPN 고질적 문제 해소

  • 업스트림 자원이 Octelium 존재 자체를 알 필요 없으며, 포트 개방 없이 NAT 뒤에서 안전하게 서비스 운영 가능
  • 고유 듀얼스택 프라이빗 IP, 프라이빗 DNS 등 설정 자동화

완전한 오픈 소스, 자체 호스팅·벤더 종속 없음

  • 전체 소스 공개, 상용 버전 기능 제한·Vendor Lock-in 없음
  • 단일 노드 미니 클러스터부터 대형 클라우드까지 확장적 구성 지원

라이선스 및 지원

  • 클라이언트 소스는 Apache 2.0, 클러스터는 AGPLv3
  • 상용 라이선스 및 엔터프라이즈 지원, 외부 기여는 현재 제한됨
  • 공식 문서, Discord, Slack, 이메일, Reddit 등 커뮤니티 지원

자주 묻는 질문 중 주요 항목 요약

  • 현재 Public Beta 단계, 내부 개발 장기 진행 이후 오픈소스 전환함
  • 한 명의 개발자(George Badawi)가 주도, VC나 외부 자본 없이 자체 운영 중임
  • VPN 역할 가능하지만, 근본적으로 정체성 인식 프록시 기반의 ZTA를 지향
  • 실제 "오픈 소스같지 않은" 제약이나 상용 강제 없고 자체 호스팅·풀기능 제공이 설계 목표임
  • 비즈니스 모델은 기술지원, 상용 라이선스, 엔터프라이즈 부가 기능(예: SIEM 연동, Vault 백엔드, EDR) 등에서 파생
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • Octelium이 무엇을 하는지 이해하기 어려운 이들을 위해 가장 명확한 설명을 찾은 곳이 있어 공유함 Octelium 작동 방식 - 공식 문서 링크가 가장 이해가 쉬움 Octelium에 대해 가능한 모든 기능을 나열하여 혼란을 주는 대신, 핵심 개념부터 시작해 점진적으로 설명하는 방식이 매력적임 주요 기능은 고급 프로토콜을 이해하면서 내용 기반으로 세밀한 보안 결정을 내릴 수 있는 VPN 유사 게이트웨이와 Kubernetes 위에 구축된 클러스터 설정 계층임 이 두 가지가 결합되어 "개인용 클라우드"를 만드는 형태임 대형 클라우드 플랫폼처럼 수많은 기능을 제공하지만, 어느 것부터 사용할지 결정이 어려움 개인 홈랩, 클라우드 비용을 절감하려는 소규모 회사, 맞춤형 PaaS 등 다양하게 활용 가능성이 있는 멋진 시스템임

    • TailScale이 만족스럽기는 하지만 경쟁사의 필요성을 느낌 IPO가 예상되고 있는데, 그 단계에 들어서면 경쟁자가 없을 경우 가격이 급격히 오를 가능성이 크다고 봄

    • 프로그래머블 네트워크 터널 패브릭 형태로 요약할 수 있음

  • 개인적으로 보았을 때 몇 가지 문제점과 그로 인해 사용자들이 회의적으로 볼 수밖에 없는 이유를 공유함 개발 이력의 부재, 알 수 없는 대규모 첫 커밋, 공개된 정보 부족, 실재하는 회사로 보이지 않음, 모든 것을 해결할 수 있다고 주장하는 마케팅에 증빙 없는 보안 등 다양한 부분에서 신뢰를 떨어뜨림 이러한 상황에서는 실제 자체 기술인지, 혹은 충분히 신뢰할 수 있는 기존 기술 위에 구축된 것인지 추가 정보가 필요함 사업으로 출시하려면 신뢰성을 확보해야 함 반면 개인 프로젝트라면 비즈니스인 척하는 모습이 오히려 가짜/스캠/주의 신호로 보일 수 있다고 조언함 1인 개발자가 메이저 기업과 경쟁할 제품을 갑자기 내놓는다는 점에 대해 긍정적이기 힘듦 보안성을 명확하게 강조하는 게 중요함 소프트웨어의 목적을 한 문장으로도 설명하기 어렵다면 힘든 싸움이 예고됨 기능을 더 많이 나열하는 것이 해답이 아님 오히려 "난 무조건 깔아줘" 같은 느낌이 들어 시도할 이유가 없어지는 효과를 가져옴 이것이 프로젝트 성공을 방해할 가능성이 높다는 사실을 지적함

    • 훌륭한 피드백임 Octelium이 다양한 기능을 동시에 수행하도록 의도적으로 설계된 점에서 비판의 정당성을 이해함 Octelium은 인간-워크로드, 워크로드-워크로드 사이 여러 케이스에서 사용할 수 있는 통합/범용 제로트러스트 액세스 플랫폼임(문서에 다양한 예시가 상세히 있음) 그래서 신입 사용자 입장에서 혼란스러울 수 있음 첫 커밋이 갑자기 등장한 건, 실제로 2020년 초부터 개발해왔으나 코드 공개를 결정하면서 개인 정보 유출 위험성 때문에 초기 커밋이 없도록 깨끗한 공개 저장소로 시작했기 때문임 지난 5년간 거의 9,000건 수작업 커밋을 했고, 초기에는 단순 원격 접속 WireGuard VPN이었다가 지금의 아키텍처, 기능, 복잡성으로 완전히 바뀌었음

    • 오픈소스 개발자들에게 관대함이 필요함 OP의 배경이나 동기를 아무도 모르고, 재미로 하는 것일 수도 있음 정당화할 필요 없음 이건 오픈소스이자 무료 소프트웨어임 사용자 설명을 한 문장으로 못한다는 비판에 대해, tailscale, cloudflare access, ngrok처럼 비교적 간단하게 설명될 수 있음 이런 제품들이 필요한 게 아니라면 애초에 이 제품도 필요하지 않음

  • Octelium을 최근 살펴봤는데, 설치 시 Kubernetes 클러스터가 필수적인 것처럼 보임 사실이라면 진입장벽이 너무 높음 우리는 오버레이 네트워크에 노드를 붙이고 싶지 k8s 등 다른 인프라 의존성이 추가되는 것은 원하지 않음 내부 서비스 의존성이 최소화 혹은 없어야 한다는 점에서 이러한 선택이 의아함 SDN이 클러스터 위에 필요하면 그게 타겟일 것일 수 있는데, 그뿐인지 궁금함 k8s 통합이 선택이길 바라고, 필수 전제나 유일한 배포 방식이 아니었음 좋겠음 혹시 k8s 없이 Octelium 사용하는 자료가 있다면 알려주길 바람

    • Octelium은 하나 혹은 그 이상의 노드 위에 동작할 수 있는 분산 시스템임 현재는 반드시 Kubernetes 위에서 동작해야 하지만, 내부적으로 k8s에 강하게 엮여 있지는 않아서 예를 들어 Nomad 같은 다른 오케스트레이터로 포팅도 쉬움 k8s를 자체 인프라로 쓰는 것은, 제로트러스트 아키텍처를 관리할 때 발생하는 수작업(프록시 배포, 스케일, 철거 등)을 시스템 관리자가 덜어주기 위함임 Octelium은 control/data plane을 모두 제공해서 octeliumctl apply만 하면 모든 서비스가 자동 배포, 관리, 스케일, 철거까지 됨 파이어월 포트 열기 등 수동 작업이 필요 없음 Kubernetes가 컨테이너를 관리하는 것처럼 Octelium은 동일하게 서비스, 프록시 등을 자동 조율함 노드 개수나 CRI 네트워킹 등 복잡한 관리도 필요 없음 클러스터가 모든 노드를 아우르며 선언형/프로그래밍적으로 관리가 가능함 Octelium을 운영하면서 Kubernetes 깊은 이해는 아예 필요 없고, k8s 자체 클러스터 스케일, TLS 인증서 설정 등 특정 작업을 제외하면 Octelium 자체만 다루면 됨 더 자세한 내용은 공식 문서 참고 추천함

  • 너무 많은 버즈워드를 내뱉는 것에 대해 즉각적으로 큰 불신이 생김 GitHub 페이지를 봐도 제품이 구체적으로 뭘 하는지 이해가 잘 안됨

    • 개선할 수 있도록, 어떤 버즈워드가 문제였는지 목록을 제공해주면 readme에 반영할 수 있어 감사함

  • 전체적으로 Tinc, Hamachi, ZeroTier, Nebula, Tailscale, Netbird 등 이미 유사한 제품이 너무 많음 각각의 장단점이 있지만 실제로는 큰 차별점이 미미하다고 생각함 개인적으로 정말 원하는 기능은 제로트러스트 '라이트하우스'임 Zerotier, Tailscale은 내 계정/네트워크에 노드를 추가하는 권한이 서비스에 있음 내가 원하는 것은 완전한 셀프호스팅과 라이트하우스가 네트워크 일부가 아닌 오로지 노드 감시 역할만 하는 구조임 관련 정보를 더 찾아봐야겠음

    • 문서를 읽어보니 많은 사람들이 Octelium의 진짜 가치를 놓치고 있음 실제로 문서의 내용대로 동작한다면 아직 발견되지 않은 보석이 될 수 있음 엔터프라이즈가 바라는 것은 기존의 경계 기반 보안에서 벗어나 Google überProxy/BeyondCorp가 제시한 (그리고 각종 버즈워드로 희석되어버린) 개념, 즉 생산 시스템, 기업 내부, 외부 인터넷 간 깔끔한 분리와, 사내 직원에게 최대한 투명한 UX, 경계 간 흐르는 트래픽의 권한 명확 관리, 모든 클라이언트의 강력한 신원 인증임 Google 외부는 다양한 프로토콜 환경으로 인해 제약이 큼 프로토콜 인지형 프록시는 기존 coarse-grain 결정 및 로깅만 가능하지만, 타입 추론까지 지원할 때 요청 단위에서 훨씬 정교한 권한 제어가 가능해짐 (모든 요청의 조건이 정책 엔진에 노출되는 것) 문서가 장황하고 마케팅이 매끄럽지 않지만, 이 문제 자체가 너무 복잡해서 어느 누구도 완전하게 풀지 못함 Teleport가 OSS와 상용화에 가장 먼저 나섰고, StrongDM도 흥미로운 시도를 하고 있음 Hashicorp 역시 여기에 더 투자했으면 하는 바람이 있음 (*개인 의견임)

    • Octelium은 위에 언급된 제품들을 대체하는 것도 가능하지만, 지향점과 활용 방식이 더 넓고 명확히 제로트러스트 지향임 단순 VPN/리모트 액세스 툴 그 이상임 꼭 문서를 읽어보고 의도와 아키텍처, 기능을 이해해줬으면 함 요즘엔 모든 제품이 "제로트러스트"라고 광고하지만 실제로 NIST에서 정의하는 진짜 ZTA(즉, L7 인지형 프록시, 정책 결정 지점, 정책 코드 기반의 요청별 세부 액세스 제어, 중앙화된 신원, 외부 SIEM/SSO/Threat intelligence 툴 정보 통합 등)는 소수임 실제로 "진짜" ZTA로 분류되는 상업 제품은 Cloudflare Access, Teleport, Google BeyondCorp, StrongDM, Zscaler 등이 있음 오히려 기업들이 이 용어를 남용해서 "진짜 제로트러스트"의 개념을 희석시켜버리는 경향이 심함

    • sanctum의 cathedral 모드를 참고바람 완전히 셀프호스팅이 가능하며, 노드는 단순히 discovery 역할만 함 터널이 성립하면 대성당 노드는 관여하지 않으며, 예외적으로 black key 분배나 피어가 NAT 뒤에 있을 때만 작동함 reliquary도 있음 직접 운영 중임 sanctum, reliquary

    • 더 많은 관련 프로젝트 목록은 awesome-tunneling에서 확인 가능함

  • "AI" 키워드 삽입은 SEO 목적이라는 것을 이해함 마치 기사 제목에 "Reddit"을 붙이는 것과 같음 내용이 훌륭해도 이런 방식은 좋은 인상을 주지 않음 API 게이트웨이와 AI 게이트웨이 다이어그램도 거의 동일함 tailscale 블로그: AI-normal

    • API와 AI 게이트웨이 간 공통 기능이 많음 예시는 문서에서 직접 확인하는 것이 좋음 AI Gateway 예시, API Gateway 예시 참고 HTTP 요청/바디 수정 프로세스 확장 작업도 진행 중이며, envoy의 ext_proc 지원이 곧 들어가고 proxy-wasm 지원도 수요에 따라 추가할 계획임 HTTP 관련 설명

  • Tailscale 오픈소스 대안을 적극적으로 찾고 있음 하지만 README가 너무 장황해서, 프로젝트 개요 및 문서 링크만 압축 표시했으면 좋겠음

  • Tailscale의 가장 큰 장점은 쉬운 P2P 연결임 Octelium은 그와 달리 중앙집중화된 라우터 구조를 사용하는 것 같은데, 정확한지 궁금함

    • Octelium은 P2P VPN이 아니라 제로트러스트 아키텍처임 물론 WireGuard/QUIC 기반 리모트 액세스 VPN 역할도 가능하지만, 구조적으로 Cloudflare Access, Teleport 쪽에 더 가까움 L7 기반 액세스 제어, 시크릿 없는 액세스(각종 키/토큰/API 키 등 직접 배포 없이 주입), 유동적 설정 및 라우팅, 실시간 OpenTelemetry 기반 가시성 및 감사 등 P2P VPN과 본질적으로 다름 본격적 ZTNA/BeyondCorp 구조(서비스 메시 제외)는 P2P VPN 형태로 구현하기엔 근본적 한계가 있음 요청별 액세스 제어/가시성 확보를 위해서는 반드시 L7 인지형 프록시가 필요함

    • 참고로 Tailscale도 패킷이 중앙집중 라우터를 통하는 경우가 있음 Tailscale의 connection types 설명

  • k3s 클러스터 설치가 앱에 내장되는 이유를 이해하지 못하겠음 기존 인프라에 쉽게 추가할 수 있는 형태/간단한 CRD로 서비스 노출이 더 명확할 것 같음 오픈소스 Cloudflare Access/Teleport 같은 컨셉 자체는 멋진데, 대부분이 결국 k8s 위 커스텀이어서 액세스 중심 기능에 집중했다면 더 관심이 갔을 것 같음

    • Octelium 클러스터는 k8s 위에 작동하는 분산 시스템임 단일 Node의 k8s/k3s 위에서도, 다수 노드의 "프로덕션용" k8s에도 설치 가능 Octelium은 단순한 k8s 래퍼가 아니라, k8s를 인프라로 삼고 자체 플랫폼을 구성함 각 노드는 Octelium Service를 위한 게이트웨이/호스트 역할을 하며, 각 Service는 ID-aware 프록시로 k8s service로 배포됨, 각 프록시는 WireGuard/QUIC 터널의 endpoint이며, 스케일에 따라 안정적인 사설 dual-stack IP를 가짐 identity-aware proxy를 컨테이너처럼 관리하는 구조임 관리자가 직접 각 프록시를 런칭/제거해야 하는 기존 ZTA(예: Teleport, Pomerium 등)와 다름 Octelium은 octeliumctl apply나 gRPC API를 통해 선언형으로 리소스를 생성/삭제하면 그 외 관리는 잊어버려도 됨 리소스가 CRD였던 시절도 있었으나, 유저, 세션, 서비스, 네임스페이스(이 중 일부는 k8s 네임스페이스와 별개), 정책, 디바이스, 자격증명 등 리소스가 너무 많고, 데이터량이 커서 등d backend가 불안정함 결국 별도 Postgres 백엔드를 도입함

  • 이미 출시된 비슷한 프로젝트가 너무 많음

  • 대기업 수준의 액세스 관리(코포 보트넷) 대체재인지 궁금함 만약 내가 대기업이라면 안정성을 위해 대기업 소프트웨어와 지원 패키지를 원할텐데 오픈소스 프로젝트가 1인 개발자 문제를 해결해줄 수 있을지 잘 모르겠음

    • Octelium은 단순히 소규모부터 엔터프라이즈까지 다양한 환경에서 범용적이고, dev/스타트업/엔터프라이즈 등 모든 레벨에 쓸 수 있는 보안 액세스 플랫폼임 예를 들어 Kubernetes도 단일 컨테이너 웹사이트, 소수 마이크로서비스용 API gateway, 수백/수천 노드 대규모 서비스 메시 등 다양한 세팅 모두 지원하듯 Octelium도 활용 범주가 매우 넓음
답변달기