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