[Bug]: There can be only one AtlasIPAccessList CR per project

[pavansokkenagaraj]

Is there an existing issue for this?

• I have searched the existing issues

AKO Version

2.11.0

Distribution

Kubernetes

Kubernetes Version

v1.32

Current Behavior

When multiple AtlasIPAccessList Custom Resources (CRs) reference the same AtlasProject,
the operator treats each CR as an authoritative list of IP entries.
As a result, whichever CR reconciles last overwrites the access list in Atlas,
removing entries created by other CRs.

For example, if one CR adds static office IPs and another CR adds dynamically discovered NAT EIPs,
the operator deletes one set when the other reconciles.

Custom Resources to reproduce the issue

apiVersion: atlas.mongodb.com/v1
kind: AtlasIPAccessList
metadata:
  name: gamma-prod
  namespace: gamma
spec:
  projectRef:
    name: gamma-prod
    namespace: gamma
  entries:
    - cidrBlock: 192.168.1.0/24
    - ipAddress: 70.53.2.144
      comment: Current user IP address
---
apiVersion: atlas.mongodb.com/v1
kind: AtlasIPAccessList
metadata:
  name: vpc-03e2e8c06c30b67bd
  namespace: gamma
spec:
  projectRef:
    name: gamma-prod
    namespace: gamma
  entries:
    - cidrBlock: 21.233.71.210/32
      comment: NAT EIP for VPC
    - cidrBlock: 21.214.166.170/32
      comment: NAT EIP for VPC
    - cidrBlock: 89.89.220.242/32
      comment: NAT EIP for VPC

Steps To Reproduce

Steps To Reproduce
1. Create an AtlasProject (e.g., gamma-prod).
2. Apply the first AtlasIPAccessList with static office IPs.
3. Apply a second AtlasIPAccessList with NAT gateway EIPs, referencing the same project.
4. Observe the operator logs — one CR’s reconciliation deletes the entries from the other.
5. In Atlas UI / CLI, only one CR’s entries appear at any time.

Logs

Code of Conduct

• I agree to follow this project's Code of Conduct

[pavansokkenagaraj]

[roothorp]

Hey @pavansokkenagaraj, thanks for the issue! We believe that AKO is operating as expected here - it is only expected to handle a single IP Access List per project. I will raise an issue with the docs team to make sure that this is clear in the documentation; I apologise for the confusion.

Thanks!

[pavansokkenagaraj]

@roothorp
Why does the operator remove IP access list entries that were added manually via the Atlas UI?
Requiring the full IP access list to be managed exclusively through the operator feels too restrictive — it would be better if entries added outside AKO weren’t automatically deleted.

Can you consider adding a validating webhook to prevent multiple AtlasIPAccessList CRs from referencing the same project. This would block duplicates early and avoid silent overwrites between CRs. A simple uniqueness check on spec.projectRef with a clear validation error should be enough.

[igor-karpukhin]

Hi @pavansokkenagaraj. This is works as it should for now. The entity assigned to a project is a List rather than Lists. The AtlasIPAccessList treats IPAccessList field for the Project as the sole owner. In the current Atlas API design, list entries do not have IDs on them, so the operator can not tell which one to keep and which one to remove by doing a 3-way merge. I'd recommend you to have only one AtlasIPAccessList resource to be attached to one AtlasProject resource (by reference or ID).