CentOS/RHEL based amphorae: no ecryptfs-utils package for encrypted ramfs certs storage

[Bernard Cafarelli]

Per https://bugs.launchpad.net/octavia/+bug/1640832/comments/1, diskimage-create.sh finishes without an error on Centos/RHEL, but ecryptfs-utils package does not exist in the current repositories and does not get installed (checked with guestmount/chroot).
So "Terminated HTTPS certs and keys in encrypted ramfs" will not work on these amphorae.

[Bernard Cafarelli (bcafarel)]

So ecryptfs was deprecated in RHEL 6, and completely removed in 7 (which means it is not available in CentOS either). Here are the possible fixes I thought about:
* extend the element to compile and install ecryptfs manually. This includes rebuilding the kernel module as it was also removed and requires a bunch of development packages
* use EncFs instead of ecryptfs. It is fuse-based alernative, so no kernel module required, but is a less popular solution in encryption from what I have seen
* use cryptsetup/LUKS with the same type of unified init scripts currently in for ecryptfs. Looks like the "standard" option for encryption (and was the recommended alternative after ecryptfs deprecation)
* use cryptsetup/LUKS with the system-specific mount options/init scripts. This is a bit cleaner but more distro-dependant

Personnally I am in favor of option 3, thoughts?

[Michael Johnson (johnsom)]

Hi Bernard, thanks for looking at this.

I really don't want to do #1 compile anything.

I didn't originally use cryptsetup/LUKS because it was more work to setup and we need to make sure things don't get hung up on password prompts. Ideally we would like to have the amp come back up from a reboot, but with obviously an empty encrypted location. That way non-TLS amps can safely reboot on their own. We have also talked about giving the agent a way to request the certs be updated.

Really, other than the compile option, I am open to whatever works for us.

[Bernard Cafarelli (bcafarel)]

Sounds good! (yes I only suggested the compilation option if ecryptfs was a must-have by itself)

I will take a look into using crypsetup to mount an encrypted ramdisk without interaction, hoping it will work out

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/403817

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/403817
Committed: https://git.openstack.org/cgit/openstack/octavia/commit/?id=0dd4649f37f2f9a6fe14f43cde0bfeb31a810ece
Submitter: Jenkins
Branch: master

commit 0dd4649f37f2f9a6fe14f43cde0bfeb31a810ece
Author: Bernard Cafarelli <email address hidden>
Date: Mon Nov 28 12:03:54 2016 +0100

    Use cryptsetup/LUKS for encrypted ramfs

    ecryptfs was dropped from RHEL/CentOS, use LUKS on a RAM-backed block
    device (brd) instead.

    Made the element name more generic

    Added systemctl enable call in postinstall (for systemd init), so that
    the service is correctly started and listed as wanted by amphora-agent

    Change-Id: Id8c7ff93ae244ef14480e22c85dc79355a902105
    Closes-Bug: #1642982
    Closes-Bug: #1662952

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/octavia 1.0.0.0b1 development milestone.