유니ックス 도메인 소켓 대신 포트 기반 프록시를 사용하는 단점은 없나요?

제품 지원 자체 호스팅
1

SELinux가 활성화된 CentOS 파생 배포판 AlmaLinux 9 위에 외부 nginx를 구성하여 Discourse를 배포하는 것을 테스트하고 있습니다.

Ubuntu 기반 컨테이너는 SELinux에 대해 인지하지 못하므로, 컨테이너를 시작할 때마다 유닉스 도메인 소켓을 보안 라벨이 없는 새 파일로 계속 대체합니다. 그 결과, nginx가 해당 파일에 접근할 수 있는 보안 컨텍스트를 부여하기 위해 restorecon으로 파일을 복구하기 전까지는 nginx가 소켓과 통신할 수 없습니다. 당연히 이는 프로덕션 환경에서 작동하는 해결책이 아닙니다.

실제로 외부 세계에 노출된 유일한 서비스인 이 서비스에서 SELinux의 이점을 실제로 활용하고 싶기 때문에, semanage permissive -a httpd_t를 실행하고 싶지 않습니다. :smiling_face:

유닉스 도메인 소켓 대신 네트워크 포트로 프록시를 설정하면 작동합니다:

  • setsebool -P httpd_can_network_connect 1
  • templates/web.socketed.template.yml을 사용하지 않습니다.
  • expose: - "8008:80"
  • 외부 nginx에서 proxy_pass http://127.0.0.1:8008

이 방식에는 특별한 단점이 있을까요? 이 구성에서 연결 제한과 같은 매개변수를 변경해야 하는가요?

더 철저한 테스트를 마친 후, 이를 문서로 더 자세히 작성할 예정입니다. 추가적인 우려 사항이 있다면 문서에 포함하겠습니다.

2

선호하는 방법으로 포트 8008에 대한 직접 연결을 차단하는 한, 아무 문제가 없습니다.

3

감사합니다!

public (active)
  target: default
...
  services: dhcpv6-client http https ssh
  ports: 
  protocols: 
  forward: yes
  masquerade: yes
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:
4

레이턴시 차이가 있습니다. 소켓은 로컬 루프백 포트보다 약 3배 빠릅니다.

그러나 가장 좋은 경우에도 그 차이는 4~5마이크로초에 불과합니다.

5

이 문제에 대해 더 자세히 살펴본 결과, 기본 Connection: close 헤더를 비활성화하기 위해 proxy_set_header "Connection" "";를 추가하는 것이 분명히 필요합니다.