MGMT-13627: Add ConfidentialVM options to AzureMachineProviderSpec

[mresvanis]

This change adds the Confidential VM configuration options to the AzureMachineProviderSpec, in order to support Confidential Computing on Azure.

Specifically, it introduces the OS disk security profile, which includes the SecurityEncryptionType and DiskEncryptionSetID fields and adds the SecureBoot and VirtualizedTrustedPlatformModule fields in the security profile of the VM.

The OS disk security profile SecurityEncryptionType field defines whether the VM is a Confidential VM. It cannot be defined alongside the EncryptionAtHost. When SecurityEncryptionType is defined the VirtualizedTrustedPlatformModule should be set to Enabled, while SecureBoot can be either Enabled or Disabled.

Possible values for the SecurityEncryptionType are:

• DiskWithVMGuestState, OS disk encryption before VM deployment that uses platform-managed keys (PMK) or a customer-managed key (CMK)
• VMGuestStateOnly, no OS disk confidential encryption

When the SecurityEncryptionType is set to DiskWithVMGuestState, the DiskEncryptionSetID can be specified to allow using customer-managed keys to encrypt the OS disk and the VMGuestState blob.

Feature link: https://issues.redhat.com/browse/OCPBU-233

Cluster API provider Azure PR: kubernetes-sigs/cluster-api-provider-azure#3265

Related PRs for Confidential Compute support on GCP:

• MGMT-12728: Add ConfidentialCompute to GCPMachineProviderSpec #1384
• MGMT-12837: Add Shielded VMs configuration to gcp provider types #1371

Signed-off-by: Michail Resvanis mresvani@redhat.com

[openshift-ci-robot]

@mresvanis: This pull request references MGMT-13627 which is a valid jira issue.

In response to this:

This change adds the Confidential VM configuration options to the AzureMachineProviderSpec, in order to support Confidential Computing on Azure.

Specifically, the SecurityEncryptionType field defines whether the VM is a Confidential VM. It cannot be defined alongside the EncryptionAtHost. When SecurityEncryptionType is defined the VirtualizedTrustedPlatformModule should be set to Enabled, while SecureBoot can be either Enabled or Disabled.

Possible values for the SecurityEncryptionType are:

• DiskWithVMGuestState, OS disk encryption before VM deployment that uses platform-managed keys (PMK) or a customer-managed key (CMK)
• VMGuestStateOnly, no OS disk confidential encryption

When the SecurityEncryptionType is set to DiskWithVMGuestState, the SecureVMDiskEncryptionSetID can be specified as well.

Feature link: https://issues.redhat.com/browse/OCPBU-233

Signed-off-by: Michail Resvanis mresvani@redhat.com

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[openshift-ci]

Hello @mresvanis! Some important instructions when contributing to openshift/api:
API design plays an important part in the user experience of OpenShift and as such API PRs are subject to a high level of scrutiny to ensure they follow our best practices. If you haven't already done so, please review the OpenShift API Conventions and ensure that your proposed changes are compliant. Following these conventions will help expedite the api review process for your PR.

For merging purposes, this repository follows the no-Feature-Freeze process which means that in addition to the standard lgtm and approved labels this repository requires either:

bugzilla/valid-bug - applied if your PR references a valid bugzilla bug

OR

qe-approved, docs-approved, and px-approved - these labels can be applied by anyone in the openshift org via the /label <labelname> command.

Who should apply these qe/docs/px labels?

• For a no-Feature-Freeze team who is merging a feature before code freeze, they need to get those labels applied to their api repo PR by the appropriate teams (i.e. qe, docs, px)
• For a Feature Freeze (traditional) team who is merging a feature before FF, they can self-apply the labels (via /label commands), they are basically irrelevant for those teams
• For a Feature Freeze team who is merging a feature after FF, the PR should be rejected barring an exception

[openshift-ci-robot]

@mresvanis: This pull request references MGMT-13627 which is a valid jira issue.

In response to this:

This change adds the Confidential VM configuration options to the AzureMachineProviderSpec, in order to support Confidential Computing on Azure.

Specifically, the SecurityEncryptionType field defines whether the VM is a Confidential VM. It cannot be defined alongside the EncryptionAtHost. When SecurityEncryptionType is defined the VirtualizedTrustedPlatformModule should be set to Enabled, while SecureBoot can be either Enabled or Disabled.

