Hi all, I'd like to propose changing the default egress policy for the built-in Isolated guest network offerings f*rom "deny" to "allow", *made configurable via a new global setting. A working PR is up for reference: https://github.com/apache/cloudstack/pull/13684
*Background / current behaviour* An Isolated network created from the shipped default offering (DefaultIsolatedNetworkOfferingWithSourceNatService, and DefaultIsolatedNetworkOffering) currently blocks all egress by default. This comes from how these offerings are seeded in ConfigurationServerImpl: they are built with a NetworkOfferingVO constructor that does not set egressdefaultpolicy, so it falls back to the Java primitive default (false = deny). The DB column default is also false. Meanwhile: - createNetworkOffering, when called without an explicit egressdefaultpolicy, already defaults to ALLOW (NetworkOfferingBaseCmd#getEgressDefaultPolicy returns true when null). - *VPC tiers*, governed by NetworkACL, *use the default "allow*" ACL and permit egress out of the box. *So we ship two inconsistent defaults *(built-in offering = deny, API-created offering = allow), and the flagship "simple Isolated network" experience is the more surprising of the two. Motivation *(frustration mainly, of course, with zero actual security reasons to block egress traffic)* Deny-by-default egress on a NAT'd Isolated network provides very little real security value: the network already has no inbound reachability without explicit port-forwarding/static-NAT/LB + firewall rules. The egress default mostly serves as a first-boot foot-gun: freshly deployed VMs cannot reach package mirrors, NTP, metadata services, etc. until the operator discovers they must add an allow-all egress rule. It's one of the most common "why is my new network broken" support questions, and it differs from what VPC tiers do. *Proposal* 1. Add a global setting network.isolated.default.egress.policy.allow (Boolean, default = true). 2. Seed the two built-in default Isolated network offerings with an egress default policy taken from that setting (allow by default). 3. Use the same setting as the fallback when createNetworkOffering is called without an explicit egressdefaultpolicy, so the built-in and API paths agree. Operators who prefer deny-by-default set the flag to false before first initialization (or simply create/keep a custom offering with egressdefaultpolicy = deny — that path is unchanged). *Backward compatibility* This is deliberately scoped to be safe: - Existing deployments are untouched. The default offerings are seeded once, at first initialization; upgrades do not re-seed them. No data migration runs against existing network_offerings rows or existing networks, so every already-created offering and network keeps its current policy. - Only brand-new deployments (and offerings explicitly created without the parameter) get allow-by-default. - The egressdefaultpolicy parameter and the per-offering behaviour are unchanged; this only changes a default. The one genuine consideration is security posture: anyone standing up a *new* cloud who relied on the historical deny-by-default of the built-in offering would now get allow-by-default. That's exactly why it's a documented, release-noted, operator-overridable setting rather than a silent flip. I'd propose calling it out prominently in the release notes and upgrade docs. Note I am intentionally NOT changing the egress_default_policy DB column default, nor adding an UPDATE against existing rows — the application always sets the value explicitly on insert, and touching existing rows would break the compatibility guarantee above. *Questions for the list* - Any objection to allow-by-default being the shipped default (vs. keeping deny and only adding the knob)? - Preferred scope for the setting — Global (as drafted) or Zone? - Anything in Marvin / integration suites that asserts the current deny-by-default that we should update alongside this? - The PR (5 files, ~25 lines) is linked above for concreteness — happy to hold it until there's rough consensus on direction. Thanks, Andrija
