Skip to content

Latest commit

 

History

History
79 lines (51 loc) · 9 KB

s6-secure-onboarding-with-fdo.md

File metadata and controls

79 lines (51 loc) · 9 KB
Raw

Section 6 - Secure Onboarding with FDO

Video

Section 6 - Video

  1. Open Gitea in http://<edge-management-server-ip>:3000 and use one of the configured users/passwords (by default user1 to user3 are created with password1 to password3). The FDO onboarding will be performed in the "test environment", so go to the rhde_image/test directory. There you will see the following files:

  • test-image-definition.yml: This is the descriptor that will generate the image Blueprint and commit that Blueprint in the Image Builder service to generate the new Red Hat Device Edge image. The file is actually the vars for the Osbuild Composer Ansible Collection.

  • test-deploy_version.yml: This is a workaround to save some time. It makes it possible to create images in advance so you only have to publish them if you want to use them during the demo. Check TIP: Reducing the demo/workshop time by pre-creating images in advance for more details.

  • test-fdo-definition.yml: This is the Blueprint that will generate the Simplified Installer ISO from the published OSTRee repo created using the test-image-definition.yml definition. In this file there is also information about the location of the FDO manufacturing server and the Ignition file that will be used to customize the onboarding first boot.

  • test-ignition.bu: This the Butane file will be used to create the Ignition file that will be used to perform the first boot customizations. In this case we use Ignition instead of Kickstart because two reasons: it's a supported way to customize your images, so you need to know it because in some cases you won't be able to use kickstart (ie. in qcow2/raw images kickstart won't work), and also because we will be using the Image Builder to generate Simplified Installer ISO that will trigger the FDO onboarding automatically, and Image Builder only accepts Ignition to customize this ISO.

    Note

    At this moment Ignition does not support custom disk partitioning, and since it is not supported in Image Blueprints either you cannot define a specific disk layout. This has some implications, for example, if you want to use Microshift with dynamic PVs (using TopoLVM) you need to setup a certain LVM layout to make it work. In the prod example we used Kickstar to perform the partition and LVM setup, that's not possible today with Ignition and RHDE. If you want to deploy FDO using the Simplified Installer, you will need to customize the generated ISO injecting a kickstart to perform the disk configuration before using it to onboard your edge devices (you can re-use the AAP Job Create ISO Kickstart to do that, just include the Simplified Installer ISO path in the iso_base Job variable).

  1. Modify something in the test-image-definition.yml to trigger the EDA webhook or directly go to AAP and launch the New Edge Device Image Workflow including the reference variable env:test, so the right Blueprint definition is used during the image creation. The Workflow will take some time, because it needs to generate the OSTree image and then it will also need to run an additional compose build for the Simplified Installer.

  2. Show in AAP the Workflow running. The workflow will also be aware that you have a test-ignition.bu in the test environment definition, so it will generate the Ignition file and will publish it using the HTTP Server (same that it happened with the Kickstart in the example prod environment)

  3. When the Compose Simplified Installer is done you can check the output to get the URL from where you can download the ISO file (it will be located in http://<edge manager ip>/<user>/). If the Ignition file publish has finised you can also take the opportunity to show the generated Ignition file (test-ignition.ign).

  4. It's time to deploy the edge device. Since you are using a Simplified Installer ISO generated by the Image Builder you need to bear in mind that the device where you use the ISO will need to use UEFI boot, not legacy BIOS. Pay attention if you are using VMs because this is a setting that usually must be configured while creating the VM. Another important point to take into account is that the FDO demo is configured to use a TPM module to store the device ID in a secure way, so if you create a VM you need to be sure that a virtual TPM is included in the VM definition (if that's not an option for you, you can change the FDO service to use text file instead of TPM).

Note

Mac users using UTM to create VMs with TPM are facing issues while booting RHEL, in order to fix that issue you will need to disable Secure Boot. You have to type exit in UEFI shell, select the “Device Manager” -> “Secure Boot Configuration” -> Press Enter on the “Attempt Secure Boot” option

  1. Open an SSH session in the Edge Management server and run sudo watch ls /etc/fdo/stores to see how the voucher is sent when the device turns on

Note

In this lab the Voucher autoapproval has been setup, so it is directly copied (accepted) from the owner_vouchers directory into the rendezvous_registered directory automatically. You should explain that this is possible because for this demo we are running an all-in-one FDO server but in production each FDO service should have its own dedicated server.

  1. Boot the edge device from the ISO and wait until you get the prompt (or the kiosk-mode if it's configured). While this happens you can SSH to the Edge Manager server, show the /etc/fdo/serviceinfo-api-server.conf.d/serviceinfo-api-server.yml and explain the automation performed with the FDO servers, and how those are interdependant with the customizations made using Ignition (file test-ignition.bu in Gitea). It is important to mention that FDO includes two secrets: the ipsec secret (useful if you setup a VPN for your demo) and a Token to access AAP (this token is fake, it was configured here just to show the FDO concept, AAP is configured to accept request without further authentication in this demo).

Note

The start of the onboarding process takes more time to start than when not using FDO, so be patient until you find the AAP onboarding workflow running

  1. After some time, check in AAP that the device is being onboarded. During this time you can jump into the edge device and:
  • Show that the customizations configured in the Ignition file have been applied
  • Run journalctl -u fdo-client-linuxapp and show the FDO client in action while contacting the Rendezvous and Owner servers
  • Show that the customizations made by FDO have been applied

  1. SSH to the Edge Server and show the different /etc/fdo/stores/ directories. Explain that for this demo FDO is configured to auto-approve the onboarding but you can also control what devices will be accepted by changing the report_to_rendezvous_endpoint_enabled parameter to false in the /etc/fdo/owner-onboarding-server.conf.d/owner-onboarding-server.yml configuration file what will make necessary to manually copy the vouchers in /etc/fdo/stores/owner_vouchers/ to the /etc/fdo/stores/rendezvous_registered/ directory to accept the device (an ansible playbook run by AAP can also be configured).

  2. (optional) You can also run lsblk on the edge device and show the luks encryption in the disk also performed by the fdo client following the config sent by the FDO server ()/etc/fdo/serviceinfo-api-server.conf.d/serviceinfo-api-server.yml).

[root@edge-5254003D5080 ~]# lsblk 
NAME                                          MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
sr0                                            11:0    1 1024M  0 rom   
vda                                           252:0    0   20G  0 disk  
├─vda1                                        252:1    0    1M  0 part  
├─vda2                                        252:2    0  127M  0 part  /boot/efi
├─vda3                                        252:3    0  384M  0 part  /boot
└─vda4                                        252:4    0 19.5G  0 part  
  └─luks-8203001f-85f9-499c-aa11-d526d8ee3b21 253:0    0 19.5G  0 crypt 
    └─rootvg-rootlv                           253:1    0    9G  0 lvm   /var/lib/containers/storage/overlay
                                                                        /var
                                                                        /sysroot/ostree/deploy/redhat/var
                                                                        /usr
                                                                        /etc
                                                                        /
                                                                        /sysroot