[proposal] Bazel Credential Helpers

[Yannic Bonenberger]

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]

+Tiago Quelhas +Chi Wang +Xudong Yang 

--
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]

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]

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]

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]

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. 

https://stackoverflow.com/questions/68868084/git-credential-osxkeychain-wants-to-access-key-github-com-in-your-keychain

-Gunnar

[Yannic Bonenberger]

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

[Xudong Yang]

The proposal looks good to me. Thanks for writing it up!

[Tiago Quelhas]

The proposal LGTM in its current state.

A few points raised during review suggest we might need to expand the design in the future, but I'd rather start with something minimal. The proposed protocol is sufficiently extensible for me to believe that we're not painting ourselves into an uncomfortable corner.

--
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/70331cb8-42d9-48a2-807b-cbbc83436defn%40googlegroups.com.