© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
5c6b958
demo site
(Get the code!)
Because we determined that fips doesn't actually take effect until the machine is restarted, I switched up and wrote this config.yaml:
vpc-id: vpc-5aaf123f
cloudinit-userdata: |
preruncmd:
- pro refresh config
- pro attach C14EW5D6fYetRNE
- pro enable usg --assume-yes
- pro enable fips-updates --assume-yes
- if [ -e /var/lib/restarted ]; then echo already restarted; else touch /var/lib/restarted; echo restarting; reboot now; fi
It worked as expected, rebooting one time after installing fips, but otherwise moved forward and did the rest of the juju initialization steps. I bootstrapped with:
$ juju bootstrap aws jam-aws --config config.yaml --bootstrap-series focal --model-default config.yaml --agent-version 3.1.5
Which forced the controller to 3.1.5, but on the controller I could run:
curl -sSf --connect-timeout 20 --noproxy '*' --insecure --tls13-ciphers TLS_CHACHA20_
curl: (35) error:0607B0C8:
35
$ curl -sSf --connect-timeout 20 --noproxy '*' --insecure -o xxx.tgz https:/
0
So I could see that Curl on the controller machine did, indeed, not like CHACHA, but was happy to do other ciphers. Using that same setup (reboot just after installing and enabling fips) I then added a new model
$ juju add-model test
$ juju model-config cloudinit-userdata
preruncmd:
- pro refresh config
- pro attach MYSECRET
- pro enable usg --assume-yes
- pro enable fips-updates --assume-yes
- if [ -e /var/lib/restarted ]; then echo already restarted; else touch /var/lib/restarted; echo restarting; reboot now; fi
$ juju deploy ubuntu-lite --base ubuntu@20.04
I then watched as it got set up. fips enablement is a bit slow (about 5 min to get through all the steps before we get to reboot)
I could see that it did get restarted as the new machine came up, before it downloaded the agent binaries
Installing FIPS Updates packages
FIPS Updates enabled
A reboot is required to complete install.
restarting
+ install -D -m 644 /dev/null /var/lib/
+ echo machine-
(and at that line 'restarting' I was connected in another terminal over ssh, and I got kicked out and had to wait a bit before I could reconnect.)
And post reboot (and finishing initialization) I can confirm that forcing the cipher fails as desired:
$ curl -sSf --connect-timeout 20 --noproxy '*' --insecure --tls13-ciphers TLS_CHACHA20_
35
I then went forward and added an LXD unit of the same application:
$ juju add-unit ubuntu-lite --to lxd:0
$ juju status
...
ubuntu-lite/1 waiting allocating 0/lxd/0 waiting for machine
...
0/lxd/0 pending pending ubuntu@20.04 Retrieving image: rootfs: 84% (20.57MB/s)
$ sudo lxc list
+------
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+------
| juju-c4252b-0-lxd-0 | RUNNING | 252.2.196.168 (eth0) | | CONTAINER | 0 |
+------
And from inside that container:
...
This machine is now attached to 'Ubuntu Pro (Apps-only) - Virtual'
SERVICE ENTITLED STATUS DESCRIPTION
anbox-cloud yes disabled Scalable Android in the cloud
esm-apps yes enabled Expanded Security Maintenance for Applications
esm-infra yes enabled Expanded Security Maintenance for Infrastructure
fips yes disabled NIST-certified core packages
fips-updates yes disabled NIST-certified core packages with priority security updates
ros yes disabled Security Updates for the Robot Operating System
usg yes disabled Security compliance and audit tools
NOTICES
...
$ lxc exec juju-c4252b-0-lxd-0 bash
tail -f /var/log/
+ curl -sSf --connect-timeout 20 --noproxy * --insecure -o /var/lib/
Cloud-init v. 23.2.2-
+ echo Agent binaries downloaded successfully.
Agent binaries downloaded successfully.
+ break
+ sha256sum /var/lib/
...
and from within that container:
root@juju-
curl: (35) error:0607B0C8:
35
root@juju-
0
So if I force it, it fails, but as long as I don't (and juju doesn't) it successfully downloads. And the container had no problem starting up.