sql,security: gate session revival behind a cluster setting#75660
sql,security: gate session revival behind a cluster setting#75660craig[bot] merged 1 commit intocockroachdb:masterfrom
Conversation
|
This change is |
|
To reviewers: let's use this PR to discuss the correct way to gate this functionality. At the time of writing this comment, the |
jaylim-crl
left a comment
There was a problem hiding this comment.
If I understand correctly, this cluster setting will be on the host cluster right? Does that also mean the host could use this revival token? And if that's true, is there a way to only restrict it to tenants?
Reviewable status:
complete! 0 of 0 LGTMs obtained (waiting on @jeffswenson and @knz)
rafiss
left a comment
There was a problem hiding this comment.
The host cluster won't have the certs, so it won't be able to use tokens. But that's not a very explicit guard, so yes, I should be able to change this to disallow it on host clusters always.
Reviewable status:
|
What is the timeline to support tenant-read-only settings? (Whatever the outcome of the discussion is, the new feature gate should be kept coherent with the one used to support |
I'd say in a few weeks, end of Feb at the latest. |
|
From the standpoint of CC automation, gating this with an environment variable or a tenant read-only setting is equally convenient. |
4b1c30a to
44018bb
Compare
Stop allowing any multitenant cluster from using this functionality. Release note (security update): The cluster setting server.user_login.session_revival_token.enabled has been added. It is false by default. If it is set to true, then a new token-based authentication mechanism is enabled. A token can be generated using the crdb_internal.create_session_revival_token builtin function. The token has a lifetime of 10 minutes and is cryptographically signed to prevent spoofing and brute-forcing attempts. When initializing a session later, the token can be presented in a pgwire StartupMessage with a parameter name of `crdb:session_revival_token_base64`, with the value encoded in base64. If this parameter is present, all other authentication checks are disabled, and if the token is valid and has a valid signature, the user who originally generated the token authenticates into a new SQL session. If the token is not valid, then authentication fails. The token does not have "use-once" semantics, so the same token can be used any number of times to create multiple new SQL sessions within the 10 minute lifetime of the token. As such, the token should be treated as highly sensitive cryptographic information. This feature is meant to be used by multitenant deployments to move a SQL session from one node to another. It requires the presence of a valid Ed25519 keypair in tenant-signing.<tenant_id>.crt and tenant-signing.<tenant_id>.key.
44018bb to
02a0943
Compare
|
ok, this is ready for review -- let's merge it like this with the TenantWriteable setting, and once @RaduBerinde + @ajstorm complete the work for TenantReadOnly settings, we can change it at that point. |
jeffswenson
left a comment
There was a problem hiding this comment.
LGTM!
With the caveat I expect the setting to use TenantReadOnly as soon as the option is available.
|
tftr! bors r=JeffSwenson,otan |
|
Build failed (retrying...): |
|
Build succeeded: |
fixes #74643
Stop allowing any multitenant cluster from using this functionality.
Release note (security update): The cluster setting
server.user_login.session_revival_token.enabled has been added. It is
false by default. If it is set to true, then a new
token-based authentication mechanism is enabled. A token can be
generated using the crdb_internal.create_session_revival_token builtin
function. The token has a lifetime of 10 minutes and is
cryptographically signed to prevent spoofing and brute-forcing attempts.
When initializing a session later, the token can be presented in a
pgwire StartupMessage with a parameter name of
crdb:session_revival_token_base64, with the value encoded in base64.If this parameter is present, all other authentication checks are
disabled, and if the token is valid and has a valid signature, the user
who originally generated the token authenticates into a new SQL
session. If the token is not valid, then authentication fails.
The token does not have "use-once" semantics, so the same token can be
used any number of times to create multiple new SQL sessions within the
10 minute lifetime of the token. As such, the token should be treated as
highly sensitive cryptographic information.
This feature is meant to be used by multitenant deployments to move a
SQL session from one node to another. It requires the presence of a
valid Ed25519 keypair in tenant-signing.<tenant_id>.crt and
tenant-signing.<tenant_id>.key.