Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

release-24.1: ccl, cli,server, sql, testutils: fix IdMap setting + client cert auth #122738

Merged
merged 1 commit into from
Apr 22, 2024

Conversation

blathers-crl[bot]
Copy link

@blathers-crl blathers-crl bot commented Apr 20, 2024

Backport 1/1 commits from #120432 on behalf of @BabuSrithar.

/cc @cockroachdb/release


ccl, cli,server, sql, testutils: fix IdMap setting + client cert auth

This update fixes the logic for matching certificate names in the identity map.

In version 22.2, client certificate authentication combined with
auth-username-maps diverged from PostgreSQL's implementation. For instance,
PostgreSQL required the connection string
postgresql://db_user@localhost:26257?sslcert=certs/client.cert_user.crt&sslkey=certs/client.cert_user.key&sslmode=verify-full&sslrootcert=certs/ca.crt
for authentication with a certificate issued to CN=cert_user, whereas
CockroachDB 22.2 accepted
postgresql://cert_user@localhost:26257?sslcert=certs/client.cert_user.crt&sslkey=certs/client.cert_user.key&sslmode=verify-full&sslrootcert=certs/ca.crt
This discrepancy arose because CockroachDB previously did not check if the
client-provided username was a valid database user, leading to an automatic
overwrite with the mapped database user.

In version 23.1, an attempt to align with PostgreSQL's behavior was made by
verifying that the client-provided username matches at least one of the mappings
for the system identity inferred from the certificate, as detailed in PR
#94915. This introduced a backward incompatible change, requiring the
connection string to specify a valid database user while presenting a
certificate issued to CN=cert_user, like so:
postgresql://db_user@localhost:26257?sslcert=certs/client.cert_user.crt&sslkey=certs/client.cert_user.key&sslmode=verify-full&sslrootcert=certs/ca.crt
However, this approach failed because we did not correctly extract and use the
CN from the presented certificate as the system identity, preventing successful
authentication.

This commit resolves this issue by implementing the correct logic to extract the
CN from presented certificates and utilize it as the system identity, ensuring
the intended authentication flow works as expected.

Fixes #120034 , CRDB-36439

Release note (bug fix): Client Certificate Auth combined with identity
maps(server.identity_map.configuration) was broken in 23.1. This bug is fixed;
note that the feature to work correctly, the client must specify a valid db user
in connection string.


Release justification: the fix needs to go in for addressing bug related to the issue

This update fixes the logic for matching certificate names in the identity map.

In version 22.2, client certificate authentication combined with
auth-username-maps diverged from PostgreSQL's implementation. For instance,
PostgreSQL required the connection string
`postgresql://db_user@localhost:26257?sslcert=certs/client.cert_user.crt&sslkey=certs/client.cert_user.key&sslmode=verify-full&sslrootcert=certs/ca.crt`
for authentication with a certificate issued to CN=cert_user, whereas
CockroachDB 22.2 accepted
`postgresql://cert_user@localhost:26257?sslcert=certs/client.cert_user.crt&sslkey=certs/client.cert_user.key&sslmode=verify-full&sslrootcert=certs/ca.crt`
This discrepancy arose because CockroachDB previously did not check if the
client-provided username was a valid database user, leading to an automatic
overwrite with the mapped database user.

In version 23.1, an attempt to align with PostgreSQL's behavior was made by
verifying that the client-provided username matches at least one of the mappings
for the system identity inferred from the certificate, as detailed in PR
#94915. This introduced a backward incompatible change, requiring the
connection string to specify a valid database user while presenting a
certificate issued to CN=cert_user, like so:
`postgresql://db_user@localhost:26257?sslcert=certs/client.cert_user.crt&sslkey=certs/client.cert_user.key&sslmode=verify-full&sslrootcert=certs/ca.crt`
However, this approach failed because we did not correctly extract and use the
CN from the presented certificate as the system identity, preventing successful
authentication.

This commit resolves this issue by implementing the correct logic to extract the
CN from presented certificates and utilize it as the system identity, ensuring
the intended authentication flow works as expected.

Fixes #120034 , CRDB-36439

Release note (bug fix): Client Certificate Auth combined with identity
maps(server.identity_map.configuration) was broken in 23.1. This bug is fixed;
note that the feature to work correctly, the client must specify a valid db user
in connection string.
@blathers-crl blathers-crl bot requested review from a team as code owners April 20, 2024 07:47
@blathers-crl blathers-crl bot requested review from michae2 and removed request for a team April 20, 2024 07:47
@blathers-crl blathers-crl bot added blathers-backport This is a backport that Blathers created automatically. O-robot Originated from a bot. labels Apr 20, 2024
@blathers-crl blathers-crl bot requested review from DarrylWong and renatolabs and removed request for a team April 20, 2024 07:47
Copy link
Author

blathers-crl bot commented Apr 20, 2024

Thanks for opening a backport.

Please check the backport criteria before merging:

  • Backports should only be created for serious
    issues
    or test-only changes.
  • Backports should not break backwards-compatibility.
  • Backports should change as little code as possible.
  • Backports should not change on-disk formats or node communication protocols.
  • Backports should not add new functionality (except as defined
    here).
  • Backports must not add, edit, or otherwise modify cluster versions; or add version gates.
  • All backports must be reviewed by the owning areas TL and one additional
    TL. For more information as to how that review should be conducted, please consult the backport
    policy
    .
If your backport adds new functionality, please ensure that the following additional criteria are satisfied:
  • There is a high priority need for the functionality that cannot wait until the next release and is difficult to address in another way.
  • The new functionality is additive-only and only runs for clusters which have specifically “opted in” to it (e.g. by a cluster setting).
  • New code is protected by a conditional check that is trivial to verify and ensures that it only runs for opt-in clusters. State changes must be further protected such that nodes running old binaries will not be negatively impacted by the new state (with a mixed version test added).
  • The PM and TL on the team that owns the changed code have signed off that the change obeys the above rules.
  • Your backport must be accompanied by a post to the appropriate Slack
    channel (#db-backports-point-releases or #db-backports-XX-X-release) for awareness and discussion.

Also, please add a brief release justification to the body of your PR to justify this
backport.

@blathers-crl blathers-crl bot added the backport Label PR's that are backports to older release branches label Apr 20, 2024
@cockroach-teamcity
Copy link
Member

This change is Reviewable

@souravcrl souravcrl requested a review from bdarnell April 20, 2024 10:44
@souravcrl souravcrl merged commit 4702ea2 into release-24.1 Apr 22, 2024
19 of 20 checks passed
@souravcrl souravcrl deleted the blathers/backport-release-24.1-120432 branch April 22, 2024 14:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport Label PR's that are backports to older release branches blathers-backport This is a backport that Blathers created automatically. O-robot Originated from a bot.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants