SNAPPY_STORE_NO_CDN configuration via core snap for locked-down environments

[Dmitrii Shcherbakov]

Continuing the theme of limited trust deployments which have fixed white lists of hostnames or IP ranges (https://pad.lv/1737332) there needs to be a way to set SNAPPY_STORE_NO_CDN=1 via core snap before any snap is installed.

Even if we set a proxy server to be the right one, snap download requests will still go to CDNs after snap store instructs snapd to do so. Not every company (especially banks, telcos and other security-cautious company types) will allow TCP 443 rules to an unspecified number of hosts, moreover, with CDNs instances of new package distribution hosts are added and removed dynamically and static IP-based firewalls will cause problems with that. DNS-based firewalling is implemented via periodic resolution which is not accurate (YMMV with TTL and firewall implementation) and not every client network will have that kind of functionality [1][2][3].

SNAPPY_STORE_NO_CDN
https://github.com/snapcore/snapd/blob/2.31.2/store/store.go#L444

 req.Header.Set("X-Ubuntu-No-CDN", strconv.FormatBool(s.noCDN))
https://github.com/snapcore/snapd/blob/2.31.2/store/store.go#L907

Snap store server side seems to react to a special HTTP header X-Ubuntu-No-CDN in which case packages are downloaded from servers that are not third-party CDN servers.

There are currently no controls in core snap for that https://github.com/snapcore/snapd/blob/2.31.2/overlord/configstate/configcore/corecfg.go

What can be used a substitute is the following cloud-init userdata:

juju model-config cloudinit-userdata
write_files:
- content: |
    [Service]
    Environment=SNAPPY_STORE_NO_CDN=1
  owner: "root:root"
  path: /etc/systemd/system/snapd.service.d/cdn.conf
  permissions: '0644'
packages:
  - squashfuse
snap:
  commands:
    "00": systemctl restart snapd

See https://paste.ubuntu.com/p/CGSWSP5MDw/

It would be helpful to make this configurable via core snap (but before it is installed) and also in Juju so that people do not reinvent the wheel all the time (userdata usage is a workaround for the lack of a feature).

[1] https://supportforums.cisco.com/t5/security-documents/using-hostnames-dns-in-access-lists-configuration-steps-caveats/ta-p/3123480

[2] https://wiki.mikrotik.com/wiki/Use_host_names_in_firewall_rules

[3] http://blog.ipspace.net/2016/10/using-dns-names-in-firewall-rulesets.html

[Dmitrii Shcherbakov (dmitriis)]

A model config to be used with juju as a workaround:

juju model-config userdata.yaml

[Arif Ali (arif-ali)]

Hi, we have the same issue at a customer at the moment, and preferably would not use the workaround suggested by Dmitrii. The customer will be deploying the system in this manner for all future builds. It would be good to get some guidelines on when we could get a resolution to this

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.