HTTP 상승: 컨테이너 환경에서의 원격 측정, 추적 및 테러
HTTP는 어디에나 존재합니다. 귀하의 TV는 HTTP를 사용합니다. 당신의 휴대전화. 태블릿. 당신의 차. 네트워킹 기능이 있는 장치라면 아마도 당신이 모국어를 말하는 것만큼 유창하게 HTTP를 말할 것입니다.
HTTP는 유연한 것입니다. 네트워킹 이웃인 TCP와 IP와 달리, A 지점에서 B 지점으로 전송할 수 있는 정보에는 거의 제한이 없습니다. IP와 TCP는 사용할 수 있는 값을 비트 단위로 정의하는 매우 엄격하고 융통성 없는 표준을 준수해야 하는 반면, HTTP는 전송하는 데이터에 대해 자유방임적인 접근 방식을 취합니다. 텍스트. 이진. JSON-기반의 데이터 형식입니다. XML 형식 암호화됨. 일반 텍스트.
꿀오소리처럼 HTTP는 신경 쓰지 않습니다. 그것은 모든 것을, 그리고 그 이상을 실어 나를 것입니다.
HTTP가 끊임없이 그 유연성을 발휘하는 방법 중 하나는 사용자가 거의 보지 못하는 헤더입니다. 이는 모든 HTTP 요청과 응답에 의해 전달되는 메타데이터입니다. 콘텐츠 유형부터 콘텐츠 길이, 권한 부여 토큰, 사용자가 누구이고 어디에 있었는지 알려주는 빵가루까지 모든 것을 공유합니다. 원하든 원치 않든 말이죠.
이는 컨테이너 공간에서 보았듯이 HTTP 헤더가 클라이언트와 서비스 간에 데이터를 전송하는 메커니즘으로 성장하고 있을 뿐만 아니라 이러한 빠르게 움직이는 환경을 매우 효율적으로 확장할 수 있는 메타데이터를 공유하는 수단으로 성장하고 있기 때문에 중요합니다.
점점 더 주목을 받고 있는 것은 서비스 메시 개념과 함께 운영 정보를 전달하는 사용자 정의 HTTP 헤더를 추가하는 것입니다. 오픈소스 서비스 메시 구현의 선두주자 중 하나인 Buoyant의 이 블로그는 단일 HTTP 요청과 응답 쌍을 구성하는 여러 서비스 간의 매우 복잡한 트랜잭션을 단순화하는 데 도움이 되는 추적 상관관계를 활성화하는 데 필요한 원격 측정 데이터를 공유하기 위해 HTTP 헤더에 의존하는 방식을 보여줍니다.
앞서 언급한 블로그 전체를 읽는 데 관심이 없는 분들을 위해 가장 관련성 있는 부분을 여기에 소개합니다. 강조 표시는 제가 했습니다.
Buoyant에서는 linkerd가 제공하는 모든 추가 추적 데이터를 "마이크로서비스를 위한 마법의 원격 측정 스프링클"이라고 설명하고 싶어하지만 실제로는 추적을 함께 연결하기 위해 소량의 요청 컨텍스트가 필요합니다. 해당 요청 컨텍스트는 linkerd가 요청을 수신할 때 설정되고, HTTP 요청의 경우 linkerd가 요청을 애플리케이션으로 프록시할 때 HTTP 헤더를 통해 전달됩니다. 애플리케이션이 요청 컨텍스트를 보존하려면 모든 아웃바운드 요청에 수정 없이 모든 인바운드 l5d-ctx-* HTTP 헤더를 포함해야 합니다.
참조된 사용자 정의 HTTP 헤더는 이러한 고도로 분산된 시스템에서 원격 측정 데이터를 공유하는 데 사용되는 여러 헤더 중 하나에 불과합니다. 블로그에서 언급했듯이 l5d-sample 헤더는 추적 샘플 속도를 조정하는 데 사용할 수 있습니다. 즉, 정보를 공유하는 데에만 사용되는 것이 아니라, 시스템의 운영을 제어 하는 데에도 사용됩니다.
잠시 이 말을 생각해 보세요. HTTP 헤더는 운영 체제의 동작을 제어하는 데 사용됩니다. 이 부분은 여러 문단에서 중요하니 기억하세요.
이 경우 제어 평면과 데이터 평면을 분리하는 것이 아니라 두 평면이 동시에 전송되고, 마치 엔드포인트에서 형태와 기능을 분리하는 것처럼 보입니다. 이 특정 솔루션은 모든 인바운드 및 아웃바운드 요청이 프록시를 통과하는 서비스 메시 개념에 의존하므로 이를 쉽게 달성할 수 있습니다. 프록시는 작동 중인 HTTP 헤더를 필터링하여 요청(또는 응답)을 의도한 수신자에게 전달하기 전에 조치를 취할 수 있습니다. 또한 나중에 추적 내용을 일치시키는 데 도움이 되도록 원격 측정 데이터를 삽입하고 운영 지침을 추가할 수도 있습니다.
컨테이너 환경에서는 애플리케이션 네트워킹 역시 일반화되고 있습니다. (적어도 프로그래밍 가능 프록시 분야에 있는 우리에게는) 항상 존재했던 일이지만, 더 큰 유연성에 대한 필요성이 커지면서 이제는 더 자주 사용되고 있습니다. Ingress 컨트롤러는 근본적으로 IP 주소나 FQDN뿐만 아니라 HTTP 헤더에서 가장 일반적으로 전송되는 애플리케이션별 데이터를 기반으로 라우팅을 가능하게 하는 프로그래밍 가능한 프록시입니다. 버전 관리, 조정, 확장. 이러한 모든 인그레스 컨트롤러의 기능은 HTTP와 HTTP 헤더에 대한 무관심한 태도로 인해 가능해졌습니다.
안타깝게도 HTTP 헤더 자체도 공격 벡터입니다. 그러므로 우리는 운영 데이터를 공유할 뿐만 아니라 운영 동작을 제어하기 위해 HTTP 헤더에 의존하는 것의 결과를 신중하게 고려할 의무가 있습니다. HTTP 헤더는 본질적으로 텍스트 기반인 와일드카드입니다(진지하게, BNF를 읽어보세요). 이로 인해 악성 명령을 실행하도록 조작하는 것이 쉬워질 뿐만 아니라 점점 더 많은 중간 및 엔드포인트 장치와 시스템에서 이 명령을 소비하게 됩니다.
만약 당신이 그것에 겁먹지 않는다면, 당신은 주의를 기울이지 않았다는 뜻입니다.
다행히도, 제어와 데이터 플레인 방법으로 HTTP 헤더를 사용하는 것은 주로 컨테이너화된 시스템에만 국한됩니다. 즉, 이들은 일반적으로 조직이 지나치게 관대한 성격으로 인한 위협을 완화할 수 있는 능력을 제공하는 여러 대중에게 공개되는 통제 지점 뒤에 숨겨져 있음을 의미합니다. 안전한 유입 경로(북쪽에서 남쪽으로)를 결합하는 아키텍처 접근 방식은 악용으로부터 필요한 보호 기능을 제공할 수 있습니다. 아니요, 우리는 그런 시도를 하는 사람을 본 적이 없습니다. 아직. 하지만 우리는 HTTP 헤더로 인해 이미 너무 많은 침해 사고를 보았기 때문에 미리 예방하는 게 후회하는 것보다 낫습니다.
HTTP는 앱, 서비스, 장치의 기본 프로토콜일 뿐만 아니라 원격 측정, 추적, 운영 명령 전송을 위한 프로토콜로 각광받고 있습니다. 흥미로운 시기이지만 운영상의 재앙을 피하려면 "우리는 무엇이든 할 수 있다"는 생각과 "하지만 안전하게 해보자"는 생각을 절충해야 합니다.