Cloud Firewalls

Quake AI concept: Security Groups

• Application model: DigitalOcean firewalls are applied to Droplets via `droplet_ids` and/or tags, whereas OpenStack security groups are typically attached to Neutron ports (VM NICs) and can vary per port ().
• Rule model includes both inbound and outbound rules and notes that if none are configured then no traffic is permitted in that direction; OpenStack security groups also support egress rules but many deployments default to allow-all egress—migrating users may need to explicitly model egress restrictions in DigitalOcean if they rely on different defaults ().
• Aggregation semantics: DigitalOcean states that when multiple cloud firewalls apply to a Droplet, rules are additive (“union of the rules”) and a more permissive rule in any firewall effectively opens access; OpenStack security groups are also generally additive, but users migrating from “deny-by-default with explicit groups” patterns may be surprised by how quickly access broadens when stacking policies ().
• Target/source object types differ: DigitalOcean allows sources/destinations to include load balancers (by UID) and uses constructs like `load_balancer_uids`, `droplet_ids`, `tags`, and CIDRs in rule JSON, whereas OpenStack security group rules typically reference CIDRs and/or remote security group IDs (not load balancer UIDs as a primitive) ().