Can a kubernetes member verify that this patch is reasonable to test? If so, please reply with "@k8s-bot ok to test" on its own line.

Regular contributors should join the org to skip this step.

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

I signed it!

CLAs look good, thanks!

cc @kubernetes/sig-auth

I'm opposed to this change. Authenticators should always verify who they are speaking to. Plumbing through an option to allow a custom CA for verifying the keystone server's serving cert would be fine with me, but I think that bypassing it entirely is unreasonable.

Any flag like this that is added as a "never use this in production" will almost certainly be used in production and the barrier to adding your cert as a CA is relatively minor.

I'm opposed to this change. Authenticators should always verify who they are speaking to. Plumbing through an option to allow a custom CA for verifying the keystone server's serving cert would be fine with me, but I think that bypassing it entirely is unreasonable.

I agree.

if you'd like to rework this to pass in a custom CA bundle to use to verify the keystone server, I think that would be fine, but I don't see adding this option.

@liggitt I've already created another PR #35488 to enable passing a ca file to verify the keystone server.

closing in favor of #35488