UA backend(s) unreachable during live filesystem builds

[Gauthier Jolly]

[context]

VM instances started, from Ubuntu FIPS cloud offers, need to boot with FIPS modules. This is why CPC needs to pre-install FIPS components (kernel + crypto libraries) on FIPS cloud images.

To do so, the CPC team is manually adding FIPS PPAs, installing and holding back packages, etc... By doing so, we are trying to mock what UA client is usually doing on running machines (with "ua enable fips"). Since FIPS installation process is sometimes updated, keeping it up-to-date across different clouds requires maintenance work. Also, because these changes also happen in UA client, the work is duplicated.

To avoid this duplication and also prevent any potential "conflict" between what is done during image build and UA client, the CPC team would like to install FIPS using UA client in the images.

[request]

To do so, UA client running on LP needs to be able to access the following domains:

for staging:
contracts.staging.canonical.com
esm.staging.canonical.com

for production:
contracts.canonical.com
esm.canonical.com

[security considerations]

Since those domains are maintained by Canonical, my security concerns are limited. However, I also have a limited knowledge of LP and of its security considerations in general.

NB: I don't know for sure if this is the only endpoints we need to allow, I will check UA client's logs to confirm.

[Gauthier Jolly (gjolly)]

> NB: I don't know for sure if this is the only endpoints we need to allow, I will check UA client's logs to confirm.

Requests to 'https://contracts.canonical.com' should be allowed as this is required to run "ua attach"

[Colin Watson (cjwatson)]

I've enabled access to esm.ubuntu.com, but there's a problem with contracts{,.staging}.canonical.com: it's on a K8s cluster with other services, and there's no way to differentiate at the firewall rule level, so IS isn't comfortable with me opening up access there as it stands. It'll need to have some kind of proxy put in front of it first.

[Éric St-Jean (esj)]

hi! any updates on this?

[Colin Watson (cjwatson)]

As far as I know, this still needs to be chased up with Commercial Systems to put a proxy in front of the contracts service, so that access to it can be controlled independently from other services in the same cluster.

[Thomas Bechtold (toabctl)]

@colin, I assume you won't work on that anymore, right? :)

[Colin Watson (cjwatson)]

Indeed not.

[John Chittum (jchittum)]

Revive in 20240419 -- emailing with alnvdl , he stated that there was a proxy in front of the contract server. a dig shows 3 IP addresses round-robbining

dig contracts.canonical.com

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> contracts.canonical.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55671
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;contracts.canonical.com. IN A

;; ANSWER SECTION:
contracts.canonical.com. 60 IN A 185.125.190.32
contracts.canonical.com. 60 IN A 185.125.190.31
contracts.canonical.com. 60 IN A 185.125.190.77

;; Query time: 116 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Apr 19 07:27:31 EDT 2024
;; MSG SIZE rcvd: 100

I wasn't in on the conversation with IS around other pieces, but could we re-investigate this? It'd simplify a lot of builds if we could default to using `pro` commands rather than re-creating them in our build scripts.