This can be used by tasks that need accessed to private bits (such as flame builds that are indexed). In the case of a signed url for a private flame build, this can be passed to Testdroid to use for flashing devices without the need to pass credentials.

I suggest as an alternative that docker-worker injects the following environment variables: - TASKCLUSTER_CLIENT_ID - TASKCLUSTER_ACCESS_TOKEN - TASKCLUSTER_CERTIFICATE Set them to a set of temporary credentials generated for the task, that uses task.scopes as scope, and expires at task.deadline. Notice, that generation of temporary credentials only requires a few HMAC operations. No network, so it's really fast, practically no overhead. Hence, it doesn't matter if most tasks chooses to ignore these temporary credentials.

yea, Jonas and I were speaking about this and it seems like a much easier approach than adding another thing to the proxy. Ideally creds would expire at or before the max run time of the task. Perhaps this bug could be changed to allow docker-worker to create temp creds based on the task scopes, and expires at task maxruntime. Would we want to have something explicit in the task for requesting temp creds to be available or all tasks get them?

Hmm, we can probably put temp TC creds injection under a feature flag.. Like we do with proxy, logs, etc. Then we can always decide if we want to enable the flag by default... Note, this way the docs for this feature can live in the json schema for the feature flag...

After sitting on this for a little bit and enjoying interacting with some other APIs that I can just curl, I am really leaning towards having this still handled by the proxy and not have docker worker worry about it. There might be the case where docker-worker issuing temp creds is a good thing, but I'm not sure it's necessary right now. Considering how simple something like this could be implemented into the proxy, it makes sense just to do that. Perhaps when there are more immediate usecases for needing credentials within a task container, it would make more sense, but for now it really seems we just need to get task/artifact info. It's also really nice to think about the idea of just curling an endpoint, piping json response to jq or similar within a bash script rather than using the client.

Comment on attachment 8565748 [details] https://github.com/taskcluster/taskcluster-proxy/pull/2 Works like I would expect it to. I was able to curl the bewit endpoint and get a signed URL that then redirected to the proper signed s3 url. Thanks!

Resetting Version and Target Milestone that accidentally got changed...