Kubernetes clusters should have authorized IP ranges configured
Restrict access to the Kubernetes Service Management API by granting API access only to IP addresses in specific ranges. Limit access to authorized IP ranges so only applications from allowed networks can access the cluster.
The API server is the central way to interact with and manage a cluster. To improve cluster security and minimize attacks, the API server should only be accessible from a limited set of IP address ranges.
What this control checks
AKS clusters must define authorized IP ranges for API server access, unless a private cluster.
Common pitfalls
Check passes when private_cluster_enabled is set
The Checkov check notes "can't be set for private cluster". It passes when private_cluster_enabled is set.
Audit evidence
Evidence that deployed resources meet this control: Azure Policy compliance results for the built-in policy definition "Authorized IP ranges should be defined on Kubernetes Services" (0e246bcf-5f6f-4f87-bc6f-775d4712c7ea); PowerPipe control azure_compliance.control.kubernetes_cluster_authorized_ip_range_defined.
Scans of the Terraform code that flag the same setting before deployment: Checkov check CKV_AZURE_6; Trivy check AZU-0041.
Framework-specific interpretation
NIST SP 800-53 Rev 5: Mapped to AC-4 (Information Flow Enforcement), SC-7 (Boundary Protection) and SC-7(3) (Access Points).
FedRAMP Moderate Baseline Rev 4: Mapped to AC-4 (Information Flow Enforcement), SC-7 (Boundary Protection) and SC-7(3) (Access Points).
Framework mappings
The clauses this control is mapped to in each framework.
- Information Flow Enforcement (AC-4)
- SC-7: Boundary Protection
- SC-7(3) Access Points
FedRAMP Moderate Baseline Rev 4
- AC-4 Information Flow Enforcement
- SC-7: Boundary Protection
- SC-7(3) Access Points
- 3.1.3 Control the flow of CUI in accordance with approved authorizations
- 3.13.1: Monitor, control, and protect communications (i.e., information transmitted or received by organizational systems) at the external boundaries and key internal boundaries of organizational systems.
- 3.13.2 Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems
- 3.13.5 Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks
- 3.13.6: Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
- AC.L2-3.1.3 Control the flow of CUI in accordance with approved authorizations
- SC.L1-3.13.1 Monitor, control, and protect communications (i.e., information transmitted or received by organizational systems) at the external boundaries and key internal boundaries of organizational systems
- SC.L1-3.13.5 Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks
- SC.L2-3.13.2 Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems
- SC.L2-3.13.6 Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception)
- AC-4 Information Flow Enforcement
- SC-7 Boundary Protection
- SC-7(3) Access Points
Related controls
Tool mappings
Use these identifiers to cross-reference this control across tools, reports, and evidence.
- Compliance.tf Control:
kubernetes_cluster_authorized_ip_range_defined - Checkov Check:
CKV_AZURE_6 - Powerpipe Control:
azure_compliance.control.kubernetes_cluster_authorized_ip_range_defined - Azure Policy Definition:
0e246bcf-5f6f-4f87-bc6f-775d4712c7ea - Trivy Check:
AZU-0041
Last reviewed: 2026-10-13