XEIZE
/Vulnerability documentation/IaC/Terraform/Azure/Redis firewall access range needs review

Redis firewall access range needs review

Determine whether Redis needs public connectivity and restrict firewall access to approved clients’ actual source addresses.

Description

When an Azure Cache for Redis instance uses a public endpoint, a firewall range wider than its clients require can allow unnecessary external connection attempts. The start_ip and end_ip values bound the permitted range. Review every address between them and the access granted by other rules, not just the endpoints.

Allowing a narrowly defined public address for an approved client is different from allowing the entire internet. Entering private IP strings does not configure a private endpoint or virtual-network connection. Authentication and data permissions are still required alongside network restrictions.

Potential impact

  • An unnecessarily broad public range increases the set of clients that can attempt to connect to the cache.
  • If credentials are leaked or permissions are excessive, that access can enable data reads, changes, or resource consumption.

Remediation

  • If the public endpoint is needed, identify clients' actual source addresses after NAT or other network translation and allow only the required addresses. Review the combined access granted by all firewall rules.
  • If only private connectivity is needed, configure and test private endpoints, DNS, and client paths on a supported tier before setting public_network_access_enabled to false.
  • Review the Terraform plan and connection impact before applying changes. Afterwards, test required client connections and rejection of unwanted sources, and check authentication, data permissions, and TLS.

Examples

These partial examples use the AzureRM v4.50.0 non_ssl_port_enabled syntax. Define the omitted resource group and random_id.server, and replace the documentation address 203.0.113.10 with an approved client’s actual public source address. These examples do not configure private connectivity.

Before

hcl
resource "azurerm_redis_cache" "example" {
  name                = "redis${random_id.server.hex}"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  capacity            = 1
  family              = "P"
  sku_name            = "Premium"
  non_ssl_port_enabled = false
}

resource "azurerm_redis_firewall_rule" "public_rule" {
  name                = "someIPrange"
  redis_cache_name    = azurerm_redis_cache.example.name
  resource_group_name = azurerm_resource_group.example.name
  start_ip            = "1.2.3.4"
  end_ip              = "2.3.4.5"
}

After

hcl
resource "azurerm_redis_cache" "example" {
  name                = "redis${random_id.server.hex}"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  capacity            = 1
  family              = "P"
  sku_name            = "Premium"
  non_ssl_port_enabled = false
}

resource "azurerm_redis_firewall_rule" "public_rule" {
  name                = "someIPrange"
  redis_cache_name    = azurerm_redis_cache.example.name
  resource_group_name = azurerm_resource_group.example.name
  start_ip            = "203.0.113.10"
  end_ip              = "203.0.113.10"
}

Explanation:

  • Before: The firewall allows a broad range from 1.2.3.4 through 2.3.4.5. Review whether those addresses are actually needed.
  • After: The start and end are set to one client address to narrow the range. The resource address public_rule is retained; verify the actual address and connection path for your deployment.

References

XEIZE DocumentationTechnical support