Deploy the Hosted Agent on Kubernetes
To run the Hosted Agent on your cluster instead of a standalone Docker host, deploy it as a Kubernetes Deployment. The console generates Docker install commands (Linux and Windows) — there is no Kubernetes-specific installer — so you adapt the environment values from the downloaded command into a manifest. The agent itself behaves the same either way: it polls the platform outbound and executes scan traffic against your target APIs.
Before you write the manifest: the agent runs no HTTP server
In broker mode — the platform's name for the agent's normal outbound-polling operation, and the mode every customer deployment uses — the agent's HTTP server is fully disabled. Nothing listens on any port inside the container; all platform communication is outbound. The MICRONAUT_ENVIRONMENTS=broker environment variable is what selects this mode; keep it as generated.
Use the agent's status in the console (ACTIVE / UNRESPONSIVE) as the health signal.
Prerequisites
- A Hosted Agent created in the console, with its Docker Linux install command downloaded — see steps 1–2 of Deploy with Docker. You use the command as the source of values, not to run it.
- Outbound HTTPS (TCP 443) from the agent's pods to the APIsec platform. Confirm egress rules and any NetworkPolicies allow it — see Networking.
- Cluster capacity for 1 CPU and 2 GB of memory per replica (
2Giin the manifest). - A way for your nodes to pull the agent image referenced in the install command. If your cluster cannot pull from public registries, mirror the image into your internal registry and reference it there (adding
imagePullSecretsas your registry requires).
Steps
-
Open the downloaded install command and locate the
docker runline. Copy the image reference and the values ofMANAGER_HOST_URL,BROKER_NAME,BROKER_ID,BROKER_TYPE,BROKER_VERSION, andBROKER_TOKEN. Keep the values exactly as generated, includingBROKER_TYPE=DOCKER_LINUX— it is a label the agent reports in its status, and the two Docker values are the only ones the platform recognizes; there is no Kubernetes value. -
Store the token in a Secret rather than in the manifest:
kubectl create secret generic apisec-agent-token \
--from-literal=broker-token='<BROKER_TOKEN value>' -
Apply a Deployment based on the following manifest, substituting your values:
apiVersion: apps/v1
kind: Deployment
metadata:
name: apisec-hosted-agent
spec:
replicas: 1
selector:
matchLabels:
app: apisec-hosted-agent
template:
metadata:
labels:
app: apisec-hosted-agent
spec:
containers:
- name: agent
image: <agent-image-from-install-command>
env:
- name: MICRONAUT_ENVIRONMENTS
value: "broker"
- name: MANAGER_HOST_URL
value: "https://<platform-host>/v1"
- name: BROKER_NAME
value: "<agent-name>"
- name: BROKER_ID
value: "<agent-id>"
- name: BROKER_TYPE
value: "DOCKER_LINUX"
- name: SEND_BACK_ERROR_REPORT
value: "true"
- name: HEARTBEAT_SCHEDULED_INITIAL
value: "0m"
- name: HEARTBEAT_SCHEDULED_FIXED
value: "5s"
- name: BROKER_VERSION
value: "<agent-version>"
- name: BROKER_TOKEN
valueFrom:
secretKeyRef:
name: apisec-agent-token
key: broker-token
resources:
requests:
cpu: "1"
memory: 2Gi
limits:
cpu: "1"
memory: 2Gi
volumeMounts:
- name: agent-tmp
mountPath: /tmp
volumes:
- name: agent-tmp
emptyDir: {}noteThe
emptyDirvolume at/tmpmirrors the volume in the Docker install command; it preserves the agent's restart marker across container restarts within the pod. -
When the platform issues a Restart action, the agent exits and relies on its runtime to bring it back. The pod's default
restartPolicy: Alwayshandles this — don't change it.
Verify
-
Confirm the pod is Running and not crash-looping:
kubectl get pods -l app=apisec-hosted-agentA restart count that climbs steadily indicates a problem. A single restart after a platform-initiated Restart action is expected behavior.
-
In the console, confirm the agent shows ACTIVE. The agent reports in as soon as the container starts.
If the pod runs but the agent never reaches ACTIVE, check outbound reachability to the platform from inside the cluster, then see Troubleshooting.
Scaling
Every replica in the Deployment polls the same instruction queue and shares the scan work — raise spec.replicas to add parallel capacity. Before you do, read Scale with replicas for how replicas appear in the console and what happens to in-flight work when a replica stops.
Related
- Deploy with Docker — the console-generated deployment path and what the install script checks.
- Understanding the Hosted Agent — the outbound-only connection model.
- Configuration reference — every environment variable the agent accepts.
- Networking — egress requirements for the agent's pods.