An example Virtual Server running CentOS 7 with LUKS encryption
The following example demonstrates how to deploy a Virtual Server running CentOS 7 with an encrypted partition on the root disk. The method used for this example is to deploy a manifest using the Kubernetes command line.
The manifest used to deploy this Virtual Server includes cloud-init directives, which are used to encrypt unallocated space on the root disk. By using a separate partition instead of a separate block volume, additional Virtual Servers can be created by cloning the encrypted partition from the same disk.
First, the desired size of the unencrypted portion of the root disk, where the Operating System resides, must be specified. After initialization, expanding this part of the disk will require manual re-partitioning.
In this example, the given value for the disk size is 40Gi.
For more information for querying disk image sources, see System Images.
Users
.spec.users[]
Next, the user accounts for the Virtual Server are specified in the .users array. In this example, users are authenticated using SSH keys (sshpublickey) only.
More than one user may be added. See User Accounts for more information.
cloud-init
Preparing the Virtual Server for an encrypted partition requires some pre-requisite steps, which are handled, along with encryption configuration, by cloud-init.
Click to expand - cloud-init directives excerpted from the manifest
The following aspects are handled by cloud-init in this manifest:
GPT Configuration
By default, Virtual Server images are configured with an Master Boot Record (MBR) partition table, which does not support sizes above 2Ti. Because of this, the disk needs to be converted to a GUID Partition Table (GPT). This process also requires re-partitioning, as GRUB must reside on a BIOS boot partition.
All of this is accomplished with a few commands in the runcmd cloud-init directive:
Because of this, the space allocated to the Virtual Server at creation time will automatically be used for the Operating System partition. To prevent this from happening on subsequent restarts after the disk has been expanded for the encrypted partition, we need to temporarily disable cloudInit.
Since the Virtual Server needs to be powered off to expand its disk, we need to inject a script using the write_files cloud-init directive to do so, then instruct it to run at next start up using the runcmd directive:
After expanding the root disk and starting the Virtual Server back up, the script called encrypt_init.sh , which was injected via write_files, completes the configuration.
Then, cloud-init is re-enabled for subsequent reboots once the growpart and resizefs modules are disabled:
The script's output can be found in/var/mail/root, and can be viewed using cat.
Deploy the Virtual Server
With the manifest fully configured and the cloud-init directives in place, the Virtual Server is deployed using kubectl:
$kubectlapply-fcentos-7-luks-part.yaml
One of the cloudInit directives powers off the Virtual Server after it completes initialization so the disk can be expanded for the encrypted partition.
Deployment progress may be monitored by invoking kubectl --watch:
Once the Virtual Server is created and spun down, the root disk may be expanded to create the encrypted partition.
In this example, the desired size of the encrypted volume is 5Ti. Since the root disk size was initially set to 40Gi, the Virtual Server is expanded to a total size of 5040Gi using kubectl patch: