Describe the current behavior

When managing Private DNS records for Private Endpoints that are created outside of ASO's control (e.g., in different subscriptions, via Terraform, or through Azure Portal), the PrivateDnsARecord resource requires the IPv4 address to be statically defined in the spec:

apiVersion: network.azure.com/v1api20200601
kind: PrivateDnsARecord
metadata:
  name: external-service
spec:
  owner:
    name: private-dns-zone
  ipv4Address: "10.10.0.50"  # Must be hardcoded
  ttl: 300

This creates operational challenges when:

• Private Endpoints are managed by external teams/systems
• IP addresses change due to endpoint recreation
• Managing multi-environment deployments where IPs differ
• Implementing GitOps workflows where environment-specific values shouldn't be hardcoded

Describe the improvement

Add support for PrivateDnsARecord to read the IPv4 address from a ConfigMap or Secret, enabling dynamic DNS record management for externally-managed Private Endpoints.

Proposed API:

apiVersion: network.azure.com/v1api20200601
kind: PrivateDnsARecord
metadata:
  name: external-service
  namespace: infrastructure
spec:
  owner:
    name: private-dns-zone
  
  # Option 1: Read IP from ConfigMap
  ipv4AddressFrom:
    configMapRef:
      name: private-endpoint-ips
      key: external-service-ip
  
  # Option 2: Read IP from Secret (for sensitive environments)
  # ipv4AddressFrom:
  #   secretRef:
  #     name: private-endpoint-ips
  #     key: external-service-ip
  
  ttl: 300

ConfigMap example:

apiVersion: v1
kind: ConfigMap
metadata:
  name: private-endpoint-ips
  namespace: infrastructure
data:
  external-service-ip: "10.10.0.50"
  database-endpoint-ip: "10.10.0.51"

Use Cases

• Cross-subscription Private Endpoints: Private Endpoints managed in a central networking subscription, but DNS records managed via ASO in application subscriptions
• Terraform/ASO hybrid environments: Infrastructure team manages Private Endpoints via Terraform, application teams manage DNS via ASO
• External IP discovery: Automation extracts Private Endpoint IPs from Azure and updates ConfigMap, triggering DNS record updates
• GitOps-friendly deployments: Environment-specific IPs stored in ConfigMaps, while DNS record manifests remain environment-agnostic

Benefits

• Kubernetes-native: Follows established Kubernetes patterns for configuration injection
• Separation of concerns: Decouples IP address discovery/management from DNS record lifecycle
• GitOps compatible: DNS record manifests can be identical across environments
• Automation-friendly: External systems can update ConfigMaps without modifying ASO resources
• Consistent with ASO patterns: Similar to how other ASO resources reference Kubernetes objects

Alternative Considered

Using ipv4AddressReference to point to ASO-managed PrivateEndpoint resources would be ideal, but this doesn't work when:

• Private Endpoints are in different subscriptions
• Private Endpoints are managed by tools other than ASO
• You need to reference non-Azure IP addresses (e.g., on-premises resources exposed via Private Link Service)

Related Issues

Related to #4326 (reading Private Endpoint IPs from status) - this extends that concept to external sources
Aligns with Kubernetes ConfigMap/Secret reference patterns used throughout ASO

Current Workaround

Manual process required on every IP change:

1. Query Azure for the IP
2. Update the PrivateDnsARecord YAML
3. kubectl apply
   Not suitable for automation or dynamic environments