Support for non-Bearer Authorization header

[simonireilly]

Describe the feature you'd like to request

Currently, authorization for the remote cache is configured in the client.go to be Bearer based:

https://github.com/vercel/turborepo/blob/e5b6baabcbaed396de6d0d28118f3b02c4fdff0d/cli/internal/client/client.go#L107

This is preventing the use of AWS as a remote cache:

Authorization: AWS4-HMAC-SHA256 
Credential=xxxxxxxx/20211230/us-east-1/execute-api/aws4_request, 
SignedHeaders=host;x-amz-date;x-amz-security-token, 
Signature=xxxxxx

A solution to allow custom authentication headers would be ideal.

Benefits

Highly regulated orgs can't share source code as freely, plus due to security concerns of build logs and plain text env vars.

Describe the solution you'd like

Basic

--authorization flag would supersede the --token flag and set the entire header.

Potentially this would be a key-value pair, as the header and value may be different in different remote caching schemas.

npx run turbo --authorization 'X-API-Key: <value here>'

Signed requests

Some auth strategies such as AWS Sig v4 require signed requests which is a more involved process.

In this instance an adapter would be better, hence the option of a local proxy to perform header re-write with the request (dismissed below).

Native support would require a modular build that supports plugins for remote caches. This would maybe cause a requirement to expose internal API's e.g. the API client struct itself, or the cache struct for fully custom caches.

Describe alternatives you've considered

• Changing my remote caches auth, isn't an option for me
• A proxy could be used for auth, but that seems like a workaround
• Use Vercel free cache; unfortunately I can't share my source code.

[weyert]

Why would you want to directly talk to a cloud storage?

You have more flexibility through a proxy and you don't need to talk directly to AWS or similar cloud providers. That might be a security concern for some companies by itself. Also you can't really only support AWS, would require at a minimum of AWS S3, Cloud Storage, Azure Storage, Alibaba etc.

My understanding is that the idea is to write a spec of the remote cache backend API to allow people to implement their own. I think they are also working in allow to encrypt the cache items with your own keys.

[simonireilly]

Why would you want to directly talk to a cloud storage?

That's not what I am suggesting here. I am suggesting a custom authorization header. The AWS-ness of it is just my use case. I wouldn't be talking directly to an Object store either, but AWS IAM strategy means I can grant users, automated roles etc. access centrally.

You have more flexibility through a proxy and you don't need to talk directly to AWS or similar cloud providers. That might be a security concern for some companies by itself.

I am not sure I follow this one, most large orgs are using SSO, temp credentials, tokens that expire. I think setting up your own proxy is potentially insecure, since your authoring code you don't need to and implementing your own auth strategy for it.

Also you can't really only support AWS, would require at a minimum of AWS S3, Cloud Storage, Azure Storage, Alibaba etc.

Yeah, I agree, I think that's why I suggest either just letting the header be set, or a spec.

My understanding is that the idea is to write a spec of the remote cache backend API to allow people to implement their own. I think they are also working in allow to encrypt the cache items with your own keys.

That's great news, if this becomes a duplicate it can be closed :+1:

[weyert]

Yeah, I assume AWS IAM is something similar to Google IAP?

I have been using the OAuth device code flow to solve authentication issue for now. But yes, directly supporting Google IAP or AWS IAM is not possible. Guess, that would be nice.

I have been working on a little implementation of the server-side part, might be of interest to you: https://github.com/Tapico/tapico-turborepo-remote-cache

I hope to include the auth flow soon too, but struggling a bit with writing tests in Go at the moment :)

[dcherman]

@weyert Out of curiosity, why not support talking directly to Cloud Storage? By talking directly to it, you can use your existing method of authenticating against your cloud of choice rather than needing to support yet another service that needs authentication/authorization. I just implemented something similar to that by writing a proxy that runs locally with your own AWS credentials that talks directly to a specific S3 bucket - it was simple to implement and works great, but it would be nice to have support for that baked into Turborepo.

[anthonyshew]

Seeing little interest for this feature after nearly two years.

Being realistic, I'm not sure this is something that will get prioritized. If you feel strongly about this, please open a new issue so we can see if it garners interest.