Support reading PrivateDnsARecord IPv4 addresses from ConfigMap

[Copilot]

What this PR does

Enables PrivateDnsARecord to read IPv4 addresses from ConfigMaps, addressing the operational gap when managing DNS records for Private Endpoints created outside ASO's control (different subscriptions, Terraform, Azure Portal).

Closes #4848

Implementation

• Added $importConfigMapMode: optional to ARecord.Ipv4Address in azure-arm.yaml for API versions 2020-06-01 and 2024-06-01
• Code generation created ipv4AddressFromConfig field alongside existing ipv4Address field
• Webhook validation ensures mutual exclusivity between direct and ConfigMap-sourced values

Usage

apiVersion: v1
kind: ConfigMap
metadata:
  name: private-endpoint-ips
data:
  external-service-ip: "10.10.0.50"
---
apiVersion: network.azure.com/v1api20200601
kind: PrivateDnsZonesARecord
metadata:
  name: external-service
spec:
  aRecords:
  - ipv4AddressFromConfig:
      name: private-endpoint-ips
      key: external-service-ip
  owner:
    name: private-dns-zone
  ttl: 300

Existing ipv4Address field remains functional for backward compatibility. External systems can now update ConfigMaps to trigger DNS record updates without modifying ASO resources.

How does this PR make you feel?

Checklist

• this PR contains documentation
• this PR contains tests
• this PR contains YAML Samples

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Support reading PrivateDnsARecord IPv4 addresses from ConfigMap</issue_title>
<issue_description>## 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
   </issue_description>

<agent_instructions>We will need to update v2/azure-arm.yaml with $importConfigMapMode: optional for this property.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes Support reading PrivateDnsARecord IPv4 addresses from ConfigMap #5025

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.