Can't deploy AWS instances with encrypted root FS

Bug #1871761 reported by Paul Goins
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canonical Juju
Triaged
Low
Unassigned

Bug Description

Hi,

I'm using juju 2.7.5-focal-amd64 to deploy a controller and model into AWS. Everything here was done within the last 24 hours.

I finished deploying a set of apps, but I noted that all the units are running on unencrypted SSD volumes (AWS gp2 volumes specifically). I'd like to redeploy, or add/remove units, so that all my units are running on encrypted volumes instead.

If I'm understanding the storage docs correctly for juju, it sounds like I either need to update the ebs pool (specified via storage-default-block-source), or _maybe_ the rootfs pool (although the provider isn't ebs), with the encrypted=true key/value pair, e.g. "juju update-storage-pool ebs encrypted=true".

Unfortunately, I can't get this to work.

* "juju update-storage-pool ebs encrypted=true" returns "ERROR pool "ebs" not found", despite "ebs" showing up via "juju storage-pools". The same is true for rootfs, although that might not work anyway since rootfs uses the rootfs provider instead.
* Creating a new storage pool and associating that with storage-default-block-source also does not seem to work. (e.g. juju create-storage-pool ebs-encrypted ebs encrypted=true; juju model-config storage-default-block-source=ebs-encrypted)

Is there a way to have the root FS on new AWS-based units be encrypted?

Revision history for this message
Ian Booth (wallyworld) wrote :

"ebs" is a built in virtual pool and gives out of the box ebs support, so creating a new bespoke ebs pool with the encrypted option is the correct approach.

How does you charm declare its storage? "filesystem" or "block"?
For "filesystem" storage you need to use the "storage-default-filesystem-source" setting.
Yes, the underlying storage provided by the cloud is a block device, but as far as the charm is concerned it is asking for a filesystem storage device; Juju take the block device from the cloud and formats an ext4 filesystem on top and hands that to the charm.

I am not sure there's a way to get the rootfs of the running instance to be encrypted. But the charm can ensure all of its workload data is stored on an encrypted volume using a storage poo which provisions encrypted volumes.

Revision history for this message
Ian Booth (wallyworld) wrote :

Any update on whether using the suggested model config attribute works?

Revision history for this message
Paul Goins (vultaire) wrote :

Hello Ian - I apologize for not replying sooner. Thank you for your feedback.

In this particular case, I could accomplish what I needed by setting an option in AWS to encrypt EBS volumes by default. Having that option available seems to reduce the urgency of this request. Personally, doing this is good enough for my current purposes.

I haven't quite worked with juju storage on charms yet, but thank you for the explanation; that may be an option in the future. I think it would still be nice to allow for encryption on the rootfs in some way, but presently there's no urgent personal need for this since I found the option above.

Revision history for this message
Ian Booth (wallyworld) wrote :

All good! I'll triage this as Medium then so we can keep track of it.

Changed in juju:
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Canonical Juju QA Bot (juju-qa-bot) wrote :

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.

Changed in juju:
importance: Medium → Low
tags: added: expirebugs-bot
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.