Welcome @janisz!

It looks like this is your first PR to kubernetes/kubernetes 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/kubernetes has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Hi @janisz. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

/release-note-edit

The auth field in Docker config will be validated to be a valid UTF-8 string and will be rejected if not.

/ok-to-test

Adding sig node:

/sig node

/assign @sreeram-venkitesh

Since this may potentially break things, let's add a feature gate around it which is enabled by default. Please see the SystemdWatchdog as an example. After one release we can delete that feature gate. It is mostly to give a quick escape hatch for a single release so users can fix their configs or give us feedback.

@SergeyKanzhelev good point. I added feature gate

please fix linter by properly adding the feature gates everywhere it needs to be declared

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: janisz
Once this PR has been reviewed and has the lgtm label, please assign liggitt for approval. For more information see the Code Review Process.

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

/hold

Is this fixing a real or theoretical issue? A remote system that is vulnerable to non-utf8 characters presented in authentication headers by untrusted users doesn't seem like Kubernetes' issue to protect against. I'm not convinced restricting the character set of the password is a reasonable thing to do.

@liggitt Good point! I do not have any exploit for this so it's a theoretical issue although since all other strings that k8s operates on are UTF-8 (validated) this can cause problems (e.g. stackrox/stackrox#15270). HTTP does not specify encoding (https://stackoverflow.com/a/703341/1387612) so in theory it may work with any bytes but I guess in most cases it will be a configuration error not a planned behaviour.

We do not have a lot of places where the non UTF-8 string will be accepted by k8s. This seems to be one of the few places. I think it is not a big deal to limit this to avoid any possible issues with handling extra characters.

If we are not limiting the character set, I think it may be a good thing to test this end-to-end with some really nasty characters.

@janisz: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

PR needs rebase.