10여 년 전, Cloudflare가 TechCrunch Disrupt에서 출시되었습니다. 당시 우리는 Cloudflare가 전통적인 보안 벤더와 차별화되는 핵심 원칙으로 세 가지를 꼽았는데요. 더 안전하고, 더 성능이 뛰어나고, 말도 안 되게 사용하기 쉽다는 거였죠. 사용하기 쉽다는 점이 우리가 내리는 모든 결정의 중심에 있었고, 이건 Cloudflare Tunnel에 대해서도 마찬가지입니다.
오늘, 이전에는 터미널에서 최대 14개의 명령을 실행해야 했던 터널 생성 작업이 이제는 Zero Trust 대시보드에서 바로 단 세 가지 간단한 단계만으로 가능해진다는 소식을 발표하면서 이렇게 흥분되는 이유도 거기에 있습니다.
이미 관련 내용을 충분히 들었다면 바로 가입 페이지로 가서 VPN 연결은 끊어버리고 Cloudflare와 함께 사설 네트워크 구축을 시작하세요. 이번 릴리즈의 의의와 다음으로는 무엇이 찾아올지 더 자세히 알아보고 싶다면 계속 스크롤하세요.
우리의 커넥터
Cloudflare Tunnel은 여러분의 인프라를 Cloudflare에 연결하는 가장 쉬운 방법입니다. Cloudflare는 로컬 HTTP 서버, Kubernetes 클러스터를 통해 서비스되는 웹 서비스, 사설 네트워크 세그먼트, 그 무엇이든 되어줄 수 있죠. 이 연결을 가능케 하는 것이 바로 가벼운 오픈 소스 커넥터인 cloudflared입니다. 이 커넥터는 Cloudflare 네트워크 내 두 개의 개별 데이터 센터에 대한 장기적인 연결 네 개를 생성해 줌으로써 기본적으로 고가용성을 제공합니다. 즉, 어느 한 연결이나 서버가 다운되거나 데이터 센터가 다운되더라도 여러분의 네트워크는 작동 상태를 그대로 유지한다는 의미입니다. 또한, 사용자들도 커넥터의 여러 인스턴스를 배포함으로써 무슨 이유로든 단일 호스트가 다운되더라도 자체 환경 내에서 리던던시를 유지할 수 있습니다.
역사적으로 커넥터를 배포하는 가장 좋은 방법은 cloudflared CLI를 통하는 방법이었는데요. 오늘, Zero Trust 대시보드에서 직접 터널과 해당 구성을 원격으로 생성, 배포 및 관리할 수 있는 새로운 솔루션의 출시를 발표하게 되어 매우 기쁩니다. 이 새로운 솔루션을 통해 고객은 직원들에게 Zero Trust 네트워크 액세스를 15분 안에 제공할 수 있습니다.
CLI? GUI? 둘 모두는 안 되는 건가
명령줄 인터페이스는 뛰어난 기능을 제공합니다. 이를 통해 사용자는 콘솔이나 터미널에서 명령을 전달하고 운영 체제와 직접 상호 작용할 수 있습니다. 이 정밀도는 사용자에게 바로 이런 정밀도가 필요한 특정 프로그램 또는 서비스와의 상호 작용에 대한 정확한 제어 권한을 부여.
그러나 학습 곡선이 더 높고, 신규 사용자에게는 덜 직관적일 수 있습니다. 즉, 사용하기 전에 해당 도구를 주의 깊게 탐구해 보아야 한다는 의미죠. 하지만 많은 사용자는 이러한 수준의 탐구를 해볼 여유가 없기 때문에 그냥 프로그램을 테스트해 보고는 자신의 문제를 해결하는 데 그다지 적합하지 않다고 생각합니다.
반대로, Zero Trust 대시보드 같은 GUI는 실제 사용해보면서 유연하게 익힐 수 있습니다. 시작하는 데 특별한 프로그램 지식이 필요하지도 않죠. 사용자들은 직관적으로 원하는 결과를 얻어내고, 이 솔루션이 자신의 문제를 해결하기에 적합하다는 것을 이미 알고 있는 상태에서 특정 작업이 어떻게, 어떤 원리로 완료되었는지만 탐구하면 됩니다.
Cloudflare Tunnel을 처음 출시했을 때 시작하는 데 필요한 고유한 명령은 10개도 채 되지 않았습니다. 그리고 이제는 더 한 발 더 나아갔으며, 언급할 만한 새로운 사용 사례도 크게 늘었습니다. 결국, 탐색하기 쉬웠던 CLI 라이브러리가 우리 제품을 막 발견한 사용자에게는 무언가 더 사용하기 번거로운 것이 되었습니다.
단순한 오타도 어떤 사용자에게는 엄청나게 좌절감을 안겨줄 수 있습니다. 예를 들어볼까요? 사설 네트워크 터널에 대한 IP 경로를 알려야 하는 사용자가 있다고 가정해 보겠습니다. cloudflared tunnel route ip add <IP/CIDR> 명령을 외우는 일은 부담이 될 수 있을 텐데요. Zero Trust 대시보드를 이용하면 CLI 라이브러리의 시맨틱은 그냥 잊어버려도 됩니다. 그저 Cloudflare를 통해 연결하려는 터널의 이름과 네트워크 범위만 알고 있으면 되죠. 간단히 my-private-net(또는 뭐든 부르고 싶은 이름)이라고 입력하고, 설치 스크립트를 복사한 다음, 네트워크 범위를 입력하면 됩니다. 정말 간단하죠. 잘못해서 틀린 IP 또는 CIDR 블록을 입력해도 대시보드가 조치 가능하고 사람이 읽을 수 있는 오류를 표시해주기 때문에 바로 수정할 수 있습니다.
CLI를 선호하든 GUI를 선호하든 궁극적으로는 수단만 다를 뿐 동일한 결과를 얻습니다. 각각 저마다의 장점이 있으며, 사용자가 하나의 솔루션에서 두 가지 장점을 모두 누리는 것이 이상적이라고 할 수 있죠.
마찰 지점 제거
터널에는 일반적으로 적절한 목적지로 요청을 라우팅하기 위해서는 로컬로 관리되는 구성 파일이 필요했습니다. 이 구성 파일은 기본적으로 생성되지 않는데도 거의 모든 사용 사례에 필요했죠. 이로 인해 사용자들은 명령줄에서 개발자 설명서의 예제를 이용해 구성 파일을 생성하고 내용을 채워야 했습니다. 하지만 cloudflared에 기능이 추가되면서 구성 파일 관리가 거추장스러워졌습니다. 포함할 매개변수와 값, 그리고 이를 어디에 포함해야 하는지 파악하는 일이 사용자에게는 부담이 되었죠. 이런 문제는 보통 사용자들이 쉽게 알아채기가 어렵고, 문제가 생겼을 때 해결하기도 힘들었습니다.
우리는 최신 릴리즈에서 터널 권한의 개념도 개선하고 싶었습니다. 이전에는 사용자들이 두 개의 고유한 토큰인 cert.pem 및 Tunnel_UUID.json 파일을 관리해야 했습니다. 쉽게 말해, cert.pem은 cloudflared tunnel login 명령 중에 발행되어 CLI를 통해 Cloudflare 계정에 대한 터널을 생성, 삭제 및 나열할 수 있는 권한을 부여했고, Tunnel_UUID.json은 cloudflared tunnel create <NAME> 명령 중에 발행되어 지정된 터널을 실행할 수 있는 권한을 부여했습니다. 하지만 이제 터널을 Zero Trust 대시보드의 Cloudflare 계정에서 바로 생성할 수 있기 때문에 더 이상 터널 생성 전에 오리진을 인증할 필요가 없습니다. 최초 Cloudflare 로그인 이벤트 중에 이미 인증이 이루어지기 때문이죠.
오늘 릴리스에서는 사용자가 더 이상 구성 파일이나 토큰을 로컬에서 관리할 필요가 없습니다. 대신, Cloudflare가 사용자가 Zero Trust 대시보드에 입력한 내용을 기반으로 이를 관리하죠. 사용자가 호스트 이름이나 서비스를 잘못 입력해도 터널을 실행하기 전에 쉽게 알 수 있어 시간과 수고를 줄일 수 있습니다. Cloudflare는 토큰도 대신 관리해주며, 이후 언제든 토큰을 갱신해야 하면 역시 여러분을 대신해 토큰도 교체해줍니다.
클라이언트 또는 클라이언트리스 Zero Trust
우리는 보통 Cloudflare Tunnel을 Zero Trust 플랫폼으로 가는 “진입로”라고 부릅니다. 일단 연결하고 나면 WARP, Gateway 또는 Access와 원활하게 페어링하여 Zero Trust 보안 정책으로 리소스를 보호할 수 있으므로 각 요청이 조직의 장치 및 ID 기반 규칙에 대해 검증됩니다.
클라이언트리스 Zero Trust
사용자는 Cloudflare Tunnel을 Access와 페어링하여 클라이언트리스 Zero Trust 배포를 달성할 수 있습니다. 이 모델에서 사용자는 Zero Trust 대시보드의 흐름을 따르게 됩니다. 먼저 사용자는 터널의 이름을 지정합니다. 다음으로 원본 서버의 운영 체제 및 시스템 아키텍처에 맞게 조정된 단일 설치 스크립트가 제공됩니다. 마지막으로 터널에 대한 공개 호스트 이름 또는 사설 네트워크 경로를 생성합니다. 앞에서 설명한 대로 이 단계에서는 구성 파일이 필요하지 않습니다. 이제 공개 호스트 이름 값이 원격 관리 터널에 대한 수신 규칙을 대체합니다. 여러분의 비공개 리소스에 액세스할 때 사용할 공개 호스트 이름을 추가하기만 하면 됩니다. 그런 다음 호스트 이름 값을 원본 서버 뒤에 있는 서비스에 매핑합니다. 마지막으로 요구 사항을 충족하는 사용자만 이 리소스에 액세스할 수 있도록 Cloudflare Access 정책을 만듭니다.
클라이언트 기반 Zero Trust
또는, Zero Trust에 대한 클라이언트 기반 접근 방식을 선호하는 경우에는 Cloudflare Tunnel을 WARP 및 Gateway와 페어링할 수 있습니다. 여기에서도 위에서 설명한 것과 동일한 흐름을 따르지만 공개 호스트 이름을 만드는 대신 사설 네트워크를 추가합니다. 이 단계는 CLI 라이브러리에서의 cloudflared tunnel route ip add <IP/CIDR> 단계를 대체합니다. 그런 다음, 사용자는 Zero Trust 대시보드의 Cloudflare Gateway 섹션으로 이동해 사설 네트워크 연결을 테스트할 두 가지 규칙을 생성하고, 시작하면 됩니다.
이름: <현재 사용자>를 <IP/CIDR>에 대해 허용정책: <IP/CIDR>의 대상 IP 및 사용자 이메일 <현재 사용자 이메일>동작: 허용
이름: <IP/CIDR>에 대한 기본 거부정책: <IP/CIDR>의 대상 IP동작: 차단
어느 접근 방식에서든 대부분의 사용 사례에는 단일 터널만 필요하다는 점에 유의해야 합니다. 터널은 충돌 없이 공개 호스트 이름과 사설 네트워크를 모두 알릴 수 있습니다. 이는 오케스트레이션을 단순하게 만드는 데 도움이 됩니다. 사실, 가능한 한 최소한의 터널로 시작하고, 터널을 추가하는 것보다는 복제본을 사용하여 리던던시를 처리하는 것이 좋습니다. 물론 이는 각 사용자의 환경에 따라 다르지만 일반적으로 단일 터널에서 시작하여 네트워크나 서비스를 논리적으로 분리해야 하는 경우에만 터널을 추가로 생성하는 것이 현명하죠.
다음 단계
Cloudflare Tunnel을 출시한 이래로 수십만 개의 터널이 생성되었습니다. 우리의 새로운 오케스트레이션 방법으로 마이그레이션해야 할 만큼 많은 터널이죠. 우리는 이 프로세스를 깔끔하게 만들고 싶습니다. 현재 로컬로 관리되는 구성을 Cloudflare가 관리하는 구성으로 원활하게 마이그레이션하기 위한 도구를 개발 중인 이유도 거기에 있죠. 몇 주 후면 이 도구를 사용할 수 있을 것입니다.
출시 시점에는 개발자 설명서에 나열된 글로벌 구성 옵션을 지원하지 않을 것입니다. 이 매개변수들은 케이스별로 지원이 필요하기 때문에 시간이 지나면 점진적으로 이 명령들을 추가할 계획입니다. 특히 이는 cloudflared 로깅 레벨을 조정하는 가장 좋은 방법은 여전히 Cloudflare Tunnel 서비스 시작 명령을 수정하고 --loglevel 플래그를 서비스 실행 명령에 추가하는 것이 될 것이라는 의미이기도 하죠. 마이그레이션 마법사를 릴리즈한 후에는 이 내용을 우선 처리할 예정입니다.
지금까지 말씀드린 것처럼 우리는 원격 터널 관리의 미래에 대한 흥미로운 계획을 추진 중이며, 앞으로도 계속해서 투자를 이어갈 것입니다. 오늘 바로 확인하고, 대시보드에서 간단한 세 단계만으로 첫 번째 Cloudflare Tunnel을 배포해 보시기 바랍니다.