How-to guide

Restrict ingress to known source IPs

When you know exactly which network a producer comes from — a partner's static egress, a government API's published range — you can refuse everything else at the door. Queuey's per-queue source-IP allowlist is a network gate evaluated before authentication.

Configure the allowlist

On the queue's ingress settings, add CIDR ranges or bare IPs (a bare address is treated as a /32 or /128). IPv4 and IPv6 are both supported:

ipAllowlistCidrs
[
  "203.0.113.0/24",
  "198.51.100.7",
  "2001:db8::/32"
]
  • Unset follows the workspace. A queue with no list of its own uses its workspace's. With no list on either, the queue accepts any source IP — the gate only bites once ranges are listed.
  • A list set on a queue replaces the workspace's — it does not union with it. An empty list counts: a queue with every range removed accepts any source IP, even when its workspace has a list.
  • To put a queue back on its workspace's list, use Reset to workspace in the queue's ingress settings. That resets the queue's other ingress settings to the workspace's as well.

What a blocked request sees

A request whose client IP is outside every range is refused before any auth or crypto runs:

Response
HTTP/1.1 403 Forbidden
Content-Type: application/json

{ "error": { "code": "ip_not_allowed", "message": "…" } }
Matches the real client IP — not a spoofable header
The allowlist matches the connection's real client IP (RemoteIpAddress). Queuey deliberately does not trust a client-supplied X-Forwarded-For header, so a forged header cannot move the matched IP or bypass the allowlist.

Related