Provisioning policies

The reusable template that decides what a device becomes when it first connects.

A provisioning policy is the answer to “what should happen when a device I have never seen before connects and claims to belong to me?” It decides whether the device is accepted at all, what it is called, what configuration it starts with, and what it is allowed to do.

It is the most important object in fleet onboarding, because it is the only place where a device’s initial state is defined once and applied to every device that follows. Get it right and adding the four-thousandth device is the same amount of work as the second.

What a policy controls

Area What the policy decides
Acceptance Whether devices are admitted automatically or wait for a human.
Identity Which service account devices authenticate as, and which role they are granted.
Naming The name and display name each new device receives.
Configuration The starting spec: network, SSH, encryption, health checks, log forwarding, labels.
Matching Which hardware fields are used to recognize a device you already know about.

Acceptance mode

The mode decides what happens at the moment a device presents itself.

Mode Behavior
Unattended The device record is created automatically, with no human involvement.
Manual approval The device raises an approval request and waits. Nothing is created until someone approves it.
Unspecified Devices do nothing. A policy in this state onboards no-one.

Unattended is what makes zero-touch provisioning zero-touch: hardware arrives at a site, is powered on, and joins. It also means anything holding valid credentials for the policy joins, so the credential is the security boundary.

Manual approval is the right choice while you are still establishing trust in a process, or where devices are installed by third parties. The cost is that someone must be watching the queue — devices sit unprovisioned until they are approved, and a forgotten queue looks exactly like a broken deployment to the person on site.

Identity and access

Each policy is associated with a service account, and a device must hold a key for that account to provision itself. This is the credential baked into the install image or delivered during a registration session.

When a device is provisioned it gets its own service account, bound to a role the policy specifies. Left unset, this defaults to the standard device agent role, which is what a normal SPEKTRA Edge OS device needs.

Grant a narrower role if your devices genuinely need less. This is the single most valuable hardening step available in a policy, because a device is a physical object in a place you do not fully control: whatever role you grant here is what an attacker holding the hardware can use.

Policies can also attach conditions to that role binding — an IP condition restricting where the credential works, for instance — which is worth considering when devices sit at known sites.

Naming

Rather than naming devices by hand, a policy provides name templates so that identity is derived from the hardware itself. A device’s name is fixed permanently at creation, so this matters: a name derived from the serial number stays meaningful, while a sequential counter tells you nothing when you are looking at an alert at three in the morning.

The display name is separate and can be changed later. Put the human-friendly, possibly-changing description there — site, position, purpose — and keep the name derived from something immutable.

The device template

The policy carries a template for the device spec, and this is what turns a blank machine into a configured one. Anything you can set on a device you can set here:

  • network configuration, including netplan and multi-WAN behavior
  • SSH access — authorized keys, allow and deny lists, whether password login is permitted at all
  • disk encryption
  • USB device control
  • health checks
  • log forwarding level
  • labels, which is how the device becomes targetable by application deployments and alerting policies
  • NTP servers

Set labels in the template deliberately. Labels are how you later target application deployments, group alerts, segment queries, and stage OS rollouts — and adding them at provisioning time is far less work than labeling a fleet retrospectively.

Matching known hardware

A policy can specify which hardware identity fields — serial number, for example — should be used to match a connecting device against device records that already exist.

This is what makes pre-registration and hardware replacement work. If you have already created a record for a serial number you expect to receive, the device attaches to that record instead of creating a second one, arriving with the configuration and labels you set in advance.

Without matching configured, a device that is wiped and reinstalled may appear as a new device rather than the one you already know, leaving you with duplicate records for one physical machine.

How many policies

One policy per class of device is the shape that tends to work — where a class is a group that should start life configured the same way.

Reasonable reasons to split: different hardware types, different network environments, different security postures, different sites with different SSH keys. A poor reason is a group you merely want to manage together, which is what labels are for.

Since the template applies only at creation, a policy is also effectively a record of “how devices onboarded in this period were configured”. Creating a new policy rather than heavily editing an existing one keeps that history legible.