Uploaded image for project: 'OpenShift Request For Enhancement'
  1. OpenShift Request For Enhancement
  2. RFE-2992

Support Shielded VMs in Google Cloud Platform (GCP) with IPI

XMLWordPrintable

    • False
    • None
    • False
    • Not Selected
    • 0
    • 0% 0%

      Epic Goal

      • As an OpenShift Infrastructure Admin, I want to deploy OpenShift on GCP Shielded VMs  in Google Cloud Platform with installer provisioned infrastructure (IPI), as I want to take advantage of Shielded VMs with Shielded disk images with Secure Boot, vTPM, and Integrity Monitoring options enabled.

      Why is this important?

      Scenarios

      1. ...

      Acceptance Criteria

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • ...

      Dependencies (internal and external)

      1. ...

      Previous Work (Optional):

      • Currently vTPM and Integrity Monitoring are on but Secure Boot is off when using the IPI.
      • In bare metal, we have options to support “bootMode: UEFOSecureBoot”.
      • In UPI, this should be possible but has not yet been tested nor documented.
      • Google documentation says:
      • This boolean constraint, when set to True, requires that all new Compute Engine VM instances use Shielded disk images with Secure Boot, vTPM, and Integrity Monitoring options enabled. Secure Boot can be disabled after creation, if desired. Existing running instances will continue to work as usual. 
      • By default, Shielded VM features do not need to be enabled in order to create Compute Engine VM instances. Shielded VM features add verifiable integrity and exfiltration resistance to your VMs. 
      • constraints/compute.requireShieldedVm
      • Additional information on Shielded VMs at https://cloud.google.com/shielded-vm

      Related support cases:

      • Cluster installation failure in OSD on Google

      Open questions:

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link to meaningful PR>

            mak.redhat.com Marcos Entenza Garcia
            julim Ju Lim
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: