Closed Bug 1172273 Opened 8 years ago Closed 5 years ago

generic-worker (windows): RDP into task users

Categories

(Taskcluster :: Workers, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jonasfj, Assigned: pmoore)

References

(Blocks 1 open bug)

Details

(Whiteboard: [generic-worker])

Attachments

(1 file)

Since the generic-worker creates a user for each task.
We could allow that user to connect via. RDP, I suspect we already do this:
https://github.com/taskcluster/generic-worker/blob/master/plat_windows.go#L67
(I think I've heard that some tests use RDP to get a desktop session).

Anyways, if the generic-worker was to export an artifact called:
  private/mozilla/rdp-info.json
  {
    host: "...",
    port: 3389,
    username: "task_....",
    password: "pWd0_....",
    url: "rdp://<username>:<password>@<host>:<port>"
  }

Then developers could RDP into the worker as the reduced privileged
user created for the specific task.
Obviously, we shouldn't do this for all tasks, it should probably require
two things:
 1) An artifact name for the `rdp-info.json` file, specified like:
      task.payload.rdpInfo = "private/mozilla/rdp-info.json"
 2) task.scopes contains a pattern granting the scope
     "generic-worker:allow-rdp:<provisionerId>/<workerType>"

We could then tweak try-flag parsing logic to make --interactive, set:
  task.payload.rdpInfo = "private/mozilla/branch/try/rdp-info.json"
  task.scopes = ["generic-worker:allow-rdp:<provisionerId>/<workerType>"]

This way only people with the scope:
  "queue:get-artifact:private/mozilla/branch/try/rdp-info.json"
Can download the rdp-info.json file.
Note: All artifacts that isn't prefixed, "public/" requires the scope:
  "queue:get-artifact:<artifact-name>"


By specifying the artifact name for rdp-info.json in task.payload.rdpInfo,
we can make tasks where some people can't RDP in.

All we would need to do on the generic-worker is:
 A) Create rdp-info.json file if conditions (1) and (2) are met
 B) After task run, wait for all remote RDP connections to disconnect
    before killing all processes under the task-specific user and cleaning
    up after the task (deleting home-dir, clearing registry).
     - Probably have a timeout in case people forget to disconnect RDP (or bugs)
     - Make sure it ignore local RDP connections as some tests probably
       creates local RDP connections to get a desktop session.

We probably want logs and artifact export before this.
But I think this would be a quick hack and very powerful hack.
Assigning all generic worker bugs to myself for now. If anyone wants to take this bug, feel free to add a comment to request it. I can provide context.
Assignee: nobody → pmoore
Blocks: tc-2015-q3
Summary: generic-worker (windows): RDP into task users → meta: [pmoore-Q3/2015-goal] generic-worker (windows): RDP into task users
Component: TaskCluster → Generic-Worker
Product: Testing → Taskcluster
No longer blocks: tc-2015-q3
Summary: meta: [pmoore-Q3/2015-goal] generic-worker (windows): RDP into task users → meta: [pmoore-Q4/2015-goal] generic-worker (windows): RDP into task users
Blocks: tc-2015-q4
Component: Generic-Worker → Worker
Whiteboard: [generic-worker]
Component: Worker → Generic-Worker
(In reply to Jonas Finnemann Jensen (:jonasfj) from comment #0)
> Since the generic-worker creates a user for each task.
> We could allow that user to connect via. RDP, I suspect we already do this:
> https://github.com/taskcluster/generic-worker/blob/master/plat_windows.go#L67

For posterity, the link above referred to:
https://github.com/taskcluster/generic-worker/blob/f22200609166032b43189b38a70e6aa935993174/plat_windows.go#L67
Summary: meta: [pmoore-Q4/2015-goal] generic-worker (windows): RDP into task users → generic-worker (windows): RDP into task users
This is initially a trivial implementation, that keeps task alive for 12 hours after completing, in order to unblock https://bugzilla.mozilla.org/show_bug.cgi?id=1399401#c65 - I'll make this a bit more solid later to check for an active RDP connection etc.
Blocks: 1399401
In the process of working on this, I hit issues with worker types being subtly different, which went unnoticed due to bug 1431750, so I am currently resolving that bug first to avoid that problem happening again.
This is all working now - will release in the morning.
Released in generic-worker 10.5.0.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Component: Generic-Worker → Workers
You need to log in before you can comment on or make changes to this bug.