Closed Bug 1562917 Opened 5 years ago Closed 5 years ago

Setup cloudfront for artifact distribution

Categories

(Taskcluster :: Services, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: brian, Assigned: brian)

References

Details

As covered in meetings and https://docs.google.com/document/d/1AaZpSuz5enFy3Zfc4eR7uKqB7FipNVoZv1wU4VxSI0Y/edit#heading=h.t7ygbjcnubsn , we want to use cloudfront for artifact distribution instead of S3 directly.

This bug covers writing terraform to setup the cloudfront distribution we'll use for distributing artifacts, as well as making any config changes that are needed in order for taskcluster services to generate links to artifacts via cloudfront.

Note that the cloudfront distribution must have a different origin from the rest of the Taskcluster deployment, since it can host user-generated HTML. We've been using taskcluster-artifacts.net for quite a while. I'm not sure how best to generate hostnames for new deployments.

Hi Dustin,

For the name we can use something like taskcluster-artifacts.services.mozilla.com or taskcluster-artifacts.cdn.mozilla.net.

Is PUBLIC_ARTIFACT_BUCKET the only bucket that needs to be behind a CDN?

What configuration will we need to set in taskcluster for it to generate URLs referencing the CDN?

Flags: needinfo?(dustin)

(In reply to Brian Pitts from comment #2)

For the name we can use something like taskcluster-artifacts.services.mozilla.com or taskcluster-artifacts.cdn.mozilla.net.

I don't think I'm expert enough at web security to know if that's OK. https://bugzilla.mozilla.org/show_bug.cgi?id=1427307 was the original sec issue on the topic, especially https://bugzilla.mozilla.org/show_bug.cgi?id=1427307#c4 explaining why a distinct domain is a good idea.

Is PUBLIC_ARTIFACT_BUCKET the only bucket that needs to be behind a CDN?

Yes

What configuration will we need to set in taskcluster for it to generate URLs referencing the CDN?

PUBLIC_ARTIFACT_BUCKET_CDN

The CDN config should be a straight pass-through. Note that many of the objects are quite large, so if the CDN does something silly like pass through all objects over 100k then that might need to be tweaked.

Flags: needinfo?(dustin)

Thanks. After review the security considerations it seems like we do need an entirely different domain. I'll see if we already have an domain that is used exclusively for user-controlled content, or if we have to get a new one or find a way to use subdomains of taskcluster-artifacts.net.

Dustin, your goal is to keep the existing taskcluster-artifacts URLs working, right?

What if we used two new subdomains of taskcluster-artifacts.net for the CDN for the two new taskclusters? On my end I don't know of any reason that couldn't work.

Where is DNS for this domain managed now? If it's in one of the cloud accounts that edunham and I have access to, we should be able to set things up.

Flags: needinfo?(dustin)

Dustin, your goal is to keep the existing taskcluster-artifacts URLs working, right?

Yes, they are likely hard-coded in 1000's of bugs, etc. Ideally they continue to work for a few months at least.

What if we used two new subdomains of taskcluster-artifacts.net for the CDN for the two new taskclusters? On my end I don't know of any reason that couldn't work.

That sounds good -- it's lumping like with like.

Where is DNS for this domain managed now? If it's in one of the cloud accounts that edunham and I have access to, we should be able to set things up.

It's in markmonitor, if that means anything to you. Our API to it is buzilla in Infra::DNS.

Flags: needinfo?(dustin)

It looks like DNS and certs for taskcluster-artifacts.net are actually managed by route 53 and ACM in your existing prod AWS account, which makes things simpler. Maybe MarkMonitor is the registrar?

Ah, that sounds correct. I'm a little unclear on what markmonitor and infoblox are, sorry :)

I'm overdue to update the state of this. The infra code is written and this is all configured for stage using the domain artifacts.tcstage.mozaws.net

Before doing prod I'll duplicate the existing taskcluster-artifacts.net DNS records in the new cloudops prod aws account and figure out how to make that authoritative.

Depends on: 1583556

In the mozilla-taskcluster account the NS record was set to

ns-1036.awsdns-01.org.
ns-1752.awsdns-27.co.uk.
ns-260.awsdns-32.com.
ns-535.awsdns-02.net.

In the new cloudops-taskcluster-aws-prod it is set to

ns-1054.awsdns-03.org.
ns-1714.awsdns-22.co.uk.
ns-527.awsdns-01.net.
ns-180.awsdns-22.com.

I have changed NS in the old account to match NS in the new account.

I have also requested IT to update markmonitor, which will update the NS record for taskcluster-artifacts.net on the DNS servers for the .net TLD.

No longer depends on: 1583556

DNS cutover worked, and afterwards I successfully set up dns+cert+cloudfront for https://community.taskcluster-artifacts.net/

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.