Closed michaelschmit closed 4 years ago
Thanks for the feedback! We are currently investigating and will update you shortly.
@michaelschmit The NSG rules will be opened based on ports on services with type Load Balancer. Do you see any services or ingress deployed for Grafana and Kiali when they are disabled
Perhaps I just assumed those NSG ports were opened up for the Grafana and Kiali dashboards, maybe Istio needs those ports open. To me, my lack of understanding means there is minimally a documentation gap. I feel there should be a note that states as part of the istio install, these ingress ports will be opened up and what those ports are used for.
@michaelschmit Thanks for details provided. I am assigning this to content author for checking and updating the document as applicable.
@michaelschmit Good catch on the invalid NSG security rules 👍. There are a few things happening here.
From: AKS | Concepts | Azure network security groups
To filter the flow of traffic in virtual networks, Azure uses network security group rules. These rules define the source and destination IP ranges, ports, and protocols that are allowed or denied access to resources. Default rules are created to allow TLS traffic to the Kubernetes API server. As you create services with load balancers, port mappings, or ingress routes, AKS automatically modifies the network security group for traffic to flow appropriately.
So, AKS will automatically update the NSG with the port and ip address of a Kubernetes Service of type LoadBalancer.
If you look at the values.yaml file used to deploy the istio ingress gateway by the istioctl manifest
command, you will notice a bunch of hard-coded ports. These include the ones you reference.
So even though you disable grafana and kiali, and in the case of the AKS docs, we enable them, but do not provide public access, we still find that the NSG contains the ports for these services. The ip address/port combo are not connected to either grafana and/or kialia via the istio ingress gateway, but for correctness should not be in the NSG.
Could you log this as an issue in the Istio project, since my expectation would be that if I have a value of grafana.ingress.enabled=false
in the grafana values.yaml, that the grafana port is not added to the gateways.istio-ingressgateway.ports
list, and subsequently is not added to the NSG by AKS.
@paulbouwer Thanks for providing the details.
Another option is to patch the istio.aks.yaml
contents in the AKS Istio Install docs.
So add gateways.istio-ingressgateway.ports
under the spec.values
section:
apiVersion: install.istio.io/v1alpha2
kind: IstioControlPlane
spec:
# Use the default profile as the base
# More details at: https://istio.io/docs/setup/additional-setup/config-profiles/
profile: default
values:
gateways:
istio-ingressgateway:
ports:
- port: 15020
targetPort: 15020
name: status-port
- port: 80
targetPort: 80
name: http2
- port: 443
name: https
# This is the port where sni routing happens
- port: 15443
targetPort: 15443
name: tls
I still believe that the Istio install should not render the grafana port if grafana.ingress.enabled=false
is set. The above gives you flexibility in what ports you want exposed via the ingress gateway.
Thanks for the response Paul.
When deploying istio into AKS with grafana and kiali disabled, I am still seeing the NSG being updated to allow the traffic which seems wrong to me. I know grafana and kiali are disabled properly via the config because the deployment doesn't exist in AKS under the istio-system namespace. If I enable grafana and kiali I see the those deployments. With that said, if this for some reason is intended then a note in this documentation might be helpful (also a note that the AKS NSG would be updated in the first place as part of the install would be nice). If this is not intentional, then perhaps someone can bubble this quickly to the group responsible, whether that is at MS or at Istio.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.