Alguma desvantagem em fazer proxy via porta em vez de unix domain socket?

Estou testando a implantação do Discourse sobre o AlmaLinux 9 derivado do CentOS com SELinux habilitado e nginx externo configurado.

Como o contêiner baseado em Ubuntu não conhece o SELinux, ele continua substituindo o soquete de domínio unix por um novo arquivo que não é rotulado de segurança toda vez que inicio o contêiner, e o nginx não tem permissão para falar com ele até que eu execute restorecon no arquivo para dar a ele um contexto de segurança que o nginx pode acessar. Obviamente, isso não funciona como uma solução de produção.

Eu realmente não quero executar semanage permissive -a httpd_t porque gostaria de aproveitar o SELinux no único serviço que está realmente aberto para o mundo exterior. :smiling_face:

Funciona se eu fizer proxy para uma porta de rede em vez de um soquete de domínio unix:

  • setsebool -P httpd_can_network_connect 1
  • não use templates/web.socketed.template.yml
  • expose: - "8008:80"
  • No nginx externo, proxy_pass http://127.0.0.1:8008

Existem desvantagens particulares nisso? Devo alterar algum parâmetro como limitação de conexão nesta configuração?

Escreverei isso com mais detalhes como documentação após testes mais completos e, se houver preocupações adicionais, posso incluí-las no que escrever.

2 curtidas

Desde que você bloqueie pessoas de se conectarem diretamente à porta 8008 usando seu método preferido, não há problema.

3 curtidas

Obrigado!

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

Há uma diferença na latência, um socket é cerca de ~3x mais rápido que uma porta de loopback local.

Dito isso, estamos falando de uma diferença de 4-5us aqui, na melhor das hipóteses.

3 curtidas

Depois de investigar mais, definitivamente quero adicionar proxy_set_header \"Connection\" \"\"; para desativar o cabeçalho padrão Connection: close