Possible values for the SecurityEncryptionType are:

• DiskWithVMGuestState, OS disk encryption before VM deployment that uses platform-managed keys (PMK) or a customer-managed key (CMK)
• VMGuestStateOnly, no OS disk confidential encryption

When the SecurityEncryptionType is set to DiskWithVMGuestState, the SecureVMDiskEncryptionSetID can be specified as well.

Feature link: https://issues.redhat.com/browse/OCPBU-233

Related PR for GCP: #1384

Signed-off-by: Michail Resvanis mresvani@redhat.com

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[openshift-ci-robot]

@mresvanis: This pull request references MGMT-13627 which is a valid jira issue.

In response to this:

This change adds the Confidential VM configuration options to the AzureMachineProviderSpec, in order to support Confidential Computing on Azure.

Specifically, the SecurityEncryptionType field defines whether the VM is a Confidential VM. It cannot be defined alongside the EncryptionAtHost. When SecurityEncryptionType is defined the VirtualizedTrustedPlatformModule should be set to Enabled, while SecureBoot can be either Enabled or Disabled.

Possible values for the SecurityEncryptionType are:

• DiskWithVMGuestState, OS disk encryption before VM deployment that uses platform-managed keys (PMK) or a customer-managed key (CMK)
• VMGuestStateOnly, no OS disk confidential encryption

When the SecurityEncryptionType is set to DiskWithVMGuestState, the SecureVMDiskEncryptionSetID can be specified as well.

Feature link: https://issues.redhat.com/browse/OCPBU-233

Related PRs for GCP:

• MGMT-12728: Add ConfidentialCompute to GCPMachineProviderSpec #1384
• MGMT-12837: Add Shielded VMs configuration to gcp provider types #1371

Signed-off-by: Michail Resvanis mresvani@redhat.com

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[openshift-ci-robot]

@mresvanis: This pull request references MGMT-13627 which is a valid jira issue.

In response to this:

This change adds the Confidential VM configuration options to the AzureMachineProviderSpec, in order to support Confidential Computing on Azure.

Specifically, the SecurityEncryptionType field defines whether the VM is a Confidential VM. It cannot be defined alongside the EncryptionAtHost. When SecurityEncryptionType is defined the VirtualizedTrustedPlatformModule should be set to Enabled, while SecureBoot can be either Enabled or Disabled.

Possible values for the SecurityEncryptionType are:

• DiskWithVMGuestState, OS disk encryption before VM deployment that uses platform-managed keys (PMK) or a customer-managed key (CMK)
• VMGuestStateOnly, no OS disk confidential encryption

When the SecurityEncryptionType is set to DiskWithVMGuestState, the SecureVMDiskEncryptionSetID can be specified as well.

Feature link: https://issues.redhat.com/browse/OCPBU-233

Related PRs for Confidential Compute support on GCP:

• MGMT-12728: Add ConfidentialCompute to GCPMachineProviderSpec #1384
• MGMT-12837: Add Shielded VMs configuration to gcp provider types #1371

Signed-off-by: Michail Resvanis mresvani@redhat.com

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[openshift-ci-robot]

@mresvanis: This pull request references MGMT-13627 which is a valid jira issue.

In response to this:

This change adds the Confidential VM configuration options to the AzureMachineProviderSpec, in order to support Confidential Computing on Azure.

Specifically, it introduces the OS disk security profile, which includes the SecurityEncryptionType and DiskEncryptionSetID fields and adds the SecureBoot and vTPM fields in the security profile of the VM.

The OS disk security profile SecurityEncryptionType field defines whether the VM is a Confidential VM.
It cannot be defined alongside the EncryptionAtHost. When SecurityEncryptionType is defined the VirtualizedTrustedPlatformModule should be set to Enabled, while SecureBoot can be either Enabled or Disabled.

Possible values for the SecurityEncryptionType are:

• DiskWithVMGuestState, OS disk encryption before VM deployment that uses platform-managed keys (PMK) or a customer-managed key (CMK)
• VMGuestStateOnly, no OS disk confidential encryption

When the SecurityEncryptionType is set to DiskWithVMGuestState, the DiskEncryptionSetID can be specified to allow using Customer-managed keys to encrypt the OS disk and the VMGuestState blob.

Feature link: https://issues.redhat.com/browse/OCPBU-233

Related PRs for Confidential Compute support on GCP:

