Auto-match Zones to Accounts via spec.managedZones (multi-account support)

[romaws]

Summary

• Introduces automatic matching of Zones and DNSRecords to Accounts using Account.spec.managedZones.
• Replaces the single shared Cloudflare client with per-account clients managed in-memory.
• Makes ownership deterministic in multi-account setups.

Changes

• Added AccountManager to map accounts and zones, resolve conflicts, and provide per-account Cloudflare clients.
• AccountReconciler creates a client from Secret and registers the account + managed zones; cleans up on delete.
• ZoneReconciler/DNSRecordReconciler resolve the account by zone name and use the corresponding client; emit clear errors for no/multiple matches.
• Updated samples: account-sample now includes spec.managedZones.
• Updated README with a heads-up about managedZones requirement.
• Adjusted unit/e2e tests to the new flow.

Breaking

• Every Account must list all managed apex zones in spec.managedZones. Zones/DNSRecords without a matching account will not reconcile.

Migration

• For each Account, add all apex zones to spec.managedZones.
• Reapply CRDs/manifests; Secrets with apiToken are unchanged.

Testing

• Unit tests updated for manager-based resolution.
• E2E uses updated sample with managedZones; ensure CF_API_TOKEN and CF_ZONE_ID are set.

Docs

• README and samples updated. Consider a follow-up docs page “How matching works”.

Checklist

• Meaningful title and description for changelog
• Single logical change
• Documentation updated (README + samples)
• Labels: enhancement, breaking, documentation
• Linked related issues/PRs

[rxbn]

Hey @romaws

Thanks a bunch for your contribution!

Since this is a bigger change, it might take a little while to review.

Appreciate your patience 🙏

Cheers,
Robin

[rxbn]

Hey @romaws,

I just had time to review your PR — thanks again for your patience and contribution!

After an internal discussion, we’d like to propose a change regarding how Account and Zone objects are linked.
In your implementation, the Zone object is linked in the Account object using the deprecated managedZones field. While this is a valid approach, it would make more sense to link the Account object in the Zone object by using a Kubernetes object reference. For example, a Zone object could look like this:

---
apiVersion: cloudflare-operator.io/v1
kind: Zone
metadata:
  name: example-com
spec:
  name: example.com
  accountRef:
    name: account-sample

We’d like to invite you to reconsider your architecture, and we’re grateful for the time you’ve spent on this contribution.

Furthermore, I’d like to suggest removing the “Heads up” section from the README, as this information will be included in the cloudflare-operator documentation. Since your change will introduce a major version bump, an upgrade guide will be necessary anyway.

Best regards,
Robin