Comment 0 for bug 1757534

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'
snap:
  commands:
    "00": apt-get install squashfuse -y
    "11": 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