tree 0859fd7922f3e446bbc1588ddd165b53577d8055
parent 7fe4e8e45db7bea1565d6082a9df8c46999d8b5d
author Ulf Adams <ulf@engflow.com> 1585688575 -0700
committer Copybara-Service <copybara-worker@google.com> 1585688642 -0700

Implement mutual TLS authentication

Add a pair of flags tls_client_certificate / tls_client_key to specify a
certificate and corresponding key, which allow Bazel to authenticate itself
over TLS to a remote cache or remote executor.

Before this change, Bazel only supports Google Cloud authentication, which
requires an open network connection to Google Cloud on the client as well as
on the server.

I have heard from one user that they are tunneling their traffic over a VPN
and then perform no client authentication in their remote caching system. I
heard from another user that they have locally patched Bazel to enable mTLS
(but have not upstreamed the patch). Finally, there is also a pending
feature request.

Compared to other authentication mechanisms, mTLS is already supported by
gRPC out of the box.

I added test coverage by also adding a --tls_ca_certificate to the local
remote worker, and updating the existing TLS test to also run with an mTLS
configuration.

I had to generate a new ca cert/key pair in order to sign a new client
certificate (and also re-generate the server cert/key pair); these are
checked in as testdata. Note that the generator script given there already
supports generating both server and client cert/key pairs, so no change to
the documentation was necessary.

Fixes #10735.

Change-Id: I8c9fdab11d172a4cc8a2b80de43faa48086cc893

Closes #11030.

Change-Id: I8c9fdab11d172a4cc8a2b80de43faa48086cc893
NOKEYCHECK=True
PiperOrigin-RevId: 304041337