search

taskcluster / taskcluster-rfcs

Taskcluster team planning
Mozilla Public License 2.0
11 stars 19 forks source link

RFC: Worker Machine Image Building Automation #164

Closed petemoore closed 3 years ago

petemoore commented 4 years ago

I consider this ready for review now.

There is still one open point for me, which is I haven't quite yet worked out if /config/imagesets.yml should be updated by automation or not, as we would then get a flurry of commits by automation every time a new image set is built. Not decided if this is a good or bad thing. An alternative might be to publish the data somewhere, but not commit back to source code. I'm not sure that is a great idea either, so at the moment tending to thinking explicit commit by automation is best.

sciurus commented 3 years ago

For config updates, we already have a process for doing this in an automated fashion for firefox-ci-tc. I suspect it makes more sense to leverage this than to build something new for community-tc.

petemoore commented 3 years ago

For config updates, we already have a process for doing this in an automated fashion for firefox-ci-tc. I suspect it makes more sense to leverage this than to build something new for community-tc.

@sciurus That's great - do you know if there are any docs that describe the process? Thanks!

sciurus commented 3 years ago

@sciurus That's great - do you know if there are any docs that describe the process? Thanks!

Not great ones. I threw together https://github.com/mozilla-services/cloudops-docs/blob/master/Services/Taskcluster/CI%20Admin.md and am happy to answer questions.

petemoore commented 3 years ago

As a general comment, this seems to take a great deal of care to generate CoT keys. Does anything in the community cluster use CoT (aside from this process itself)? I believe the answer is "no". If that's the case, could we just disable CoT on the worker images, and not worry about generating keys?

@djmitche So I think Chain of Trust is a generally useful feature in the worker, but I think it has an unfortunate name, since it makes it sound like it is only relevant for the mozilla firefox CI chain of trust validation process. However, it is simply an artifact signing feature, that provides a guarantee that the artifacts that were posted against a given task were signed by a key that was on the worker itself. It would be reasonable for all tasks to always have the feature enabled, as it costs very list and offers protection against taskcluster credential breaches (it isn't possible to obtain the signing keys via a taskcluster credential breach, the signing key would also need to be breached).

Perhaps we should rename the feature to signedArtifacts instead. I certainly feel like it is a useful security feature in any production deployment of taskcluster.

I'll respond to the other points tomorrow - many thanks!

escapewindow commented 3 years ago

We could retitle #158 to something like obsolete chain of trust keys and simplify maintenance and deployment :)

petemoore commented 3 years ago

Closing for now as I'm not actively working on it.