docs: Add design doc for --initialize-secure #28482
Conversation
|
[REVIEW NOTIFICATION] This pull request has been approved by:
To complete the pull request process, please ask the reviewers in the list to review by filling The full list of commands accepted by this bot can be found here. Reviewer can indicate their review by submitting an approval review. |
ti-chi-bot
added
release-note-none
|
/run-check_dev_2 |
There was a problem hiding this comment.
Might be good to note that a socket connection is considered to be a "secure connection", just like TLS is. So if we use a random password instead we would also have to enable auto-tls and set REQUIRE SSL on the user to have the same security for the initial connection. If at any point we make caching_sha2_password the default instead of mysql_native_password this would require TLS as well. Using a UNIX socket allows us to get in to the server even if TLS isn't configured or if the TLS certificates are expired or are otherwise problematic.
| 2. Stale socket files are automatically cleaned up on server start [PR Merged](https://github.com/pingcap/tidb/pull/27886) | ||
| 3. TiDB listens on both TCP **and** unix socket by default [PR in Review](https://github.com/pingcap/tidb/pull/28486) | ||
|
|
||
| ## Test Design |
There was a problem hiding this comment.
If we use ubuntu instead of root we should verify if there are other things that might break because of this.
Might be good to test br, dumpling, lightning, etc to see if they allow UNIX socket connections (should not be a blocker, and likely already the case for MySQL support)
There was a problem hiding this comment.
Yes. Although in practice, this won't break if we modify tiup and Operator to use --initialize-insecure and generate a random password before we change the default bootstrap to secure (default change is not in scope yet for this proposal).
|
|
||
| The design choice of `auth_socket` is based on our current requirement of only supporting unix-like operating systems, and not needing to support Windows. This is a reasonable choice, as we do not expect to support Windows in the future. There might be some minor added complexity if we currently do not handle cases well such as the socket file already existing. | ||
|
|
||
| Adding the option `--initialize-secure` itself does not add risk, but enabling it by default will add risk as it is a difference in behavior. This design tries to minimize the risk, but it is a large change. There is a risk if we don't update all the documentation and communicate the change effectively, it will become a support issue for new users. |
There was a problem hiding this comment.
Yes, my concern is for the deployment of a new version of TiDB by the old version of the deployment tool(TiUP/TiOperator), the users may be surprised by the --initialize-secure mode and very difficult to access by auth socket in a pod(TiOperator).
For now, I prefer to set the default option as --initialize-insecure and change the default option after all old versions of TiUP/TiOperator are deprecated.
There was a problem hiding this comment.
I agree, and this is is what is intended: The default is --initialize-insecure to give installers time to transition. Once transitioned, the default can change to secure.
By adding both options, it supports the transition correctly because initially --initialize-insecure will be a noop, but will later mean something as the default changes.
There was a problem hiding this comment.
See also the above comment: default change is not in scope yet for this proposal.
ti-chi-bot
added
status/LGT2
|
/merge |
|
This pull request has been accepted and is ready to merge. Commit hash: dc3b0e6
|
ti-chi-bot
added
the
status/can-merge
|
@morgo: Your PR was out of date, I have automatically updated it for you. At the same time I will also trigger all tests for you: /run-all-tests If the CI test fails, you just re-trigger the test that failed and the bot will merge the PR for you after the CI passes. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository. |
|
|
||
| ## Impacts & Risks | ||
|
|
||
| The design choice of `auth_socket` is based on our current requirement of only supporting unix-like operating systems, and not needing to support Windows. This is a reasonable choice, as we do not expect to support Windows in the future. There might be some minor added complexity if we currently do not handle cases well such as the socket file already existing. |
There was a problem hiding this comment.
How about if we consider the Windows OS?
What problem does this PR solve?
Issue Number: #28481
Problem Summary:
This adds a proposal for a secure bootstrap.
Check List
Tests
Side effects
Documentation
Release note