LaserData Cloud
Networking

Access Rules

IP-based access control for deployment endpoints across all cloud providers

Access rules control which IP addresses and CIDR ranges can reach your deployment endpoints. Every deployment starts fully isolated by default - no traffic is allowed until you explicitly create an access rule. This includes LaserData itself - our control plane orchestrates infrastructure but has no network access to your deployment endpoints or data.

You are in full control of who can reach your deployment. Nothing is open until you say so.

Exception: Free tier Managed deployments are created with a default global access rule (0.0.0.0/0) that opens all Iggy protocols and the Console, so you can connect immediately. You can delete or replace this rule at any time.

Available on all deployment models (Managed, BYOC, On-Premise) and all plans.

Why Access Rules

When you provision a deployment, it has zero network access configured - no IP, no port, no protocol is reachable by anyone. Clients cannot connect to any endpoint until you explicitly allow traffic. Access rules let you:

  • Restrict access to known office or VPN IP ranges
  • Open specific protocols (e.g. TCP for applications, HTTP for monitoring) independently
  • Grant temporary access with automatic expiry - useful for contractors or debugging sessions
  • Keep the Console UI accessible only from trusted networks

Concepts

Protocol Rules

Each access rule specifies which protocols to open for the allowed CIDR blocks. You can enable any combination:

ProtocolAPI FieldWhat It Opens
Iggy HTTPiggy_httpIggy HTTP API endpoint (ports 80 and 443)
Iggy TCPiggy_tcpIggy TCP transport
Iggy WebSocketiggy_websocketIggy WebSocket transport
Iggy UDPiggy_udpIggy QUIC/UDP transport

The Stream UI is served over the same HTTP ports as the Iggy HTTP API - enabling iggy_http also grants access to the built-in Console.

There is no "allow all" default - you must explicitly select which protocols to permit. If no protocols are enabled, no ports are opened even if CIDR blocks are defined.

CIDR Blocks

Each rule requires at least one IPv4 CIDR block:

  • Single host: 203.0.113.5/32
  • Subnet: 10.0.0.0/16
  • All IPs: 0.0.0.0/0 (opens the selected protocols to the entire internet)
  • Subnet mask must be between /0 and /32

Rule Expiry

You can set an optional expiration date on any rule. Once expired, the rule is no longer enforced and traffic from those CIDRs is blocked again. This is useful for temporary access - for example, granting a partner access for 30 days without needing to remember to clean it up.

Creating an Access Rule

From the Console

  1. Navigate to your deployment and open the Access Rules tab
  2. Click Add Rule
  3. Enter a name for the rule (must be unique within the deployment)
  4. Add one or more CIDR blocks - your IP ranges
  5. Select the protocols you want to allow (Iggy TCP, HTTP, WebSocket, UDP)
  6. Optionally set an expiration date
  7. Add optional remarks for context
  8. Click Create

LaserData automatically configures the underlying cloud infrastructure (security groups on AWS, firewall rules on GCP) to permit the specified traffic.

Validation

When creating a rule, the platform validates:

  • Name must be unique within the deployment (case-insensitive)
  • CIDR blocks must be valid IPv4 CIDR notation with at least one entry
  • Expiry, if set, must be a future timestamp
  • The deployment must not have reached its plan's access rule limit

Managing Access Rules

From the Access Rules tab you can view all active rules with their CIDR blocks, enabled protocols, expiry status, and creation timestamps. Rules can be deleted individually - this removes both the rule and the corresponding cloud infrastructure configuration.

Plan Limits

ResourceBasicProEnterprise
Access rules per deployment31020

Audit

All access rule operations are recorded in the audit log:

  • Rule created - who created it, which CIDRs and protocols
  • Rule updated - what changed, previous values preserved
  • Rule deleted - who removed it and when

API Reference

For programmatic access via API keys, the following endpoints are available.

Required permission: deployment:access:manage (create, delete) or deployment:access:read (list)

Create a Rule

curl -X POST {supervisor_url}/deployments/{deployment_id}/access_rules \
  -H "ld-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "production-api-access",
    "cidr_blocks": ["10.0.0.0/16", "172.16.0.0/12"],
    "rules": {
      "iggy_tcp": true,
      "iggy_http": true
    },
    "valid_to": "2026-12-31T23:59:59Z",
    "remarks": "Production API servers"
  }'

List Rules

curl {supervisor_url}/deployments/{deployment_id}/access_rules \
  -H "ld-api-key: YOUR_API_KEY"
[
  {
    "id": 1,
    "name": "production-api-access",
    "remarks": "Production API servers",
    "rules": {
      "iggy_http": true,
      "iggy_tcp": true,
      "iggy_websocket": false,
      "iggy_udp": false
    },
    "cidr_blocks": ["10.0.0.0/16", "172.16.0.0/12"],
    "valid_to": "2026-12-31T23:59:59Z",
    "created_at": "2025-01-15T10:30:00Z"
  }
]

Delete a Rule

curl -X DELETE {supervisor_url}/deployments/{deployment_id}/access_rules/{rule_id} \
  -H "ld-api-key: YOUR_API_KEY"

On this page