IP Restrictions for Control Plane

The API7 Control Plane (Dashboard and Admin API) is the highest-privilege interface in your deployment. Restricting which IP addresses can reach it reduces the attack surface for stolen-credential, lateral-movement, and brute-force scenarios.

The Dashboard and the Admin API are served by the same Control Plane process and share a single configuration file. The built-in IP allow list configured there applies to both interfaces.

Configure the built-in IP allow list

The Control Plane reads a security.ip_restriction block from its configuration file (dashboard_conf/conf.yaml in the Docker Compose layout, or the equivalent ConfigMap in Helm). Add the trusted networks to allow_list:

dashboard_conf/conf.yaml

security:
  ip_restriction:
    allow_list:
      - 192.168.1.0/24
      - 10.0.0.5/32
    deny_list: []
    message: "Access denied"
    response_code: 403

Behaviour:

• Both IPv4/IPv6 addresses and CIDR ranges are accepted.
• An empty allow_list means allow all; an empty deny_list means deny none. Set allow_list to a non-empty list to lock the Control Plane down.
• Requests from a non-allowed IP receive HTTP 403 with {"error_msg":"Access denied"} before any authentication runs. This applies to both the Dashboard UI and the Admin API on the same listener (default port 7443).
• message and response_code customise the rejection response.

Apply changes by restarting the Control Plane container or pod.

caution

Before enabling allow_list, make sure to include the IPs of every operator workstation, CI/CD runner, and monitoring system that needs Control Plane access. Misconfiguring the list can lock you out of the Dashboard and Admin API; recovery requires shell access to the Control Plane host to revert the file.

What this does NOT cover

The ip-restriction plugin (configured via the Admin API as a plugin or global rule) executes on the data plane and only affects proxied client traffic to your published services. It does not gate Admin API requests on the Control Plane and is not a substitute for the configuration above.

Defence in depth

The Control Plane's built-in allow list should be one of several layers:

• Network firewall or security group: Restrict inbound traffic to the Control Plane's Admin API/Dashboard port (default 7443) at the platform level — AWS security groups, Kubernetes NetworkPolicy, or a hardware firewall.
• Reverse proxy in front of the Control Plane: Terminate Control Plane traffic on an NGINX, HAProxy, or cloud load balancer that enforces an IP allow list independently from the Control Plane's own list.
• Admin API key authentication: Every Admin API request must carry a valid X-API-KEY header. Rotate keys regularly and scope them per user or service account.
• SSO for the Dashboard: Layer SSO on top so that being on a permitted network is necessary but not sufficient for access.
• mTLS between Control Plane and Data Plane: See Mutual TLS between CP and DP so that even an attacker on the Admin API port cannot impersonate a data plane node.

Best Practices

1. Default-deny at the network layer: Allow only known operator subnets, CI/CD runners, and bastion hosts to reach the Control Plane ports.
2. Audit changes: Pair IP restrictions with Audit Logs so unauthorized configuration changes are detectable even if an allowed network is compromised.
3. Test before locking down: Stage allow_list changes in a non-production environment first, and keep an out-of-band recovery path (host shell access) available.

Next Steps

• Review Audit Logs to detect failed login attempts from restricted IPs.
• Configure SSO for centralized user authentication.