### Services for docker-worker

Use-cases:

• A) tasks wants some service booted to test against
  • postgres
  • mysql
  • redis
  • rabbitmq
  • bugzilla
  • taskcluster-queue
  • skye is the limit
• B) tasks wants some authentication proxies
  • releng api proxy
  • vpn proxy
  • balrog proxy
  • upload symbols
  • anything we want to auth for...
    
    
    
    

### Delegation of Scopes
To facilicate (B) without putting secrets into the images,
I propose the following:
All workers are given the scope:
  assume:docker-service-image:<provisionerId>/<workerType>/*
When ever they start a service they setup an auth-proxy for the
service and tells the auth-proxy to delegate the following scope:
assume:docker-service-image:<provisionerId>/<workerType>/<imageId>
  , where <imageId> is the docker image identifier or hash maybe?

On auth.taskcluster.net the scope:
assume:docker-service-image:<provisionerId>/<workerType>/<imageId>
implies membership of the role identified as:
  "docker-service-image:<provisionerId>/<workerType>/<imageId>"
Hence, we can create a trusted service image and define a role with
scopes that we entrust this image with.
(note, auth doesn't have roles yet)

Notice:
 - The role + docker-worker delegates scopes to the service image.
 - The service image is public, but guards access to the resource.
 - The services image can see task.scopes, so it can decide if
   you have the scope required to use it (in case of auth-proxies)

### Payload Format

task.payload = {
  ... // the usual
  services: [
    {
      name:    'my-service-alias',
      image:   'my-image'
      command: ['my-command'],
      env: {
        MYVAR: 'my value'
      },
      // maybe later we add support for:
      // - logs
      // - devices
      // - cache folders
      // - artifacts (from services)
      // Note, sure we should support these.
    }
  ]
}


### At Run-Time
When running the payload format above, we'll create a container
running my-image with 'my-command', this container will be linked
to an auth-proxy delegating the scope:
  assume:docker-service-image:<provisionerId>/<workerType>/my-image
The container will also be linked into the task container with
the alias 'my-service-alias'.

Note, services can specify an ENTRYPOINT which "command" won't
overwrite. So if the service is an auth-proxy it should just
assume command/env are untrusted and ignore them or use them as
untrusted settings.

### Clean-up
Service containers are killed once the task is done.
Probably without delay.