Access는 Cloudflare의 접근제어 솔루션이다. 접근제어 솔루션이 시장에 한둘이 아니긴 하다. Access는 주로 사용자가 많지 않은 백오피스 시스템에 인증 서비스를 붙일 때 유용하다. 백오피스 앞에 클라우드 플레어가 버티고 서고 플레어가 사용자를 확인한 후 실제 백오피스로 트래픽을 흘려보낸다.
여기까지가 가장 간단한 사용 시나리오이다. 여러 개의 백오피스를 하나의 IDP(Identity Provider)로 묶고 클라우드 플레어를 방벽 삼아 DDOS 등의 공격에 대비한다.
레가시 백오피스에 이렇게 액세스를 붙이면 한가지 성가신 점이 있다. 사용자가 인증을 두 번해야 할지 모른다. 레가시 백오피스가 자체 인증 구조를 가지고 있다면 사용자는 Access에 인증한 후 백오피스에 또다시 인증해야 한다.
이런 구조는 액세스에서 넘겨주는 JWT 토큰을 백오피스가 받아서 인증을 처리하게 하면 쉽게 해결된다.
이 정도면 사용자는 기존 시스템을 이용할 때와 거의 동일한 사용자 경험을 누린다. 단 시스템을 관리하는 입장에서 보면 더 개선할 여지가 있다.
이 구조에서는 클라우드 플레어가 프록시가 되고 클라우드 플레어를 통하는 트래픽은 백오피스 앞단의 로드 밸런서를 통한다.
이때 로드밸런서는 방화벽을 이용해 클라우드 플레어를 통하지 않은 트래픽은 받지 않는다. 그러려면 클라우드 플레어의 IP 주소 대역을 주기적으로 확인하고 방화벽에 이를 적용하는 자동화가 필수적이다. 그리고 방화벽이 있다곤 하나 DDOS 등의 공격이 여전히 가능하다. 그런 까닭에 백오피스용 로드밸런서를 두지 않는 선택을 할 수도 있다. 백오피스와 플레어 사이에 터널을 뚫으면 로드밸런서가 없어도 된다. 이를 구현한 제품이 Argo이다. Argo를 이용하면 로드밸런서를 제거하고 방화벽 관리를 Cloudflare로 일원화할 수 있다.
어쩌면 착한 요금
- 5인까지 무료
- 6인부터 Basic은
(인원 - 5인) x 3 달러 / 월, Premium은(인원 - 5인) x 5 달러 / 월
Kubernetes와 Access
Argo를 Kubernetes 안에서 운영할 때는 크게 두 가지 선택권이 있다. Cloudflare 측에서 현재 권장하는 방법은 Argo tunnel을 제공하는 cloudflared를 백오피스 애플리케이션에 사이드카로 붙이는 것이다. 그런데 이 방법은 애플리케이션 서버를 롤링업데이트할 때 여러 문제를 일으킨다. 사이드카 패턴의 고질적인 문제인데 컨테이너 간의 의존성 문제를 아주 깔끔하게 처리하기 힘들기 때문이다. 배포시 50x 오류를 겪을 가능성이 높다. 이 문제는 차기 K8s에서 어느 정도 해결될 전망이긴 하다.
개인적으론 CF측이 공식 지원을 포기한 cloudflare/cloudflare-ingress-controller: A Kubernetes ingress controller for Cloudflare’s Argo Tunnels 가 더 낫다고 본다. Controller 의 관리 주체만 CF의 크레덴셜을 중앙에서 관리하면 되니 보안 관제 면에서 유리하다. 또한 애플리케이션마다 미묘하게 다른 사이드카 튜닝을 하느라 고생할 필요도 없다. Controller의 개발이 사실상 중지된 탓에 cloudflared의 최신 기능을 이용하려면 직접 코드를 수정해야 하지만 그렇게 어렵지는 않다.
Access를 현명하게 사용한 사례
Access를 꼭 백오피스에만 써야 할 이유는 없다. Kubernetes의 비용구조를 분석하는 untab.io 는 사업 초창기에 베타 사용자의 계정을 발급할 때 Access를 현명하게 이용했다. G-Suite 을 IDP로 사용하여 사용자가 베타 서비스에 접속할 수 있게 했다. 액세스는 사용자 수에 비례해 과금하므로 일반적으로 사용자 수가 적은 백오피스에 적합하지만, 베타서비스처럼 사용자 수가 한정적일 때도 유용하다. 특히 사업 초기에는 계정 서비스를 구축하는 시간과 비용조차 아쉬울 수 있으니 액세스 같은 서비스를 적극적으로 활용하면 나쁘지 않다.
