Add verify_server_hostname to tls.defaults

[blmhemu]

Feature Description

When configuring consul, it is not immediately obvious that we need to fiddle with verify_server_hostname which is present only under tls.internal_rpc. Adding it to tls.defaults makes all the verify_* config be grouped in the defaults section.

Use Case(s)

Ease of use / config / discoverability.

[huikang]

@blmhemu , thanks reporting this. I think the proposal makes sense, given other verify_* can override the values in tls.defaults

But I will leave this to our PM to decide @jkirschner-hashicorp

[jkirschner-hashicorp]

@huikang : I agree this change would simplify the UX.

Currently, the standard configuration looks something like this:

tls {
  defaults {
    key_file = "/etc/pki/tls/private/my.key"
    cert_file = "/etc/pki/tls/certs/my.crt"
    ca_file = "/etc/pki/tls/certs/ca-bundle.crt"
    verify_incoming = true
    verify_outgoing = true
  }

  internal_rpc {
    verify_server_hostname = true
  }
}

With the change, there would be no need for the internal_rpc stanza:

tls {
  defaults {
    key_file = "/etc/pki/tls/private/my.key"
    cert_file = "/etc/pki/tls/certs/my.crt"
    ca_file = "/etc/pki/tls/certs/ca-bundle.crt"
    verify_incoming = true
    verify_outgoing = true
    verify_server_hostname = true
  }
}

One could argue that it's strange to set a default that only applies to one interface (internal RPC) rather than all 3 (internal RPC, gRPC, HTTPS). However, we already have precedence for defaults that only apply to a subset of the interfaces: verify_outgoing is seemingly not used in gRPC, but can still be set in tls.defaults.

[fulviodenza]

I think the change makes sense, if needed I can work on it.
@jkirschner-hashicorp @huikang

[david-yu]

The #17155 PR was merged and is scheduled to be released in 1.17.0

[david-yu]

Will go ahead and close this issue. Thanks @fulviodenza for the PR!