Atlas IP Access List Ownership Conflict
Parent: MongoDB Atlas Infrastructure as Code · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-6c84a071d812
↓ Facts as markdownall context files
Source-anchored research for Atlas IP Access List Ownership Conflict. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- AKO’s default retention of Atlas objects when Kubernetes custom resources are deleted should not be treated as protection against entry removal during reconciliation: the documented default concerns custom-resource deletion, while #2869 demonstrates destructive list reconciliation. (high confidence) (verified as of 2026-10-14) [source]
Problems, failure modes and limitations
- Issue #2343 reproduced provider 1.17.0 failing terraform plan after a UI deletion with ATLAS_NETWORK_PERMISSION_ENTRY_NOT_FOUND. The changelog records the Read() missing-resource fix in provider 1.17.2, released June 20, 2024; this is historical evidence, not proof that current providers cannot recover drift. (high confidence) [source]
Comparisons and alternatives
- The Terraform provider documents a duplicate-creation limitation: declaring an already existing IP, CIDR, or security-group entry can succeed by associating the resource with that existing entry. Combined with Terraform’s one-remote-object/one-resource-address rule, this creates a duplicate-ownership risk rather than a reliable uniqueness guard. (high confidence) (verified as of 2026-10-23) [source]
- Pulumi’s own multi-tool Kubernetes guidance recommends explicit ownership boundaries when tools coexist. Applied to Atlas as a design inference, aggregate office, application, and NAT addresses into one authoritative operator list rather than separate competing lists; Pulumi’s article supplies general guidance, not an independent Atlas reproduction. (medium confidence) [source]
Facts and statements
- Atlas project IP access lists govern client access across all clusters in the project; treating the list as an application-local setting can therefore affect other applications sharing that project. (high confidence) [source]
- Atlas Kubernetes Operator documents at most one AtlasIPAccessList resource per project and replacement of an existing list. Issue #2869 reports mutually deleting office and NAT entries with operator 2.11.0; maintainers confirmed that one resource owns the project list. (high confidence) (verified as of 2026-10-14) [source]
- The singular mongodbatlas_project_ip_access_list resource manages one entry, whereas AtlasIPAccessList represents the project list. These ownership boundaries differ; an AKO list must include entries that it should preserve. (high confidence) (verified as of 2026-10-14) [source]
- Recommended ownership pattern, inferred from the documented conflicts: aggregate approved entries into one authoritative AtlasIPAccessList, or delegate entry management to Terraform without an overlapping AKO list writer. Pulumi independently recommends assigning mixed-tool ownership by resource boundary; its guidance is general Kubernetes guidance, not an Atlas-specific experiment. (medium confidence) [source]
- AKO can manage a list for a project managed elsewhere by using externalProjectRef plus a connectionSecret. This separates project ownership from list ownership; it does not provide separate ownership for subsets of list entries. (medium confidence) (verified as of 2026-10-14) [source]
- Changing an entry’s IP address or CIDR forces Terraform to destroy and recreate the entry. Atlas also warns that connections from a removed address can remain open temporarily, so immediate connection survival does not prove the intended access-list entry remains configured. (high confidence) (verified as of 2026-10-23) [source]
- For an ownership handoff to Terraform, import an existing entry using its project ID plus CIDR or IP, and bind that remote object to only one resource address. Import records an existing object in state; it does not resolve a competing operator’s authoritative list configuration. The need to remove that competing ownership follows from the two ownership models. (high confidence) [source]
- Atlas’s Activity Feed records entry creation and deletion; an address edit appears as a deletion plus creation, while comment edits are omitted. These events can help investigate apparent list wipes but do not alone identify the controlling IaC configuration. (low confidence) (verified as of 2026-10-14) [source]
- In the November 2025 discussion of #2869, maintainers described AtlasIPAccessList as the sole owner of the project IPAccessList. Manual UI additions are therefore outside its authoritative specification and can be removed on reconciliation; separate Kubernetes resource names do not partition the project list. (high confidence) [source]
- The Terraform mongodbatlas_project_ip_access_list resource represents one entry, whereas AtlasIPAccessList represents the project list. Inference: Terraform entry management and operator list reconciliation should not independently control overlapping project access-list configuration. (high confidence) [source]
Children
- No children recorded.