• MGMT-12728: Add ConfidentialCompute to GCPMachineProviderSpec #1384
• MGMT-12837: Add Shielded VMs configuration to gcp provider types #1371

Signed-off-by: Michail Resvanis mresvani@redhat.com

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[mresvanis]

/hold
We should probably hold this PR until:

• either the necessary RHCOS / RHEL features are present, in order to have full support for Confidential VMs on Azure (i.e. with support for OS attestation)
• or we decide that support for SecureBoot, vTPM and OS disk encryption on Confidential VMs, but without OS attestation, is good enough as a first step

[mresvanis]

Upstream issue: kubernetes-sigs/cluster-api-provider-azure#3264
Upstream PR: kubernetes-sigs/cluster-api-provider-azure#3265

[mresvanis]

/unhold
I believe the consensus is that we can enable support for Confidential VMs and Trusted launch for VMs already, in order to have a head start for support of Confidential OpenShift Clusters in the future.

[openshift-ci-robot]

@mresvanis: This pull request references MGMT-13627 which is a valid jira issue.

In response to this:

This change adds the Confidential VM configuration options to the AzureMachineProviderSpec, in order to support Confidential Computing on Azure.

Specifically, it introduces the OS disk security profile, which includes the SecurityEncryptionType and DiskEncryptionSetID fields and adds the SecureBoot and vTPM fields in the security profile of the VM.

The OS disk security profile SecurityEncryptionType field defines whether the VM is a Confidential VM.
It cannot be defined alongside the EncryptionAtHost. When SecurityEncryptionType is defined the VirtualizedTrustedPlatformModule should be set to Enabled, while SecureBoot can be either Enabled or Disabled.

Possible values for the SecurityEncryptionType are:

• DiskWithVMGuestState, OS disk encryption before VM deployment that uses platform-managed keys (PMK) or a customer-managed key (CMK)
• VMGuestStateOnly, no OS disk confidential encryption

When the SecurityEncryptionType is set to DiskWithVMGuestState, the DiskEncryptionSetID can be specified to allow using Customer-managed keys to encrypt the OS disk and the VMGuestState blob.

Feature link: https://issues.redhat.com/browse/OCPBU-233

Cluster API provider Azure PR: kubernetes-sigs/cluster-api-provider-azure#3265

Related PRs for Confidential Compute support on GCP:

• MGMT-12728: Add ConfidentialCompute to GCPMachineProviderSpec #1384
• MGMT-12837: Add Shielded VMs configuration to gcp provider types #1371

Signed-off-by: Michail Resvanis mresvani@redhat.com

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[mresvanis]

Hi @JoelSpeed and @soltysh, now that the respective upstream PR is merged I would very much appreciate your review and feedback for this PR. Many thanks.

[JoelSpeed]

I will try to review next week. A quick scan suggests that the names of some of the fields might need to be changed, since they don't fit the conventions (they don't fit upstream conventions either, eg VTpmEnabled should be VTPMEnabled, oh and it's a bool, which we don't allow either).

Could you please review our conventions and make the appropriate changes?

The API need not match upstream, we would prefer it matches conventions downstream where possible, so long as the API can be converted to upstream's at a later point, that's ok

[openshift-ci-robot]

@mresvanis: This pull request references MGMT-13627 which is a valid jira issue.

In response to this:

This change adds the Confidential VM configuration options to the AzureMachineProviderSpec, in order to support Confidential Computing on Azure.

Specifically, it introduces the OS disk security profile, which includes the SecurityEncryptionType and DiskEncryptionSetID fields and adds the SecureBoot and vTPM fields in the security profile of the VM.

The OS disk security profile SecurityEncryptionType field defines whether the VM is a Confidential VM.
It cannot be defined alongside the EncryptionAtHost. When SecurityEncryptionType is defined the VirtualizedTrustedPlatformModule should be set to Enabled, while SecureBoot can be either Enabled or Disabled.

Possible values for the SecurityEncryptionType are:

• DiskWithVMGuestState, OS disk encryption before VM deployment that uses platform-managed keys (PMK) or a customer-managed key (CMK)
• VMGuestStateOnly, no OS disk confidential encryption

When the SecurityEncryptionType is set to DiskWithVMGuestState, the DiskEncryptionSetID can be specified to allow using customer-managed keys to encrypt the OS disk and the VMGuestState blob.

Feature link: https://issues.redhat.com/browse/OCPBU-233

