[alessandro-verzicco]

Today, with TLS enabled, any client certificate signed by the configured CA is accepted. As described in #174 that is too broad when the CA is shared with other services (e.g. an internal CA issuing clientAuth certificates to everything).

This adds an optional allowlist of client identities:

• --tlsallowedclient <identity> (repeatable), and MGMT_API_TLS_ALLOWED_CLIENTS (comma-separated) in the Cassandra, Cassandra trunk and DSE images
• after the normal CA chain validation, the client certificate is accepted only if its subject CN or one of its DNS / URI / email / IP subject alternative names matches an allowed value
  • DNS names match case-insensitively, IP addresses in any notation (::1 == 0:0:0:0:0:0:0:1), CN / URI / email exactly
• the allowlist is applied on startup and on TLS hot reload, since both go through createSSLContext()
• when the option is not set, behaviour is unchanged (SslContextBuilder.trustManager(caFile) as before)

Implementation is a small X509ExtendedTrustManager (AllowedClientsTrustManager) that delegates chain validation to the JDK default trust manager built from the same CA file, then checks the identity.

In the entrypoints the identities are passed as separate quoted arguments rather than through MGMT_API_ARGS, so values with spaces (CN=Reaper Client) or glob characters are not split or expanded.

Testing

• NettyTlsClientAuthTest: allowed client accepted, CA-signed but not allowed client rejected, allowed CN with an untrusted chain rejected, and the allowlist applied through Cli (createSSLContext())
• AllowedClientsTrustManagerTest: matching rules (CN, multi-valued RDN, DNS case, IPv6 notation, URI/email, ignored SAN types) and rejection of a CA file without certificates

This change was developed with AI assistance (Claude Code); I reviewed and tested it, and the commit carries an Assisted-By trailer.

Fixes #174