Documentation

Wardpod relies on an agent installed in your clusters, which sends what it observes to your console. The console never connects to your clusters.

Install the agent

1. In the console, open “Clusters and sources”, then “Add a cluster”.
2. Copy the kubectl apply command offered: it contains this cluster's token.
3. Run it with the kubectl context of the cluster to monitor. The agent installs into kube-system.
4. The cluster appears in the console after the first upload, then the agent sends a complete state every 10 minutes.

The agent uses the Trivy Operator if it is installed. Otherwise, it analyses the running images itself, once per digest.

Prerequisites

• The right to create a ClusterRole and a Deployment in the cluster, for installation.
• HTTPS outbound access from the cluster to your console's address. No inbound port is needed.
• A persistent volume for the agent's cache.
• Agent resources: 100 m of CPU and 256 MiB of memory reserved, 2 GiB of memory at most.

Private registries

To analyse private images, declare their credentials in a dedicated Secret in dockerconfigjson format. The agent never reads the cluster's other Secrets.

Data collected

• Running images: registry, repository, digest, base system.
• Packages and versions of each image (SBOM), vulnerabilities found.
• Workloads: name, namespace, exposure (Service, Ingress, routes), container security settings.

Never: image contents, environment variables, Secrets, your applications' logs.

Per-namespace exclusions, set in the console, remove what you do not want to follow.

Security

• Read-only agent: its rights are limited to reading pods, services, controllers, jobs, Ingresses, routes and Trivy Operator reports. It has no rights on the cluster's Secrets.
• Agent container without root, with a read-only file system, no privilege escalation, Pod Security restricted profile.
• Agent tokens stored as hashes; a token only writes to its own cluster, and each organization is isolated from the others.
• Accounts with two-factor authentication (app, security key, email code), which can be required for the whole organization.
• Hosted in France, backups encrypted twice a day, kept in storage locked against deletion.
• Export of all your data and deletion of the organization at any time. See also the data processing agreement and the service status.

Remove the agent

With the cluster's kubectl context, this command deletes everything the installation created:

kubectl delete deployment,configmap,secret,persistentvolumeclaim,serviceaccount,clusterrolebinding,clusterrole,namespace --all-namespaces -l app.kubernetes.io/managed-by=wardpod-server

Then delete the cluster in the console to erase its data.

Plans and billing

• Each paid plan includes a monthly fee and a price per distinct running image, calculated on the average of daily readings: neither replicas nor the number of nodes count. See the pricing.
• Your customer area gives an estimate for the current period, your invoices and your payment method. The console's “Usage” page details the volume by cluster and namespace.
• Cancellation takes effect at the end of the paid period: the organization and its data are then deleted. It can be undone until then from the customer area.
• The plan is changed from the customer area and applies immediately, including images in the current period. Nothing is charged or refunded at that moment: the next invoice adjusts the fee pro rata to the remaining time. Example: moving from €250 to €150 per month halfway through the period gives €50 of credit (€125 unused, minus €75 at the new rate), i.e. a €100 fee on the next invoice instead of €150.
• Moving from the Free plan to a paid plan creates a dedicated console: data from the shared console is not carried over and the agent must be reinstalled.