An issue was recently observed where an HCP tenant cluster's worker nodes were unable to self-register at startup because their CSRs were not getting approved. 

The approval for these certificates was failing because the hostname they were assigned was in the form of `<EC2 resource name>.ec2.internal` instead of `<EC2 IP name>.ec2.internal` (ie - `i-123456asdf.ec2.internal` instead of `ip-xxx-xxx-xxx-xxx.ec2.internal`). 

The reason these nodes were assigned a resource name hostname type is because the setting `Hostname Type: Resource name` was set at the subnet-level, rather than the typical `Hostname Type: IP name` MC components expect.

AWS documentation (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/hostname-types.html#instance-naming-modify) indicates this subnet-level config is a default only, which implies that it can be overridden at/following creation-time. In order to improve reliability of the product, we should ensure this field is explicitly set to `IP name` on HCP-owned instances, which has been observed to be required for HyperShift to approve nodes' certificates. 
    

Observed in 4.16.z, likely present in all HCP versions
    

Likely very
    

    1. Create a subnet with {{Hostname Type: Resource Name}}
    2. Provision an HCP cluster using this subnet
    3. Workers created in this subnet should be assigned a hostname matching the pattern {{i-somevalue.ec2.internal}}, which will prevent the control-plane from issuing certificates for these nodes
    

Worker nodes' certificates are not approved, preventing HCP from being usable in subnets that define a `Hostname Type` that is not `IP name`.
    

HCP should be able to provision machines in subnets whose default `Hostname Type` is not `IP name` by explicitly setting this on EC2 instances during/shortly after creation