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 Brand stores fit within our devices infrastructure. The general details we cover below should be useful for anyone using Ubuntu Core.
Brand Store and Snap Store capabilities
Brand 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.
| Brand Store | Snap Store | |
|---|---|---|
| Access | Restricted | Public |
| Snaps published | Only to Brand 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 |
| Refresh control | Yes | Yes |
| Account delegation | Yes | No |
| Proxy snap server support | Yes | No |
| Custom dashboard | Yes | No |
| Custom API access | Yes | No |
| Substores | Yes | No |
Brand accounts
The Brand account grants roles and privileges to the Brand 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:
- Brand 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 Brand Store, its images and devices and are therefore considered brand activities.
While it is technically possible to use different Ubuntu SSO accounts to administer Brand Store actions, a single Brand account simplifies access and security oversight and is the strongly recommended approach.
Assertions
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.
Brand 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.
Device authentication
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 Brand 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.
See Serial vault overview for further Serial vault details, and our IoT guide for more details on using devices with a Brand store.