Description of problem:

The spec.configuration.apiServer.encryption field in the HostedCluster CR is non-functional and misleading. Despite specifying the encryption type under this field, it has no impact on the cluster's behavior. Instead, only the spec.secretEncryption field is respected. This creates a UX issue and confusion for users.

When defining a HostedCluster CR, setting the following fields under spec.configuration.apiServer.encryption appears to be allowed by the API schema, but has no actual effect on the encryption configuration of the hosted control plane:

spec:
  configuration:
    apiServer:
      audit:
        profile: Default
      encryption:
        type: aescbc  # This has no effect

At the same time, the following configuration under spec.secretEncryption does work and is required for the actual encryption setup:
 

spec:
  secretEncryption:
    aescbc:
      activeKey:
        name: dpateriy-hcp-etcd-encryption-key
    type: aescbc

This disconnect results in user confusion, as spec.configuration.apiServer.encryption is misleadingly suggestive of functionality that is not implemented. It is confirmed via engineering Slack discussions that this field is a no-op.
Expected Behavior:

• spec.configuration.apiServer.encryption should be removed or marked deprecated in the CRD

Actual Behavior:
The field is silently ignored, while the user expects it to work based on its presence in the API.

Impact:

• User confusion

• Wasted troubleshooting time

• Potential misconfigurations due to assuming encryption is enabled when it's not