Feature Overview

This feature aims to enable customers of OCP to integrate 3rd party KMS solutions for encrypting etcd values at rest in accordance with: https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/

This feature makes the feature GA after the Tech Preview released with OCPSTRAT-108 

Goals

• Bring KMS v2 API to stable level.
• Create/expose mechanisms for customers to connect to external KMS providers.
• Provide similar UX experience for all of self-hosted, hypershift, SNO scenarios.
• Provide mechanisms to allow encrypt/decrypt the platform secrets during temporary loss of access to the external KMS provider e.g. work from the cache and mechanism to block actions that would delete the cache such as certificates rotations, updates or restarting of the Kube API server pods.

General Prioritization for the Feature

1. Approved design for detection & actuation for stand-alone OCP clusters.
   1. How to detect a problem like an expired/lost key and no contact with the KMS provider?
   2. How to inform/notify the situation, even at node level, of the situation
2. GA after at least one stable KMS plugin provider
   • Cloud: (priority Azure > AWS > Google)
     • Azure KMS
     • Azure Dedicated HSM
     • AWS KMS
     • AWS CloudHSM
     • Google Cloud HSM

• • On-premise:
    • HashiCorp Vault (HashiCorp to add a new plugin)
    • EU FSI & EU Telco KMS/HSM top-2 providers.
    • Background, and strategic fit

We've had numerous customer requests for allowing external KMS integration to encrypt etcd. The existing etcd encryption mechanism is deemed insufficient for a couple reasons:

1) The encryption algorithm being used is static (and everybody has preferences).

2) The decryption keys are easily discoverable on self-hosted clusters.