Aikido Broker for Internal Applications
Use the Aikido Broker to scan and monitor applications that live on internal networks and are not reachable from the internet.
The broker runs inside your infrastructure and forwards Aikido’s requests to the internal URLs you allow.
When to use the Broker
Use the broker with any Aikido scan on applications or services that only exists inside your company network, including:
Code scanning on on-prem GitLab or other local code platforms
Container scanning on private or on-prem container registries
AI pentesting on internal applications
Front-end and API testing scans on internal domains or services
Requirements
To run the Aikido Broker you need:
Docker and Docker compose installed
Optionally Kubernetes 1.19+
Network access to the applications you want Aikido to scan
Outbound HTTPS access to
*.aikidobroker.comWebSocket (wss) support for reliable connection
corporate proxy/firewall must preserve
Connection: UpgradeandUpgrade: websocketheaders
Enough CPU (1 core) and memory (1 GB) to run a small container
Installation
Generate and set a broker client token
Go to Broker Clients page and create a new broker client secret. Save the Client Secret for next step.
If you're unable to access this page, reach out to support in the Aikido dashboard
Add resources (internal URL's)
Define which internal URLs Aikido is allowed to access through the broker.
These are the applications and APIs you want Aikido to scan, for example:
https://api.internal.corp.local
http://service-a.internal:8080
https://10.0.5.20
You can manage these resources in the Aikido UI by selecting an existing broker from the list or by creating a new one.
After you save the resources, a unique Broker URL is generated for each resource. Use this Broker URL in place of the original URL within Aikido.
Start the broker
Bring up the broker service on a machine with access to the internal applications you want Aikido to access. Make sure to replace the CLIENT_SECRET value with the one generated on clients page.
You can check if the Broker is running expected with docker logs aikido-broker
On Windows and Mac OS: Use host.docker.internal instead of localhost or 127.0.0.1 to connect to local services.
Aikido provides a Helm chart to deploy the Broker within a Kubernetes environment.
Set additional parameters by using a values.yaml file and running the command with helm install broker-client aikido/broker-client -f values.yaml
You can check if the Broker is running with kubectl logs -n aikido -l app.kubernetes.io/name=broker-client
Configuration
You can control how the broker reaches your internal services and how it resolves hostnames.
ALLOWED_INTERNAL_SUBNETS
List of CIDR ranges that the broker is allowed to call.
Use this to:
Limit the broker to specific internal networks
Prevent accidental access to unrelated infrastructure
Example:
DNS_SERVERS
Optional list of DNS servers the broker should use to resolve internal hostnames.
Use this if:
You have internal DNS zones (for example *.corp.local)
Your internal services are not resolvable with public DNS
Example:
NODE_EXTRA_CA_CERTS for Custom CA (internal TLS)
If your internal services use certificates signed by a private CA, provide that CA so the broker can validate TLS correctly.
Typical use cases:
Internal services with self-signed certificates
Internal PKI for service-to-service encryption
How you configure this depends on your deployment, but at a high level you will:
Mount your custom CA file into the broker container
Point the broker to that CA file using the provided environment variable or config option
When you add custom certificates the broker must be able to read them inside the container. Mount the certificate folder into the container with an extra -v flag and point the broker to the certificate file with the NODE_EXTRA_CA_CERTS variable. Here is a short example:
Proxy
If your internal network requires a proxy to reach certain hosts or the internet, configure the broker to use that proxy.
This is useful when:
Outbound traffic in your network must go through an HTTP or HTTPS proxy
Internal segments are only reachable via a central proxy
Configure the proxy URL through the broker’s proxy setting or environment variables: HTTP_PROXY, HTTPS_PROXY, ALL_PROXY
You can also configure the client so that requests to certain hosts do not go via the proxy by setting the NO_PROXY environment variable (-e NO_PROXY=noproxy.dev,my-domain.internal). It's value should be a comma separated list of hosts to bypass the proxy.
NODE_TLS_REJECT_UNAUTHORIZED
When the broker keeps running into issues due to self signed TLS certificates, you can tell the broker to disable TLS verification, by passing the 'NODE_TLS_REJECT_UNAUTHORIZED' environment variable with value 0:
How to use Broker resources with Aikido
After you install the broker and add your internal URLs as resources, the broker generates a unique Aikido URL for each resource. These URLs act as secure entry points for Aikido to reach your internal services through the broker.
Use these Aikido Broker URLs in all Aikido scans.
This is important because:
Aikido cannot reach your internal network directly
The broker maps the Aikido URL to your internal service
Using the internal URL directly will not work
Example
When configuring a Domains and API scan (front-end scan), use the Broker URL instead of the internal address.
For example:
Do not use http://my-internal-app.test:8000
Use the generated broker URL, such as: https://4948_c562ddc641.aikidobroker.com
Troubleshooting
Check logs
Check the Docker logs for warning messages and errors:
Error: Cannot access another client's resources
The cached client id no longer matches the CLIENT_SECRET organization. Delete the config/client_id file and try again.
Last updated
Was this helpful?