제13장. 레이어 7 및 FQDN 정책
이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: translation-feedback@oreilly.com
이 장에서는 제12장에서 다룬 네트워크 정책의 기초를 바탕으로 한 여러 고급 사용 사례를 다룹니다. 해당 장을 읽지 않았다면 최소한 규칙 구조와 정책 데이터 경로 작동 방식에 대해 숙지해야 합니다. 여기서는 HTTP, HTTPS, DNS 및 FQDN 정책에 대한 레이어 7 정책에 중점을 둘 것입니다. 이 장의 모든 매니페스트는 책의 GitHub 저장소 내 chapter13 디렉터리에 있습니다.
레이어 7 정책
이전 장인 ' '에서는 순수하게 레이어 3에서 정책을 적용했습니다. toEndpoints, toEntities, toCIDR 출구 규칙 문장과 그에 상응하는 입구 규칙 등 트래픽의 신원을 파악하는 다양한 방법을 사용했지만, 궁극적으로 적용한 모든 정책은 패킷 내 IP 주소와 포트 정보를 기반으로 동작했습니다.
이러한 요소만으로 보호하려는 모든 리소스를 고유하게 식별할 수 있다면 좋겠지만, 종종 더 나아가야 할 필요가 있습니다. 예를 들어, 워크로드가 외부 서비스에 대한 액세스를 읽기 전용으로 제한하고 싶다면 어떻게 해야 할까요? HTTP를 통한 서비스라면, 관련 IP 주소나 식별자 및 TCP 포트 80으로만 아웃바운드 트래픽을 제한할 수 있지만, 이 정책은 GET 요청과 POST 요청 모두에 동일하게 적용됩니다. 마찬가지로, 이러한 정책으로는 /api와 같은 특정 URL 경로만 접근을 제한할 수 없습니다. 서로 다른 클라이언트가 서로 다른 경로를 사용할 것으로 예상되는 HTTP 서버를 보호하려면 어떻게 해야 할까요? 또는 동일한 IP 주소에 여러 가상 서버가 호스팅되고, 해당 서버로의 트래픽이 HTTP Host 헤더나 TLS 서버 이름 표시(SNI) 헤더를 기반으로 필터링 및 라우팅되는 경우에는 어떻게 해야 할까요? 이는 콘텐츠 전송 네트워크(CDN)나 관리형 서비스에 호스팅될 수 있는 외부 서비스에 특히 중요합니다. 이러한 서비스에서는 동일한 IP 주소가 여러 다른 서비스를 제공하는 데 사용될 수 있기 때문입니다.
예를 들어, 포드가 api.weather.example의 API에 접근하도록 허용하려면 해당 사이트에 사용되는 특정 IP 범위를 알고 toCIDR 규칙을 사용하여 해당 범위의 포트 443 또는 포트 80 접근을 허용할 수 있습니다. 하지만 해당 범위가 CDN 소유라면, 파일 호스팅 사이트 filehost.example같은 다른 사이트도 이를 사용할 수 있습니다. 이로 인해 api.weather.example 접근을 허용한 포드들이 filehost.example에도 접근할 수 있게 되는 문제가 발생합니다. 단독으로 보면 문제가 되지 않을 수 있지만, 공격자는 이 취약점을 악용하여 침해된 포드에서 민감한 데이터를 유출하거나 악성코드를 위한 "명령 및 제어" 메커니즘을 구현할 수 있습니다. 이러한 예시는 많은 "가정"과 "가능성"을 포함하여 추상적일 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access