WASViking Docs
⌘K
Sentinel agent

Installing the Sentinel agent

Register an agent in the portal, install the signed package, register on the host to fetch certificates, and start the service. mTLS to your tenant, no inbound ports.

The WASViking® Sentinel agent installs from a signed package. The whole flow is driven from your portal: create the agent record to get a one-time token, install the package on the host, register with the token to fetch certificates, and start the service. The mTLS tunnel comes up and the WASViking cloud can then scan your internal targets.

Supported platforms

Platform Package
Ubuntu / Debian .deb
RHEL / Rocky / Alma / Amazon Linux .rpm
Other Linux with systemd tarball
macOS Supported for local evaluation.
Windows Not supported.

Minimum requirements: 1 vCPU, 512 MB RAM, 1 GB disk for cache and ephemeral scan output. Network: outbound HTTPS to your tenant gRPC endpoint (sentinel.wasviking.com, port 443). No inbound ports required.

Step 1 — Register a new agent in the portal

Sign in to portal.wasviking.com. In the left sidebar, under WASVIKING SENTINEL, open Sentinel Agents and click Add Sentinel Agent.

Set the Agent display name: a human-friendly label shown in the portal, for example London - DMZ Scanner 01. It is not the machine hostname, must be unique within your organization, and is renameable later.

Click Create. The portal issues a bootstrap token, displayed once. Copy it and keep it safe. If you lose it, revoke this agent record and create a new one.

Step 2 — Download the package

Click Get Agent at the top of the Sentinel Agents page. The portal serves the right package for the platform you select.

Verify the download before installing. The Verify download (SHA256 & signature) action on the modal gives you the expected checksum and the signature to validate the artifact has not been tampered with.

Step 3 — Install and enable the service

On Ubuntu / Debian:

sudo dpkg -i wasviking-sentinel_<version>_amd64.deb
sudo systemctl enable --now wasviking-sentinel

# Replace <version> with the release version printed in the portal.

The package installs the agent under /opt/wasviking-sentinel/ and registers a systemd unit named wasviking-sentinel. At this point the service is enabled but waits for registration to provide its certificates.

Step 4 — Register and start the agent

Register the agent once with the bootstrap token from Step 1. The agent securely downloads its client certificates and writes its configuration file.

# Step A — Register this agent (replace with your token from the portal)
cd /opt/wasviking-sentinel
./wasviking-sentinel register --token <YOUR_TOKEN_FROM_PORTAL>

# What happens during registration:
# - Client certificates are securely downloaded
# - Configuration is saved to:
#   /opt/wasviking-sentinel/configs/config.yaml

# Step B — Start and verify the service
sudo systemctl start wasviking-sentinel
sudo systemctl status wasviking-sentinel

In CI or scripts, read the token from an environment variable instead of pasting it on the command line:

export WASVIKING_BOOTSTRAP_TOKEN="<paste-from-portal>"
./wasviking-sentinel register --token "$WASVIKING_BOOTSTRAP_TOKEN"

Registration output:

Registering with WASViking API...
Certificates downloaded successfully into /opt/wasviking-sentinel/certs/
Config written to /opt/wasviking-sentinel/configs/config.yaml

The private key never leaves the host. The CA certificate, the client certificate, and the client key are written under /opt/wasviking-sentinel/certs/:

ls -l /opt/wasviking-sentinel/certs
# -rw-r--r--  ca.crt
# -rw-r--r--  client.crt
# -rw-------  client.key

After a successful registration and start, the agent connects to the WASViking cloud automatically and appears as Active in your portal within a few seconds.

The config file

register writes /opt/wasviking-sentinel/configs/config.yaml:

grpc_server: sentinel.wasviking.com
agent_hostname: dmz-scanner-01
agent_id: ""
use_tls: true
tls_ca_cert: certs/ca.crt
tls_cert: certs/client.crt
tls_key: certs/client.key
use_mtls: true
log_path: logs/sentinel_agent.log

agent_id is empty until the first run. The service populates it automatically and persists it back to the file. You do not need to edit this file by hand in the common case.

# After the first run, agent_id is filled in:
agent_id: 56b3bd08aa4d5201edafd434740d9c140c1e477742d47360d71a76842b09ec21  # auto-generated on first run, do not edit

Agent status

In Sentinel Agents, each agent shows one of:

Status Meaning
Active Registered, tunnel connected, heartbeat current.
Pending Registered but has not connected yet.
Offline Was Active, no recent heartbeat.
Revoked Certificate invalidated; tunnel refused.

Counters at the top of the page summarize the fleet: Total · Active · Pending · Offline · Revoked.

If the agent stays Pending

If an agent remains Pending for more than a few minutes, check these common causes:

  • Outbound connectivity on port 443 is allowed.
  • No TLS interception or proxy blocks HTTPS to sentinel.wasviking.com.
  • System clock is synchronized (NTP). Certificate validation fails on a skewed clock.
  • Client and CA certificates are present and valid under /opt/wasviking-sentinel/certs/.

How the portal lists agents

Column Meaning
Name The display name set on creation. Editable in the row actions.
Hostname The host the agent reports.
Address The egress address the WASViking side observes.
Status Active / Pending / Offline / Revoked.
Last Seen Time of the last heartbeat.
Actions Rename, rotate certificate, revoke.

Trigger your first internal scan

With the agent Active, create a target whose URL resolves only inside your network. On the New Scan screen, the agent appears in the routing selector (Execution Mode). Pick it, configure auth if needed, and start the scan. Every analyzer routes its HTTP probes through the tunnel.

See Internal scanning for the full walkthrough.

Certificate rotation and revocation

Both are operator actions in the portal, no host change needed.

  • Rotate. From the agent's row actions, click Rotate certificate. The portal issues a new certificate set; the agent picks it up on the next reconnect. The previous certificate is immediately revoked WASViking-side.
  • Revoke. Click Revoke. The certificate is invalidated immediately; the agent's status flips to Revoked and the tunnel drops. The host record stays in the list for audit.

The client certificate also auto-rotates before expiry as defense-in-depth.

Upgrade

Download the new package from Get Agent, install it over the existing one, and restart the service. The certs/ and configs/config.yaml are preserved across upgrades.

sudo dpkg -i wasviking-sentinel_<new-version>_amd64.deb
sudo systemctl restart wasviking-sentinel

Uninstall

sudo systemctl disable --now wasviking-sentinel
sudo dpkg -r wasviking-sentinel
sudo rm -rf /opt/wasviking-sentinel

In the portal, Revoke the agent record so the certificate's CN is no longer accepted on the WASViking side.

Troubleshooting

Symptom Likely cause
register returns 401 Bootstrap token already consumed or expired. Create a new agent in the portal.
Agent stays Pending See the four common causes above (port 443, TLS interception, NTP, certificates).
Peer certificate verification failed certs/ca.crt is stale. Rotate from the portal and re-run register.
403 from gRPC after some time The agent was revoked in the portal. Create a new one.
Tunnel keeps dropping A proxy enforces an idle timeout. Confirm egress to sentinel.wasviking.com:443 and any HTTP/2-aware proxy in the path.