Thx Wido, I'll check that it doesn't auto-switch during upgrades and such, and the best way to control it (perhaps via offering setting, or global setting etc... - need to check where the "iptable template" rules for "DENY BY DEFAULT" are stored.
thx, On Mon, Jul 27, 2026 at 12:03 PM Wido den Hollander <[email protected]> wrote: > > > Op 24-07-2026 om 05:55 schreef Andrija Panic: > > 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 > > > > > > I would argue that this is a good change. Similar I see this with > inbound security groups, it still confuses a lot of people who deploy a > VM and can't SSH to it, but that's a different discussion. > > Egress traffic is something which should probably just work. VMs need to > download updates, sync their time, send out a ping somewhere. > > Wido > > > *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 > > > > -- Andrija Panić