Cluster API provider Azure PR: kubernetes-sigs/cluster-api-provider-azure#3265

Related PRs for Confidential Compute support on GCP:

• MGMT-12728: Add ConfidentialCompute to GCPMachineProviderSpec #1384
• MGMT-12837: Add Shielded VMs configuration to gcp provider types #1371

Signed-off-by: Michail Resvanis mresvani@redhat.com

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[mresvanis]

@JoelSpeed I think I have covered the conformance to our API conventions, just a kind reminder for a review. Thanks in advance.

[openshift-ci-robot]

@mresvanis: This pull request references MGMT-13627 which is a valid jira issue.

In response to this:

This change adds the Confidential VM configuration options to the AzureMachineProviderSpec, in order to support Confidential Computing on Azure.

Specifically, it introduces the OS disk security profile, which includes the SecurityEncryptionType and DiskEncryptionSetID fields and adds the SecureBoot and VirtualizedTrustedPlatformModule fields in the security profile of the VM.

The OS disk security profile SecurityEncryptionType field defines whether the VM is a Confidential VM.
It cannot be defined alongside the EncryptionAtHost. When SecurityEncryptionType is defined the VirtualizedTrustedPlatformModule should be set to Enabled, while SecureBoot can be either Enabled or Disabled.

Possible values for the SecurityEncryptionType are:

• DiskWithVMGuestState, OS disk encryption before VM deployment that uses platform-managed keys (PMK) or a customer-managed key (CMK)
• VMGuestStateOnly, no OS disk confidential encryption

When the SecurityEncryptionType is set to DiskWithVMGuestState, the DiskEncryptionSetID can be specified to allow using customer-managed keys to encrypt the OS disk and the VMGuestState blob.

Feature link: https://issues.redhat.com/browse/OCPBU-233

Cluster API provider Azure PR: kubernetes-sigs/cluster-api-provider-azure#3265

Related PRs for Confidential Compute support on GCP:

• MGMT-12728: Add ConfidentialCompute to GCPMachineProviderSpec #1384
• MGMT-12837: Add Shielded VMs configuration to gcp provider types #1371

Signed-off-by: Michail Resvanis mresvani@redhat.com

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[openshift-ci-robot]

@mresvanis: This pull request references MGMT-13627 which is a valid jira issue.

In response to this:

This change adds the Confidential VM configuration options to the AzureMachineProviderSpec, in order to support Confidential Computing on Azure.

Specifically, it introduces the OS disk security profile, which includes the SecurityEncryptionType and DiskEncryptionSetID fields and adds the SecureBoot and VirtualizedTrustedPlatformModule fields in the security profile of the VM.

The OS disk security profile SecurityEncryptionType field defines whether the VM is a Confidential VM. It cannot be defined alongside the EncryptionAtHost. When SecurityEncryptionType is defined the VirtualizedTrustedPlatformModule should be set to Enabled, while SecureBoot can be either Enabled or Disabled.

Possible values for the SecurityEncryptionType are:

• DiskWithVMGuestState, OS disk encryption before VM deployment that uses platform-managed keys (PMK) or a customer-managed key (CMK)
• VMGuestStateOnly, no OS disk confidential encryption

When the SecurityEncryptionType is set to DiskWithVMGuestState, the DiskEncryptionSetID can be specified to allow using customer-managed keys to encrypt the OS disk and the VMGuestState blob.

Feature link: https://issues.redhat.com/browse/OCPBU-233

Cluster API provider Azure PR: kubernetes-sigs/cluster-api-provider-azure#3265

Related PRs for Confidential Compute support on GCP:

• MGMT-12728: Add ConfidentialCompute to GCPMachineProviderSpec #1384
• MGMT-12837: Add Shielded VMs configuration to gcp provider types #1371

Signed-off-by: Michail Resvanis mresvani@redhat.com

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[mresvanis]

/test verify

[JoelSpeed]

If you can update the required tags to match the correct format, there's one I highlighted and one a few lines below, after that, this LGTM

[mresvanis]

/retest-required

[JoelSpeed]

/test verify

[JoelSpeed]

/lgtm

The verify failure is in code that's already in master, looks like maybe there's an ordering issue coming out somewhere, will need to be investigated

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JoelSpeed, mresvanis

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [JoelSpeed]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[JoelSpeed]

/test verify

[openshift-ci]

@mresvanis: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.