https://github.com/cockroachdb/cockroach/pull/70269 --- Release note (security update): The server.identity_map.configuration cluster setting allows a pg_ident.conf file to be uploaded to support dynamically remapping system identities (e.g.: Kerberos or X.509 principals) to database usernames. This supports use-cases where X.509 certificates must conform to organizational standards that mandate the use of Common Names that are not valid SQL usernames (e.g.: CN=carl@example.com => carl). Mapping rules that result in the root, node, or other reserved usernames will result in an error when the client attempts to connect. Release note (security update): The client_authentication_info structured log message provides a new "SystemIdentity" field with the client-provided system identity. The existing "User" field will be populated after any Host-Based Authentication rules have been selected and applied, which may include a system-identity to database-username mapping. Release note (security update): GSSAPI-based authentication can now use either the HBA "map" option or "include_realm=0" to map the incoming princpal to a database username. Existing configurations will operate unchanged, however operators are encouraged to migrate from "include_realm=0" to "map" to avoid ambiguity in deployments where multiple realms are present. Release note (security update): Incoming system identities are normalized to lower-case before they are evaluated against any active identity-mapping HBA configuration. For example, an incoming GSSAPI principal "carl@EXAMPLE.COM" would only be matched by rules such as "example carl@example.com carl" or "example /^(.*)@example.com$ %5C1".
Exalate commented:
https://github.com/cockroachdb/cockroach/pull/70269 --- Release note (security update): The server.identity_map.configuration cluster setting allows a pg_ident.conf file to be uploaded to support dynamically remapping system identities (e.g.: Kerberos or X.509 principals) to database usernames. This supports use-cases where X.509 certificates must conform to organizational standards that mandate the use of Common Names that are not valid SQL usernames (e.g.: CN=carl@example.com => carl). Mapping rules that result in the root, node, or other reserved usernames will result in an error when the client attempts to connect. Release note (security update): The client_authentication_info structured log message provides a new "SystemIdentity" field with the client-provided system identity. The existing "User" field will be populated after any Host-Based Authentication rules have been selected and applied, which may include a system-identity to database-username mapping. Release note (security update): GSSAPI-based authentication can now use either the HBA "map" option or "include_realm=0" to map the incoming princpal to a database username. Existing configurations will operate unchanged, however operators are encouraged to migrate from "include_realm=0" to "map" to avoid ambiguity in deployments where multiple realms are present. Release note (security update): Incoming system identities are normalized to lower-case before they are evaluated against any active identity-mapping HBA configuration. For example, an incoming GSSAPI principal "carl@EXAMPLE.COM" would only be matched by rules such as "example carl@example.com carl" or "example /^(.*)@example.com$ %5C1".
Jira Issue: DOC-1766