Azure
Primcoat builds your hardened image, uploads it to Azure Blob Storage, and registers it as an image version in an Azure Compute Gallery.
- Uploads to
- Azure Blob Storage
- Registers as
- a Compute Gallery image version
Azure is the fussiest destination about disk format. It takes a fixed VHD rather than a dynamic one, and the virtual size has to land on a whole number of MiB — a disk a few bytes off is refused at registration, which is after the upload has already happened. Primcoat produces the disk to that shape during the conversion stage, so it is not something you have to know about.
The Azure Linux Agent goes in during the build, so the image behaves like a first-class Azure image — provisioning, extensions, and the portal all work as expected. The Azure Monitor Agent is available from the software catalog if you want it baked in.
Galleries and replication
An Azure Compute Gallery (formerly Shared Image Gallery) separates the image definition — the OS, generation, and publisher/offer/SKU identifiers — from the image versions published under it. Primcoat uploads to Blob Storage and registers a new version under the definition you point it at, so the gallery accumulates a version history rather than overwriting one image in place, and your VM scale sets and templates keep referring to the same definition.
You list the replication regions on the publish target. Azure handles copying the version out to them, which is why a first publish to a wide region list takes longer to become available everywhere than the upload itself does.
Naming the image definition
Gallery image definition names accept letters, digits, and . _ -, up to 80 characters — a narrower set than AWS allows, with no spaces and no /. Primcoat validates the name template against those rules when you save the definition, so the same template that is valid for an AMI does not fail at the end of an Azure publish.
What you configure
A publish target holds the Azure credentials, the target gallery, the image definition inside it, and the replication regions. You define the image name, and add version information and other details as you like.
The recommended credential setup is Entra workload identity federation rather than a client secret — see the platform overview, and security & compliance for the SBOM, signature and compliance report each build produces.
Machine-readable:/integrations/azure.md