[proposal] Bazel Credential Helpers

22 views
Skip to first unread message

Yannic Bonenberger

unread,
Jun 8, 2022, 3:56:20 PMJun 8
to baze...@googlegroups.com, bazel-discuss, chi...@google.com, pcl...@google.com, Will Martin
Hi all,

I’m proposing to add support for credential helpers to Bazel, an extensible mechanism for providing Bazel the credentials to connect to remote
servers. This will solve some of the pain points users have when fetching external repositories from private registries (e.g., http_archive
downloading from a private S3 bucket) or when connecting to a Remote Caching / Remote Execution cluster.

Please take a look.

Thanks,
Yannic

Tobias Werth

unread,
Jun 9, 2022, 1:53:50 AMJun 9
to Yannic Bonenberger, Tiago Quelhas, Xudong Yang, bazel-dev, bazel-discuss, Chi Wang, Yun Peng, Will Martin
--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/708A2F4F-4EDD-4B5F-B7C3-14A54DE02914%40yannic-bonenberger.com.

Tiago Quelhas

unread,
Jun 9, 2022, 9:48:41 AMJun 9
to Tobias Werth, Yannic Bonenberger, Xudong Yang, bazel-dev, bazel-discuss, Chi Wang, Yun Peng, Will Martin
Thanks for the proposal! I think this is a much-needed feature. Here are some thoughts:

- Is it enough to assume that the credentials are set through headers? For example, could a service expect credentials to be e.g. embedded in the URL? (I believe the proposed JSON reply format could be naturally extended to support it; my question is primarily whether such a need already exists today.)

- Should the design allow for providing multiple credential helpers to Bazel, so that users don’t have to write their own URL pattern matching? I can imagine two ways of doing this:
    - Bazel receives a list of helpers and queries each one in turn until it obtains a successful response (but this is potentially inefficient?)
    - Bazel receives a mapping from URL to helper. The key could potentially contain wildcards, so that e.g. a family of services service1.foo.com, ..., serviceN.foo.com sharing the same credentials would only require a single *.foo.com entry.

- The proposal should clarify what it means for a helper to "fail": does it return a nonzero exit code? What if the exit code is zero, but the response is empty - would that mean "no credentials are required"?

- Is a credential helper allowed to be user-interactive? For example, if a service requires a browser authentication flow or security key touch to obtain credentials, is it acceptable to trigger it from the helper? (I think this is potentially a bad idea, but I could be convinced.)

- The proposal probably should clarify the relative priority of --credentials_helper and other authentication flags that already exist in Bazel.

Tiago Quelhas

unread,
Jun 13, 2022, 7:48:36 AMJun 13
to Tobias Werth, Yannic Bonenberger, Xudong Yang, bazel-dev, bazel-discuss, Chi Wang, Yun Peng, Will Martin
On Thu, Jun 9, 2022 at 12:09 PM Tiago Quelhas <tj...@google.com> wrote:
Thanks for the proposal! I think this is a much-needed feature. Here are some thoughts:

- Is it enough to assume that the credentials are set through headers? For example, could a service expect credentials to be e.g. embedded in the URL? (I believe the proposed JSON reply format could be naturally extended to support it; my question is primarily whether such a need already exists today.)

Taking yet another step back: are HTTP headers the right level of abstraction for a credential helper's response?

The two other examples I could find of a credential helper protocol (Docker and Git) both describe a credential as a (url, username, secret) tuple. Is this model general enough?

Yannic Bonenberger

unread,
Jun 13, 2022, 3:58:13 PMJun 13
to Tiago Quelhas, Tobias Werth, Xudong Yang, bazel-dev, bazel-discuss, Chi Wang, Yun Peng, Will Martin
I believe that headers are the right level of abstractions. I know of cases where a custom header is used for auth (e.g., x-my-org-auth) or
where multiple headers are required.

I updated the proposal to include support for multiple helpers, and clarified the semantics of paths to helpers.

I’ll also clarify what it means if a helper fails. I’m leaning toward failing meaning exit code != 0 or producing an invalid stdout, and only accepting a
valid response with an empty array of headers as „no credentials needed“. I’m not planning to allow helpers to be interactive, but I could be
convinced otherwise.

Gunnar Wagenknecht

unread,
Jun 13, 2022, 4:19:26 PMJun 13
to Yannic Bonenberger, Tiago Quelhas, Tobias Werth, Xudong Yang, bazel-dev, bazel-discuss, Chi Wang, Yun Peng, Will Martin


On Jun 13, 2022, at 21:58, Yannic Bonenberger <yan...@yannic-bonenberger.com> wrote:
I’m not planning to allow helpers to be interactive, but I could be
convinced otherwise.

I don't think that's in your control. For example, git-credential-osxkeychain causes OS specific dialog to confirm access to Keychain. 

-Gunnar

Yannic Bonenberger

unread,
Jun 13, 2022, 5:49:07 PMJun 13
to Gunnar Wagenknecht, Tiago Quelhas, Tobias Werth, Xudong Yang, bazel-dev, bazel-discuss, Chi Wang, Yun Peng, Will Martin
Ok, let me clarify then: I’m not planning to allow helpers to interact with the user using stdin. If a helper really wants to require user-interaction,
I guess it can do that. For all I know, a helper might call an API and send a push notification to a phone and require user approval that way. We
can’t prevent that.

Thanks,
Yannic
Reply all
Reply to author
Forward
0 new messages