1156404 - auth: Configure scopes given to temporary credentials (discussion)

Status: RESOLVED FIXED

(Taskcluster :: General, defect)

Description

[Jonas Finnemann Jensen (:jonasfj)]

In bug 1137740 scopes issued to temporary credentials was made configurable.

See the "temporary-credentials" client on:
https://tools.taskcluster.net/auth/

So now we just need to change its scrops from "*" to something else.
I propose:
  queue:*
  index:*
  provisioner:*
  assume:*
  scheduler:*

We can always make it stricter?
If anyone wants to sit down and design something more elaborate that would be greatly appreciated.

At the moment I would be happy just remove "auth:*" which this would achieve.

@rail, what scopes you do want to restrict?
@jlal, did you ever decide what scopes to issues/restrict?

Ideally, we should knock scopes issued down to the absolute minimum.
And then just extend the scopes allowed whenever someone ask for it.
I'm not sure anyone is actually using temporary credentials for anything,
so maybe it's not an issues to just restrict to the default workerType
defined in task-creator...

Thoughts?

Comment 1

[Rail Aliiev [:rail]]

The list of scopes looks sane to me.

Comment 2

[James Lal [:lightsofapollo]]

looks like a good start...

Comment 3

[Jonas Finnemann Jensen (:jonasfj)]

Temporary credentials are now issued with the following scopes:
  queue:*
  index:*
  aws-provisioner:*
  assume:*
  scheduler:*
  auth:azure-table-access:taskclusterdev/*

I suggest that we restrict these further over time. But for now temporary creds issued by auth.tc.net
cannot be used to view/add/modify client credentials and scopes anymore.

I'm resolving this bug. As temporary credentials are no longer issued with "*" scope.

---

@rail, if you do signing in a task, you should be able to specify an ENTRYPOINT for the docker container, that can't be overwritten by task.payload.command. In this entrypoint you can then very that the current task has a given scope before you proceed to download and/or sign anything.
Hence, if task doesn't have the required scope (which you can just make up), the task exists non-zero before running any untrusted code.
Checking if task.scopes has a scope like: "release-on-rails-signing" would totally work :)

Remark, above pattern is open to docker layer cache poisoning attacks. But this could be mitigated by using a trusted workerType, which is probably what you should do for anything release related.

Comment 4

[Pete Moore [:pmoore][:pete]]

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