Skip to main content

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 (2Gi in 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 imagePullSecrets as your registry requires).

Steps​

  1. Open the downloaded install command and locate the docker run line. Copy the image reference and the values of MANAGER_HOST_URL, BROKER_NAME, BROKER_ID, BROKER_TYPE, BROKER_VERSION, and BROKER_TOKEN. Keep the values exactly as generated, including BROKER_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.

  2. 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>'
  3. 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: {}
    note

    The emptyDir volume at /tmp mirrors the volume in the Docker install command; it preserves the agent's restart marker across container restarts within the pod.

  4. When the platform issues a Restart action, the agent exits and relies on its runtime to bring it back. The pod's default restartPolicy: Always handles this — don't change it.

Verify​

  1. Confirm the pod is Running and not crash-looping:

    kubectl get pods -l app=apisec-hosted-agent

    A restart count that climbs steadily indicates a problem. A single restart after a platform-initiated Restart action is expected behavior.

  2. 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.