Connection Allowlist
You set up a connection allowlist by defining approved IP addresses in your network rules. This network rule blocks any traffic that comes from an unknown source address. Most engineering teams start by adding office IP ranges and cloud subnet blocks. Over time, teams add wide IP blocks so remote workers can log in. Broad rules let too many machines reach your core databases and servers. How a connection allowlist works in practice A connection allowlist works as a basic gatekeeper at the net
Connection Pooling Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a connection allowlist by defining approved IP addresses in your network rules. This network rule blocks any traffic that comes from an unknown source address. Most engineering teams start by adding office IP ranges and cloud subnet blocks. Over time, teams add wide IP blocks so remote workers can log in. Broad rules let too many machines reach your core databases and servers.
How a connection allowlist works in practice
A connection allowlist works as a basic gatekeeper at the network edge. When a client sends a request, the firewall checks the source IP address. If the IP address matches a rule, the firewall opens the port. If the IP address does not match, the firewall drops the packet right away.
Cloud providers and database hosts build these checks into their network groups. You pick a port number and type in a trusted IP range. You can also point the rule at another security group in the same cloud. Then you attach that rule set to your server or database instance.
After the network check passes, the user still must log in with a key. The network rule and the login check work as two separate steps. The first step checks where the traffic comes from on the network. The second step checks who the user or app claims to be.
How teams manage rules across cloud networks
Small teams often edit these IP lists by hand in a cloud console. As a team grows, manual updates take too much time and cause mistakes. An engineer who travels or works from home gets a new IP address often. Each change forces someone to add a new rule and delete the old one.
Many teams routes all staff traffic through a single VPN server instead. Then the allowlist only needs to trust the fixed IP of that VPN. That approach keeps the IP list short and much easier to read. Still, every person on that VPN shares the same level of network trust.
App servers also need rules so they can read and write database rows. Teams group app servers into a shared subnet and allow that whole range. If you add a test server to that subnet, it gets the same reach. Old rules often stay in place long after a server shuts down.
Connection Pooling Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What network rules solve and what they miss
Network allowlists stop outside bots from scanning your open ports all day. They cut down noise in your logs and block basic network attacks. This setup works well to keep random internet traffic away from private data. It gives your team a clear boundary around your cloud servers.
Still, a network check only decides who can open a socket and log in. Once a user logs in from an allowed IP, the network rule stops watching. The firewall does not read the SQL queries or shell commands in flight. A valid user on a trusted network can still run a bad drop command.
Shared roles make this gap worse when many engineers use the same login. The network log shows the VPN address, and the database log shows a shared role. You cannot tell which person ran a query or read sensitive rows. Even with strict IP rules, raw emails, phone numbers, and card numbers return in full.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between an allowlist and a blocklist?
An allowlist blocks all traffic by default and only lets trusted IP addresses through. A blocklist lets everyone in by default and only stops known bad addresses.
Do I still need strong passwords if I use an IP rule?
Yes, because an IP rule only checks the network path, not the person. Anyone on the same office network or VPN can reach that open port.
Why do old IP rules cause security risks over time?
Cloud hosts reuse public IP addresses when teams shut down their old servers. A stranger can claim your old IP address and pass right through your firewall.