Azure中Kubernetes LoadBalancer服务默认安全组规则管控及Nginx Ingress规则调整

Great questions—these are common pain points when working with AKS LoadBalancers and Nginx Ingress. Let's break down solutions for each scenario:

1. Avoiding or controlling default security group rules when creating Kubernetes LoadBalancer services in Azure #

AKS automatically creates a Network Security Group (NSG) for LoadBalancer services by default, but you have full control to override or customize this behavior:

• Use a pre-created custom NSG
  Skip automatic NSG generation entirely by attaching your own pre-configured NSG to the LoadBalancer. First, create an NSG with all the inbound/outbound rules you need, then add this annotation to your LoadBalancer service manifest:

  annotations:
    service.beta.kubernetes.io/azure-load-balancer-nsg: "my-custom-nsg-name"
  

  AKS will use your custom NSG instead of generating a new one, so you manage all rules directly.

• Use LoadBalancer annotations to restrict default rules
  If you still want AKS to handle the NSG but need to tweak rules, use these annotations:

  • service.beta.kubernetes.io/azure-load-balancer-internal: "true": Creates an internal LoadBalancer (no public IP), eliminating public-facing default rules.
  • service.beta.kubernetes.io/azure-load-balancer-disable-outbound-rules: "true": Disables auto-generated outbound rules—you'll need to add your own required outbound rules manually.
  • service.beta.kubernetes.io/azure-load-balancer-health-probe-port: "8080": Specifies a custom health check port, preventing AKS from opening unexpected ports for probes.

• Layer in Kubernetes Network Policies
  Even if your LoadBalancer NSG has broad rules, Network Policies enforce pod-level traffic restrictions. This acts as a second line of defense to block unwanted traffic that might slip through the NSG.

2. Blocking or modifying the 80/443 public NSG rules added by Nginx Ingress Controller #

When deploying the Nginx Ingress Controller with a LoadBalancer service, it automatically adds NSG rules (500/501) opening 80/443 to 0.0.0.0/0 by default. Here's how to stop or adjust this:

• Deploy Ingress Controller with a custom NSG
  Similar to the first scenario, attach a pre-configured NSG to the Ingress Controller's LoadBalancer service. Add this annotation to the Ingress Controller's service manifest (or pass it via Helm parameters):

  annotations:
    service.beta.kubernetes.io/azure-load-balancer-nsg: "my-ingress-nsg"
  

  Your custom NSG can define restricted access to 80/443 (e.g., only your corporate IP range) instead of opening to the entire internet. The Ingress Controller won't modify this NSG automatically.

• Restrict IP ranges during Ingress Controller deployment
  Use Helm to specify allowed source IP ranges directly, which will modify the auto-created NSG rules to target only those ranges instead of 0.0.0.0/0. For example:

  helm install nginx-ingress ingress-nginx/ingress-nginx \
    --set controller.service.loadBalancerSourceRanges={192.168.1.0/24,10.0.0.0/8}
  

  This tells the Ingress Controller to create NSG rules that only allow traffic from the specified IP ranges to 80/443.

• Lock NSG rules with Azure Policy (post-deployment)
  If you've already deployed the Ingress Controller and want to prevent future modifications to the NSG rules, use Azure Policy to enforce a lock on the NSG. Note: This is a last-resort option—ensure your rules are finalized first, as it will block any legitimate updates from the Ingress Controller or AKS.

Content sourced from Stack Exchange, question author: ThatChrisGuy