Dedicated Snap Stores
A dedicated Snap Store (formerly known as a Brand Store) allows vendors running Ubuntu Core and snap-based devices to control exactly what snaps are available and when.
See our IoT guide for a comprehensive overview of how dedicated Snap Stores fit within our devices infrastructure. The general details we cover below should be useful for anyone using Ubuntu Core.
Dedicated Snap Store and Snap Store capabilities
Dedicated Snap Stores have their roles and administration controlled by a Brand account and can inherit selected packages from other snap stores, and host a set of snaps specific to a brand and device models, and be either open to all developers or a specific list.
|Dedicated Snap Store||Snap Store|
|Snaps published||Only to dedicated Store users||Seen globally|
|Content||Curated by owner||Curated by Canonical|
|Hosting||Canonical hosted/managed||Canonical hosted/managed|
|Security||Monitored by Canonical||Monitored by Canonical|
|OTA (over-the-air updates)||Yes||Yes|
|Proxy snap server support||Yes||No|
|Custom API access||Yes||No|
The Brand account grants roles and privileges to the dedicated Snap Store, and is itself derived from a nominated Ubuntu SSO account. It’s strongly recommended that the Ubuntu SSO account is used only for Brand activities and that its use is strictly limited and controlled.
There are several activities that must be done under the authority of this Brand SSO account, including:
- Dedicated Snap Store administration
- Generating keys used to sign assertions, such as the model and serial assertions
- Gadget snap publishing (if you are using a non-Canonical gadget snap)
- Kernel snap publishing (if you are using a non-Canonical kernel snap)
These activities are central to managing a dedicated Snap Store, its images and devices and are therefore considered brand activities.
While it is technically possible to use different Ubuntu SSO accounts to administer dedicated Snap Store actions, a single Brand account simplifies access and security oversight and is the strongly recommended approach.
An assertion is a digitally signed document that either verifies the validity of a process, as attested by the signer, or carries policy information, as formulated by the signer.
Dedicated Snap Stores, Ubuntu Core, Snapcraft, snapd and the Snap Store all use assertions to handle a variety of functions and processes, including authentication, policy setting, identification and validation.
The model assertion, for example, contains the fundamental definition of a snap-based device, including its core base and the snaps it bundles. It is signed by a key from a Brand account, which means it can be authenticated and its integrity relied upon.
See Create a custom image for instructions on how to use a model assertion to create an Ubuntu Core image.
When a device boots for the first time, it obtains a signed serial assertion from a Serial vault. Each device can then be authenticated with the dedicated Snap Store using the model assertion’s model name and an authentication token called a macaroon.
The macaroon is provided by the Canonical Authentication Service, via the Store API, and requires that a device has the following:
Model support in the Serial vault
This includes the snap account-id of the Brand account, a model name (which must be used in the model assertion mentioned previously), and a key generated by the Brand SSO account. Setting up the Serial Vault configuration currently requires communicating with Canonical.
Gadget snap with prepare-device hook pointing at Serial vault
The system needs a gadget snap that has a prepare-device hook script that points the device to the Serial Vault. The hook script sets a few snapd variables, including the Serial vault URL and device’s serial number.