Skip to content

Confidential Computing VM

General GCP product documentation here: GCP Confidential Compute (CC) (https://app.clickup.com/2496230/docs/2c5q6-69975/2c5q6-254515)

We started using Confidential Computing (CC) instances in 2024/01 on some TMS environments to comply with a customer's request but we are also generally rolling out CC-infrastructure to new projects to bring in a more secure environment to work in. Next up we are working on bringing CC-infrastructure to ROAD.

Impacts

  • Needs AMD Epyc processors so if you have some other like Intel processors in use at some instances you then have to re-create those instances with Epyc processor (N2D)
    • Even with AMD Epyc processors you should only choose the 3rd generation Milan-architecture and not the 2nd generation Rome-architecture processors since Rome has a Zenbleed vulnerability
  • Adds big level of security (what does this actually mean?)
  • Needs to be tested first at nightly to be sure there will be no problems with the software, integrations etc
  • Might cost more (depends of course what was the earlier instance machine type)
  • Needs Ubuntu Pro FIPS (adds also some costs)
  • Network Interface Card (NIC) requirements: gVNIC

Needs to be done with Terraform. At some point it would be clever to implement this to our whole GCP-environment instances that needs this security layer. Terraform repos with CC-architecture implementations: * https://github.com/Attracs/terraform-attracs-services-195009 * https://github.com/Attracs/terraform-attracs-logistics

There are also some other options that you should enable with this * Secure boot * vTPM * ~~Integrity monitoring~~ * Integrity monitoring is not used for now as we don't fully understand how to use it.

Integrity Monitoring

More documentation about this here: GCP CC Integrity Monitoring failure modes (https://app.clickup.com/2496230/docs/2c5q6-69975/2c5q6-254575) * Our confidential instances cannot use integrity monitoring for now * Caused our test instance to refuse any SSH connections to it after updating the kernel and rebooting the instance, probably lost our authorized keys? * GCP logs said something about hashes not being correct * We have to investigate integrity monitoring further and write documentation on how to actually use this feature, some OS updates cause the integrity monitoring to fail, so after update (but preferably BEFORE RESTART) we have to run integrity monitoring policy updates