With more jobs moving to TC, and being scheduled in tree, it will be important (very soon) to have the ability to pass secrets to workers. There are several ad-hoc solutions in place for jobs scheduled outside of the tree, but a centralized service is more appropriate for things like Android/Desktop FF builds/tests. Relevant IRC Conversation Summary: 5:11 PM <garndt> dustin: tldr; we need secrets in tasks and doing so by in-tree tasks is not possible currently 5:11 PM <dustin> I had been thinking that relengapi access, in particular, would do well with a proxy container 5:12 PM <dustin> since the proxy could learn what relengapi-specific scopes the task has, and generate a token (which it adds to the request in the process of proxying) with only those permissions 5:14 PM <garndt> yea, proxies are definitely a doable thing now, we would just write another proxy as a docker-worker "feature" 5:16 PM <garndt> so I think there are 3-4 ideas so far... 1) secret docker volume container mounted into task container 2) relengapi proxy feature for docker-worker 3) encrypt in-tree file with worke rpublic key similar to how travis does encrypted env variables, `mach taskcluster-graph` can do the magic to insert some path to that file int he task def that the worker knows 5:16 PM <garndt> to decrypt and add to the task container. 4) secret git repo that is added to the base ami and then some how mount it into the task container based on scopes 5) centralized secrets manager (we are going to be doing something like this for our workers for its own things

Heroku does something very easy with regards to keeping secrets in environment variables. I don't know how it works or if it would made sense but I wish that defining secrets would be very very easy rather than having to know what scopes are and set up tokens and other similar concepts.

Heroku and TaskCluster are solving different issues, though -- we need secrets injected into jobs based exclusively on public information. For example, when I make a try push, that push needs to be able to authenticate to tooltool in order to download Android bits. Scopes are the appropriate model (and users shouldn't be handling tokens of any sort directly). Just a matter of figuring out how best to map scopes to secrets.

I definitely favor proxy solutions, they are very elegant with docker. Assuming relengapi already has scopes, you can just prefix them like "releng-api:<existing-scope>", or something like that. But proxy solutions aren't very generic, and will never cover random cases. For this we have encrypted env vars, which aren't great as they never expire. So gandt encouraged me to open bug 1168534 to discuss a secret key/value store. I've previously encouraged pmoore and jhford to prototype something like this, not sure what exists. I'm not sure how much this would solve, as it just makes it the responsibility of the task creator to upload the secrets to the secret key/value store. Anyways, it's a more generic solution. (Note, I still strongly encourage proxies for any remotely common use-case).

In many cases the task creator (in the sense of "the human initiating the task") should not have the secrets. So at least for tasks triggered from version-control commits, the decision task will have to authenticate and add the necessary secrets.