Generic worker cot

[escapewindow]

@petemoore , I am currently

• detecting generic worker by the existence of task.payload.osGroups or task.payload.mounts, and
• doing no checks about interactivity or docker image shas for generic worker. Are there some checks to make sure no one has RDPed or ssh'ed in?

Do those two things sound like valid tests for generic worker?

Once we have task.payload.features.chainOfTrust set in the build tasks and the pubkey for the level 3 windows build workerTypes in the cot repo, I think this will work.

[coveralls]

Coverage decreased (-0.2%) to 99.825% when pulling 029046b on escapewindow:generic-worker-cot into 32cb707 on mozilla-releng:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 9705b3c on escapewindow:generic-worker-cot into 32cb707 on mozilla-releng:master.

[petemoore]

Hi @escapewindow

Sorry for my delay in replying. Indeed, if mounts or osGroups payload property exist, it is fair to reason that this is a generic worker task payload. I fear that this could be something that changes (e.g. maybe mounts gets added to taskcluster-worker).

We don't currently have interactive support, although @grenade is working on this, so at some point soon we will. Machines that are loaned out will be terminated - but I guess an attack avenue might be to stop a machine from being terminated. However, @grenade can advise - I think secrets get wiped as part of the loan process, so it would be impossible for a worker to claim a new task after it has been loaned, I believe, even if the loaner was able to interfere with it and prevent it from being terminated. @grenade can confirm for sure.

The gecko windows machines don't have an ssh daemon (although other windows worker types, such as nss worker types do).

A question - if a task doesn't mount anything, and doesn't use osGroups feature - will these checks still work?

Also if there is anything I can do to make it less magic (like adding something in the cot certificate to make it clear it is generic worker) let me know.

Thanks!

[escapewindow]

Sorry for my delay in replying. Indeed, if mounts or osGroups payload property exist, it is fair to reason that this is a generic worker task payload. I fear that this could be something that changes (e.g. maybe mounts gets added to taskcluster-worker).

We'll have to modify scriptworker.cot.verify to support taskcluster-worker once it's ready, so we'll have to make changes then anyway. I do worry about how we'll detect taskcluster-worker and differentiate it from generic-worker via task definition alone, but we still have the ability to define that. Worst case, we can curate a set of known workerTypes.

We don't currently have interactive support, although @grenade is working on this, so at some point soon we will. Machines that are loaned out will be terminated - but I guess an attack avenue might be to stop a machine from being terminated. However, @grenade can advise - I think secrets get wiped as part of the loan process, so it would be impossible for a worker to claim a new task after it has been loaned, I believe, even if the loaner was able to interfere with it and prevent it from being terminated. @grenade can confirm for sure.

Terminating loaners and removing their secrets sounds like a good plan. In that case, they won't be able to validly sign the cot artifact, and we won't have to worry about otherwise verifying validly-signed tasks aren't run on loaners.

The gecko windows machines don't have an ssh daemon (although other windows worker types, such as nss worker types do).

Which will be turned off unless it's a loaner, yes?

A question - if a task doesn't mount anything, and doesn't use osGroups feature - will these checks still work?

It checks to see if osGroups is in the task definition. It can be an empty list. If generic-worker takes the task even if osGroups and mounts are not keys in the task definition, then it will cause problems, and we may have to move to the workerType solution sooner. Alternately, we could put a 'workerImpl': 'generic-worker' in the task definition somewhere, and the absence of that or any scriptworker-isms would imply taskcluster-worker.

Also if there is anything I can do to make it less magic (like adding something in the cot certificate to make it clear it is generic worker) let me know.

We use the worker implementation detection to determine which gpg homedir to use to validate the cot certificate, so it's a bit of a circular dependency. We could read the cot certificate twice, once ignoring signature to determine worker implementation, second to validate the signature... that may be another option alongside the workerType list.

[coveralls]

Coverage remained the same at 100.0% when pulling cbac162 on escapewindow:generic-worker-cot into 32cb707 on mozilla-releng:master.

[JohanLorenzo]

Supporting a new type of worker this way, looks good to me.

IIUC, generic-workers translates (for now) to windows machines, right?

[JohanLorenzo]

Supporting a new type of worker this way, looks good to me.
IIUC, generic-workers translates (for now) to windows machines, right?

Meh, Github was down, I couldn't see my first comment.

[escapewindow]

IIUC, generic-workers translates (for now) to windows machines, right?

I believe so, yes. Thanks for the super fast reviews!

[coveralls]

Coverage remained the same at 100.0% when pulling 4090cbf on escapewindow:generic-worker-cot into 32cb707 on mozilla-releng:master.

[petemoore]

IIUC, generic-workers translates (for now) to windows machines, right?

I believe so, yes. Thanks for the super fast reviews!

Update: we now have OS X tests running in generic worker in production.

[escapewindow]

Awesome! Tests don't currently factor into cot, and I don't think anything needs to change here even if hey did, so I think we're still good.

…

On Jun 19, 2017, at 04:14, Pete Moore ***@***.***> wrote: IIUC, generic-workers translates (for now) to windows machines, right? I believe so, yes. Thanks for the super fast reviews! Update: we now have OS X tests running in generic worker in production. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.