andrijapanicsb opened a new pull request, #13684:
URL: https://github.com/apache/cloudstack/pull/13684
### Description
Isolated guest networks created from the built-in default network offerings
(`DefaultIsolatedNetworkOfferingWithSourceNatService` and
`DefaultIsolatedNetworkOffering`) currently **deny all egress by default**.
This
comes from how they are seeded in `ConfigurationServerImpl`: they use 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`
returned `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 Isolated offering = deny,
API-created offering = allow), and the default "simple Isolated network"
experience is the more surprising of the two. Deny-by-default egress on a
NAT'd
Isolated network provides little practical security value — the network has
no
inbound reachability without explicit static-NAT/port-forwarding/LB +
firewall
rules — but it regularly surprises operators whose freshly deployed VMs
cannot
reach package mirrors, NTP, metadata, etc. until an allow-all egress rule is
added.
This PR makes **allow** the default for the built-in Isolated offerings and
makes
the behaviour configurable.
### Changes
- New global setting **`network.isolated.default.egress.policy.allow`**
(Boolean,
default `true`).
- The built-in default Isolated network offerings are seeded with the egress
default policy taken from this setting.
- `createNetworkOffering` without an explicit `egressdefaultpolicy` now
follows
the same setting instead of a hard-coded `true`, so the built-in and API
paths
agree.
Operators who prefer deny-by-default set the setting to `false` before first
initialization, or continue to create/use a custom offering with
`egressdefaultpolicy = deny` (that path is unchanged).
### Backward compatibility
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 **new deployments** (and offerings created without the parameter) get
allow-by-default.
- The `egressdefaultpolicy` parameter and per-offering behaviour are
unchanged;
this only changes a default.
- The `egress_default_policy` DB column default is intentionally **not**
changed
and no `UPDATE` is run against existing rows — the application always sets
the
value explicitly on insert, so the setting is the single control point.
The one real consideration is security posture on **new** clouds: an
operator who
relied on the historical deny-by-default of the built-in offering now gets
allow-by-default. That is why it is an operator-overridable, documented
setting
rather than a silent flip, and should be called out in the release notes.
> A `[DISCUSS]` thread will be raised on dev@ so the community can weigh in
on
> making allow the shipped default vs. keeping deny and only adding the
setting.
### Types of changes
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] New feature (non-breaking change which adds functionality)
- [x] Enhancement (improves an existing feature and functionality)
- [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
- [ ] build/CI
### How Has This Been Tested?
- Modules `api`, `engine/schema`, and `server` compile cleanly with the
change.
- Manual verification of the seeded egress default policy on a fresh
initialization and via `listNetworkOfferings` / `listConfigurations` is
outstanding and will be added; happy to extend Marvin coverage for the new
default if reviewers prefer.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
