Appendix C. Whole Disk Images
The main overcloud image is a flat partition image. This means it contains no partitioning information or bootloader on the images itself. The director uses a separate kernel and ramdisk when booting and creates a basic partitioning layout when writing the overcloud image to disk. However, you can create a whole disk image, which includes a partitioning layout, bootloader, and hardened security.
The following process uses the director’s image building feature. Red Hat only supports images built using the guidelines contained in this section. Custom images built outside of these specifications are not supported.
A security hardened image includes extra security measures necessary for Red Hat OpenStack Platform deployments where security is an important feature. Some of the recommendations for a secure image are as follows:
-
The
/tmp
directory is mounted on a separate volume or partition and has therw
,nosuid
,nodev
,noexec
, andrelatime
flags -
The
/var
,/var/log
and the/var/log/audit
directories are mounted on separate volumes or partitions, with therw
,relatime
flags -
The
/home
directory is mounted on a separate partition or volume and has therw
,nodev
,relatime
flags Include the following changes to the
GRUB_CMDLINE_LINUX
setting:-
To enable auditing, include an extra kernel boot flag by adding
audit=1
-
To disable the kernel support for USB using boot loader configuration by adding
nousb
-
To remove the insecure boot flags by setting
crashkernel=auto
-
To enable auditing, include an extra kernel boot flag by adding
-
Blacklist insecure modules (
usb-storage
,cramfs
,freevxfs
,jffs2
,hfs
,hfsplus
,squashfs
,udf
,vfat
) and prevent them from being loaded. -
Remove any insecure packages (
kdump
installed bykexec-tools
andtelnet
) from the image as they are installed by default -
Add the new
screen
package necessary for security
To build a security hardened image, you need to:
- Download a base Red Hat Enterprise Linux 7 image
- Set the environment variables specific to registration
- Customize the image by modifying the partition schema and the size
- Create the image
- Upload it to your deployment
The following sections detail the procedures to achieve these tasks.
C.1. Downloading the Base Cloud Image
Before building a whole disk image, you need to download an existing cloud image of Red Hat Enterprise Linux to use as a basis. Navigate to the Red Hat Customer Portal and select the KVM Guest Image to download. For example, the KVM Guest Image for the latest Red Hat Enterprise Linux is available on the following page:
C.2. Disk Image Environment Variables
As a part of the disk image building process, the director requires a base image and registration details to obtain packages for the new overcloud image. You define these aspects using Linux environment variables.
The image building process temporarily registers the image with a Red Hat subscription and unregisters the system once the image building process completes.
To build a disk image, set Linux environment variables that suit your environment and requirements:
- DIB_LOCAL_IMAGE
- Sets the local image to use as your basis.
- REG_ACTIVATION_KEY
- Use an activation key instead as part of the registration process.
- REG_AUTO_ATTACH
- Defines whether or not to automatically attach the most compatible subscription.
- REG_BASE_URL
-
The base URL of the content delivery server to pull packages. The default Customer Portal Subscription Management process uses
https://cdn.redhat.com
. If using a Red Hat Satellite 6 server, this parameter should use the base URL of your Satellite server. - REG_ENVIRONMENT
- Registers to an environment within an organization.
- REG_METHOD
-
Sets the method of registration. Use
portal
to register a system to the Red Hat Customer Portal. Usesatellite
to register a system with Red Hat Satellite 6. - REG_ORG
- The organization to register the images.
- REG_POOL_ID
- The pool ID of the product subscription information.
- REG_PASSWORD
- Gives the password for the user account registering the image.
- REG_REPOS
A string of repository names separated with commas (no spaces). Each repository in this string is enabled through
subscription-manager
.Use the following repositories for a security hardened whole disk image:
-
rhel-7-server-rpms
-
rhel-7-server-extras-rpms
-
rhel-ha-for-rhel-7-server-rpms
-
rhel-7-server-optional-rpms
-
rhel-7-server-openstack-13-rpms
-
- REG_SAT_URL
- The base URL of the Satellite server to register Overcloud nodes. Use the Satellite’s HTTP URL and not the HTTPS URL for this parameter. For example, use http://satellite.example.com and not https://satellite.example.com.
- REG_SERVER_URL
-
Gives the hostname of the subscription service to use. The default is for the Red Hat Customer Portal at
subscription.rhn.redhat.com
. If using a Red Hat Satellite 6 server, this parameter should use the hostname of your Satellite server. - REG_USER
- Gives the user name for the account registering the image.
The following is an example set of commands to export a set of environment variables to temporarily register a local QCOW2 image to the Red Hat Customer Portal:
$ export DIB_LOCAL_IMAGE=./rhel-server-7.5-x86_64-kvm.qcow2 $ export REG_METHOD=portal $ export REG_USER="[your username]" $ export REG_PASSWORD="[your password]" $ export REG_REPOS="rhel-7-server-rpms \ rhel-7-server-extras-rpms \ rhel-ha-for-rhel-7-server-rpms \ rhel-7-server-optional-rpms \ rhel-7-server-openstack-13-rpms"
C.3. Customizing the Disk Layout
The default security hardened image size is 20G and uses predefined partitioning sizes. However, some modifications to the partitioning layout are required to accommodate overcloud container images. The following sections increase the image size to 40G. You can also provide further modification to the partitioning layout and disk size to suit your needs.
To modify the partitioning layout and disk size, perform the following steps:
-
Modify the partitioning schema using the
DIB_BLOCK_DEVICE_CONFIG
environment variable. -
Modify the global size of the image by updating the
DIB_IMAGE_SIZE
environment variable.
C.3.1. Modifying the Partitioning Schema
You can modify the partitioning schema to alter the partitioning size, create new partitions, or remove existing ones. You can define a new partitioning schema with the following environment variable:
$ export DIB_BLOCK_DEVICE_CONFIG='<yaml_schema_with_partitions>'
The following YAML structure represents the modified logical volume partitioning layout to accommodate enough space to pull overcloud container images:
export DIB_BLOCK_DEVICE_CONFIG=''' - local_loop: name: image0 - partitioning: base: image0 label: mbr partitions: - name: root flags: [ boot,primary ] size: 40G - lvm: name: lvm base: [ root ] pvs: - name: pv base: root options: [ "--force" ] vgs: - name: vg base: [ "pv" ] options: [ "--force" ] lvs: - name: lv_root base: vg extents: 23%VG - name: lv_tmp base: vg extents: 4%VG - name: lv_var base: vg extents: 45%VG - name: lv_log base: vg extents: 23%VG - name: lv_audit base: vg extents: 4%VG - name: lv_home base: vg extents: 1%VG - mkfs: name: fs_root base: lv_root type: xfs label: "img-rootfs" mount: mount_point: / fstab: options: "rw,relatime" fsck-passno: 1 - mkfs: name: fs_tmp base: lv_tmp type: xfs mount: mount_point: /tmp fstab: options: "rw,nosuid,nodev,noexec,relatime" fsck-passno: 2 - mkfs: name: fs_var base: lv_var type: xfs mount: mount_point: /var fstab: options: "rw,relatime" fsck-passno: 2 - mkfs: name: fs_log base: lv_log type: xfs mount: mount_point: /var/log fstab: options: "rw,relatime" fsck-passno: 3 - mkfs: name: fs_audit base: lv_audit type: xfs mount: mount_point: /var/log/audit fstab: options: "rw,relatime" fsck-passno: 4 - mkfs: name: fs_home base: lv_home type: xfs mount: mount_point: /home fstab: options: "rw,nodev,relatime" fsck-passno: 2 '''
Use this sample YAML content as a basis for your image’s partition schema. Modify the partition sizes and layout to suit your needs.
Define the right partition sizes for the image as you will not be able to resize them after the deployment.
C.3.2. Modifying the Image Size
The global sum of the modified partitioning schema might exceed the default disk size (20G). In this situation, you might need to modify the image size. To modify the image size, edit the configuration files used to create the image.
Create a copy of the /usr/share/openstack-tripleo-common/image-yaml/overcloud-hardened-images.yaml
:
# cp /usr/share/openstack-tripleo-common/image-yaml/overcloud-hardened-images.yaml \ /home/stack/overcloud-hardened-images-custom.yaml
For UEFI whole disk images, use /usr/share/openstack-tripleo-common/image-yaml/overcloud-hardened-images-uefi.yaml
.
Edit the DIB_IMAGE_SIZE
in the configuration file to adjust the values as necessary:
...
environment:
DIB_PYTHON_VERSION: '2'
DIB_MODPROBE_BLACKLIST: 'usb-storage cramfs freevxfs jffs2 hfs hfsplus squashfs udf vfat bluetooth'
DIB_BOOTLOADER_DEFAULT_CMDLINE: 'nofb nomodeset vga=normal console=tty0 console=ttyS0,115200 audit=1 nousb'
DIB_IMAGE_SIZE: '40' 1
COMPRESS_IMAGE: '1'
- 1
- Adjust this value to the new total disk size.
Save this file.
When the director deploys the overcloud, it creates a RAW version of the overcloud image. This means your undercloud must have necessary free space to accommodate the RAW image. For example, if you increase the security hardened image size to 40G, you must have 40G of space available on the undercloud’s hard disk.
When the director eventually writes the image to the physical disk, the director creates a 64MB configuration drive primary partition at the end of the disk. When creating your whole disk image, ensure it is less than the size of the physical disk to accommodate this extra partition.
C.4. Creating a Security Hardened Whole Disk Image
After you have set the environment variables and customized the image, create the image using the openstack overcloud image build
command:
# openstack overcloud image build \ --image-name overcloud-hardened-full \ --config-file /home/stack/overcloud-hardened-images-custom.yaml \ --config-file /usr/share/openstack-tripleo-common/image-yaml/overcloud-hardened-images-rhel7.yaml
The /home/stack/overcloud-hardened-images-custom.yaml
custom configuration file contains the new disk size from Section C.3.2, “Modifying the Image Size”. If you are not using a different custom disk size, use the original /usr/share/openstack-tripleo-common/image-yaml/overcloud-hardened-images.yaml
file instead.
For UEFI whole disk images, use the /usr/share/openstack-tripleo-common/image-yaml/overcloud-hardened-images-uefi-rhel7.yaml
configuration file.
The overcloud-hardened-full.qcow2
image that you have created contains all the necessary security features.
C.5. Uploading a Security Hardened Whole Disk Image
Upload the image to the OpenStack Image (glance) service and start using it from the Red Hat OpenStack Platform director. To upload a security hardened image, execute the following steps:
Rename the newly generated image and move it to your images directory:
# mv overcloud-hardened-full.qcow2 ~/images/overcloud-full.qcow2
Remove all the old overcloud images:
# openstack image delete overcloud-full # openstack image delete overcloud-full-initrd # openstack image delete overcloud-full-vmlinuz
Upload the new overcloud image:
# openstack overcloud image upload --image-path /home/stack/images --whole-disk
If you want to replace an existing image with the security hardened image, use the --update-existing
flag. This will overwrite the original overcloud-full
image with a new security hardened image you generated.