인포레터에서 최신 DevOps 트렌드를 격주로 만나보세요!
PROXY 프로토콜로 Teleport 실행
이 가이드는 Teleport Auth 서비스와 Proxy 서비스가 레이어 4(l4) 로드 밸런서 뒤에서 실행되도록 구성하는 방법을 보여줍니다.
이 설정에서 Auth 서비스와 Proxy 서비스는 PROXY 프로토콜에 의존하여 L4 로드 밸런서 뒤에 있을 때 클라이언트의 IP 주소를 검색합니다. 신뢰할 수 있는 클라이언트 IP 정보는 보안 관점에서 중요하며, 감사 로그 및 IP 핀 고정과 같은 기능에 의존합니다. PROXY 프로토콜이 올바르게 구성되지 않으면 이러한 기능이 손상됩니다.
Teleport Enterprise(Cloud) 사용자는 PROXY 프로토콜 설정을 관리할 필요가 없습니다. Teleport에서 관리하는 Auth 서비스와 Proxy 서비스 배포는 PROXY 프로토콜이 구성된 L4 로드 밸런서 뒤에서 실행됩니다.
작동 원리
PROXY 프로토콜은 클라이언트 IP에 대한 정보를 포함하는 TCP 연결에 접두사를 추가합니다. 이는 일반적으로 사용자가 Teleport Auth 서비스 및 Proxy 서비스와 같은 엔드포인트 서비스와 사이에 L4 로드 밸런서를 포함하는 네트워크에서 사용됩니다.
L4 로드 밸런서는 설계상 연결을 전달할 때 원래 클라이언트의 IP 주소와 포트를 유지하지 않으며, PROXY 프로토콜은 TCP 스트림 이전에 클라이언트의 원래 IP 주소와 포트를 추가하여 이 문제를 극복할 수 있도록 합니다.
다음은 PROXYv1 프로토콜 헤더의 예입니다:
PROXY TCP4 127.0.0.1 127.0.0.2 12345 42\r\n
필수 조건
-
자가 호스팅된 Teleport Enterprise 계정. 자가 호스팅된 Teleport Enterprise를 시작하려면 판매팀에 문의하십시오. Teleport Community Edition으로 데모 환경을 설정할 수도 있습니다.
PROXY 프로토콜을 사용하도록 Teleport 클러스터를 구성하기 전에 이 가이드를 완전히 읽고 이해하는 것이 좋습니다.
-
tctl
관리 도구 및tsh
클라이언트 도구 버전 >= 17.0.0-dev.tctl
및tsh
를 다운로드하는 방법에 대한 지침은 설치를 방문하십시오.
1/2단계. Teleport 배포 계획
PROXY 프로토콜 동작의 잘못된 구성은 보안 문제를 초래할 수 있습니다. PROXY 프로토콜은 내장 인증이 없기 때문에 악의적인 공격자가 자신의 IP 주소를 위조하기 위해 위조된 사용자 정의 PROXY 프로토콜 헤더를 보낼 수 있습니다. 이를 방지하기 위해 네트워크 설정에 따라 PROXY 프로토콜 설정을 명시적으로 구성해야 합니다:
-
PROXY 프로토콜을 활성화해야 하는 Auth 서비스 및 Proxy 서비스 인스턴스를 결정합니다. PROXY 프로토콜 동작은 Auth 서비스 및 Proxy 서비스에 대해 별도로 제어됩니다.
Proxy 서비스와 Auth 서비스 인스턴스 간에 PROXY가 활성화된 L4 로드 밸런서가 있는 경우, Auth 서비스에서 PROXY 프로토콜을 활성화해야 합니다. 그렇지 않으면 비활성화할 수 있습니다.
Teleport Proxy 서비스 인스턴스도 서로 다른 PROXY 프로토콜 설정을 가질 수 있습니다. L4 로드 밸런서 뒤에서 Proxy 서비스 인스턴스의 하위 집합을 실행하는 경우 이러한 인스턴스에 대해서만 PROXY 프로토콜을 활성화할 수 있습니다.
-
PROXY 프로토콜 지원이 있는 Auth 서비스 또는 Proxy 서비스 인스턴스는 L4 로드 밸런서를 통해서만 접근할 수 있는지 확인합니다. 이는 공격자가 자신의 IP 주소를 위조하고 직접 연결하여 사용자 정의 PROXY 헤더를 보내는 것을 방지합니다. Teleport는 들어오는 연결에 대해 하나의 PROXY 프로토콜 헤더만 허용하며, 여러 PROXY 행이 포함된 요청은 공격을 방지하기 위해 거부합니다.
-
PROXY 헤더를 보내지 않는 L4 로드 밸런서 뒤에서 Teleport를 실행하지 않는 경우, Auth 서비스와 Proxy 서비스에서 PROXY 프로토콜 지원을 비활성화해야 합니다. PROXY 프로토콜 헤더를 보내지 않는 L4 로드 밸런서 뒤에서 Teleport를 실행하면 Teleport 관점에서 모든 들어오는 연결이 동일한 IP 주소에서 오는 것처럼 보이게 되어 Teleport 감사 로그 및 IP 핀 고정 기능이 손상됩니다.
2/2단계. 정적 Teleport 구성 편집
Teleport 프로세스에서 Auth 서비스와 Proxy 서비스는 각각 클라이언트와의 통신을 위해 PROXY 프로토콜을 지원할 수 있습니다. PROXY 프로토콜을 활성화하거나 비활성화하기 위해 각 서비스는 Teleport 구성 파일의 해당 섹션에서 proxy_protocol
필드를 읽습니다:
proxy_service:
proxy_protocol: on | off
# ...
auth_service:
proxy_protocol: on | off
기본적으로 proxy_protocol
은 명시되지 않습니다. 사용자는 수동으로 proxy_protocol
을 on
또는 off
로 설정할 수 있습니다:
on
: PROXY 프로토콜이 활성화되고 필수입니다. PROXY 프로토콜 헤더가 수신되면 Teleport 서비스는 헤더를 파싱하고 클라이언트의 IP 주소와 포트를 추출합니다. 헤더가 없으면 Teleport 서비스는 오류와 함께 연결을 거부합니다.off
: PROXY 프로토콜이 비활성화되고 금지됩니다. PROXY 프로토콜 헤더가 있는 모든 연결은 자동으로 거부됩니다.
네트워크 설정에 따라 사용자에게 명시적으로 proxy_protocol
설정을 on
또는 off
모드로 설정하는 것이 좋습니다.
proxy_protocol
이 명시되지 않은 경우, 해당 Teleport 서비스는 연결에 PROXY 헤더를 요구하지 않지만, 존재할 경우 헤더를 파싱하고 클라이언트의 소스 IP 주소를 PROXY 헤더의 것으로 교체합니다. 이 주소는 감사 이벤트에 나타납니다. PROXY 헤더가 있는 들어오는 연결은 소스 포트를 0
으로 설정하여 표시되며, 감사 이벤트에서도 확인할 수 있습니다.
구성에서 proxy_protocol
설정이 명시적으로 설정되지 않은 경우 IP 핀ning은 작동하지 않습니다. 소스 포트가 0
으로 표시된 연결은 IP 핀ning 검사 중에 거부됩니다.
기본적인 미지정 값 모드는 운영에 적합하지 않습니다. 오직 테스트 환경에만 적합합니다.