Open
Description
Description
Currently, Kubernetes Ingress resources on AKS allow the creation of rules without specifying a host. This results in ambiguous "catch-all" routing, where the Ingress controller routes traffic for any hostname matching the path. Such behavior introduces the following challenges:
- Security Risks: Open-ended Ingress definitions can unintentionally expose backend services to unauthorized access.
- Routing Conflicts: Lack of hostname specificity may lead to unpredictable routing behavior across multiple Ingress resources.
- Operational Complexity: Debugging and managing Ingress configurations without clear host rules becomes cumbersome.
To improve security, predictability, and operational efficiency, AKS should provide a built-in policy or recommendation to enforce that all Ingress resources include a host in their rules section.
Examples
Without host (current undesired behavior)
- Problem: This configuration results in a "catch-all" rule that matches requests for any hostname (*) and routes them to the example-service. This is ambiguous and can lead to security and operational issues.
With host (desired behavior)
- Benefit: This configuration explicitly defines the host as example.com, ensuring that the Ingress rule only applies to requests sent to example.com. This enhances security, predictability, and operational clarity.