No AKS tenho um serviço do tipo LoadBalancer com 2 portas definidas, uma para acesso geral (e autenticação bidirecional) e outra para acesso exclusivo de um cluster Service Fabric também no Azure. Para obter acesso exclusivo, alterei a regra de entrada nas VMs para permitir o acesso apenas ao Cluster SF. O problema é que muitas vezes vejo que a regra é redefinida para o padrão, provavelmente devido a uma implantação que modifica o serviço AKS do Azure DevOps (embora o objeto LoadBalancer nunca mude)
A configuração do LoadBalancer é semelhante a esta:
apiVersion: v1
kind: Service
metadata:
name: myservice-loadbalancer
spec:
ports:
- name: public-port
port: 1234
targetPort: public-port
- name: service-fabric-port
port: 4321
targetPort: service-fabric-port
selector:
app: myservice
type: LoadBalancer
Uma possível solução é adicionar o IP permitido ao objeto LoadBalancer, conforme recomendado aqui:https://github.com/Azure/AKS/issues/570#issuecomment-413299212, mas no meu caso isso limitará a "porta pública" também.
Não consigo pensar em uma saída diferente do que criar dois objetos LoadBalancer, um por porta. Mas não é uma solução alternativa limpa, pois: o serviço é o mesmo apenas através de duas portas diferentes, e desta forma eu teria dois IPs para o mesmo serviço. Além disso, conforme mencionado no link acima, as alterações nas regras de entrada devem ser persistentes.
Existe alguma outra solução alternativa? Muito obrigado antecipadamente por qualquer insight.
Responder1
Fiz a mesma pergunta no StackOverflow e respondi lá também:https://stackoverflow.com/a/61696167/6860266
Conforme mencionado na outra resposta, a solução foi adicionar novas regras no Grupo de Segurança de Rede com prioridade maior que a existente.
Por exemplo, o serviço LoadBalancer acima criará uma regra para a porta TCP 4321, permitindo que qualquer fonte de Internet acesse essa porta no IP público fornecido ao serviço. Digamos que a prioridade dada a essa regra seja 500. Posso mudar essa regra, masserá redefinido mais tarde.
Tenho que adicionar mais duas regras com prioridades maiores, digamos 400 e 401. Ambas as regras têm como destino o IP público do serviço e a porta 4321. A regra 400 permitirá acesso à etiqueta de serviço ServiceFabric, enquanto a regra 401 negará acesso a a etiqueta de serviço Internet.
As regras serão avaliadas na ordem 500, 401 e 400, então finalmente apenas o Service Fabric poderá acessar essa porta. As regras 400 e 401 não são criadas pelo Azure, portanto não serão alteradas.