<!-- llms-explorer concept facts · https://llms-explorer.com/tree/cedar-forbid-only-policy-patterns-for-atlas/ · pack 2026-10-23 · ~1597 tokens -->

# Cedar forbid-only policy patterns for Atlas

> Source-anchored research for Cedar forbid-only policy patterns for Atlas. Run status: COMPLETED.

Parent: [Atlas Resource Policies Cedar](https://llms-explorer.com/tree/atlas-resource-policies-cedar/) · 6 facets · 19 facts · page: https://llms-explorer.com/tree/cedar-forbid-only-policy-patterns-for-atlas/

## Structure and components

- Atlas accepts forbid rules, rejects permit, and leaves principal universal; its resource-policy layer is allow-by-default within existing role permissions. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/atlas-resource-policies.md)
- The project.ipAccessList.modify action with when { context.project.ipAccessList.contains(ip("0.0.0.0/0")) } blocks wildcard access-list additions; the practitioner walkthrough reports the attempted addition was rejected. (high confidence) — [source](https://www.mongodb.com/docs/atlas/atlas-resource-policies.md)

## How it works

- An unless exception disables only that forbid's match. It does not override another satisfied forbid, because Cedar gives forbids precedence over permits. (high confidence) — [source](https://docs.cedarpolicy.com/auth/authorization.html)

## How-to and procedures

- Use forbid with when to deny a bad state, or unless to require an approved state. The practitioner AWS-only example uses cluster.modify and equality with the singleton cloudProviders set. (high confidence) — [source](https://www.mongodb.com/docs/atlas/atlas-resource-policies.md)
- Use forbid ... when to reject an undesirable state, or forbid ... unless to reject states outside an approved configuration. Keep principal universal and constrain the relevant Atlas action. (high confidence) — [source](https://www.mongodb.com/docs/atlas/atlas-resource-policies.md)

## Problems, failure modes and limitations

- Cedar skips policies that error and reports diagnostics. The upstream schemaless reproduction misuses in for string membership; contains fixes the type error. This is a generic Cedar risk, not evidence of an Atlas bypass. (high confidence) — [source](https://docs.cedarpolicy.com/auth/authorization.html)

## Comparisons and alternatives

- A wildcard IP guardrail targets project.ipAccessList.modify and tests context.project.ipAccessList.contains(ip("0.0.0.0/0")); it constrains access-list configuration, rather than testing the administrator's source address. (high confidence) — [source](https://www.mongodb.com/docs/atlas/atlas-resource-policies.md)
- Use set.contains(value) for string membership rather than stringValue in [strings]. Cedar issue #2428 demonstrates that the latter errors and can neutralize forbids when a surviving permit allows the request; it is not evidence of an Atlas bypass. (medium confidence) — [source](https://github.com/cedar-policy/cedar/issues/2428)

## Facts and statements

- Standard Cedar authorization requires a satisfied permit and no satisfied forbid. Therefore Atlas's allow-by-default integration must not be confused with evaluating a standalone forbid-only policy set using Cedar's default algorithm. (high confidence) — [source](https://www.mongodb.com/docs/atlas/atlas-resource-policies.md)
- For region allowlists, use approvedRegions.containsAll(context.cluster.regions) inside unless; containsAny alone does not establish that every deployment region is approved. (medium confidence) — [source](https://www.mongodb.com/docs/atlas/atlas-resource-policies.md)
- A project exception belongs inside the relevant forbid rule, for example unless { resource in ResourcePolicy::Project::"<PROJECT-ID>" }; it does not grant an exception to other forbids. (high confidence) — [source](https://www.mongodb.com/docs/atlas/atlas-resource-policies.md)
- Resource-policy deployment does not automatically repair existing violations; inventory them through nonCompliantResources and plan remediation. The practitioner observed an existing wildcard access-list entry remain after policy creation. (high confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/atlas-resource-policies.md)
- Minimum-shard rules need a conversion exception such as && !context.cluster.isConvertingToSharded; General-class tier rules should guard optional attributes with has and do not cover Low CPU or NVMe SSD classes. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/atlas/atlas-resource-policies.md)
- Pulumi ResourcePolicy accepts an organization identifier and a list of policy bodies; this provides an infrastructure-as-code representation of Atlas guardrails. (low confidence) (verified as of 2026-10-18) — [source](https://www.pulumi.com/registry/packages/mongodbatlas/api-docs/resourcepolicy)
- The AWS/MongoDB engineering account describes validation before enforcement and reports that policy violations identify the failing policy; validate configuration cases before rollout. (low confidence) — [source](https://aws.amazon.com/blogs/opensource/decoupling-authorization-at-scale-mongodb-atlas-and-cedar-based-resource-policies/)
- Guard optional cluster attributes with has before comparing tier or disk limits. MongoDB's documented General-class tier example excludes Low CPU and NVMe SSD classes. (low confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/atlas/atlas-resource-policies.md)
- Cedar skips policies that produce evaluation errors, including forbid policies, and returns diagnostics. Applications can choose stricter handling; this does not establish Atlas's treatment of runtime diagnostics. (high confidence) — [source](https://docs.cedarpolicy.com/auth/authorization.html)
- Test allowed and prohibited configurations before rollout. The independent Foojay walkthrough reports blocked GCP cluster creation under an AWS-only policy and blocked wildcard IP additions; these observations support enforcement of those examples, not universal policy coverage. (medium confidence) — [source](https://foojay.io/today/enforcing-governance-in-mongodb-atlas-with-resource-policies/)
- Policies do not automatically repair existing resources. Monitor /orgs/{ORG-ID}/nonCompliantResources; pre-existing autoscaling limits can still exceed a newly imposed policy. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/atlas/atlas-resource-policies.md)
