docs: Add design doc for --initialize-secure

[morgo]

What problem does this PR solve?

Issue Number: #28481

Problem Summary:

This adds a proposal for a secure bootstrap.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

None

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• bb7133
• dveeden

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

The full list of commands accepted by this bot can be found here.

Reviewer can indicate their review by submitting an approval review.
Reviewer can cancel approval by submitting a request changes review.

[morgo]

/run-check_dev_2

[dveeden]

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.

[dveeden]

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)

[morgo]

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).

[bb7133]

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.

[morgo]

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.

[morgo]

See also the above comment: default change is not in scope yet for this proposal.

[bb7133]

Got it, thank you!

[bb7133]

LGTM

[bb7133]

/merge

[ti-chi-bot]

This pull request has been accepted and is ready to merge.

Commit hash: dc3b0e6

[ti-chi-bot]

@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.

[zhangjinpeng87]

How about if we consider the Windows OS?