Setup HTTPS on the frontend

[tomwilkie]

• make it work in local/dev too (self-signed, probably)
• buy some certificates for scope.weave.works
• update the react app to use ssl
• deploy it to prod

Edit:

• make scope probe support wss:// and redirections (for instance, revert weaveworks/scope@d57d4aa)

[paulbellamy]

Slightly blocked on how new deployment works

[paulbellamy]

We can redirect-to-ssl on all urls except POST /app/report, because the probe won't follow redirects.

Current thinking is there are three options for loading the certs:

1. compile the certs into the frontend image: means we need a separate image for each env
2. have a cert-container and do volumes-from: means we have to colocate containers
3. have the certs on the host, and mount them from there: means we have the certs sitting on every host

[tomwilkie]

3. have the certs on the host, and mount them from there: means we have the certs sitting on every host

We currently deploy the frontend on every host, so this is pretty much equivalent.

1. compile the certs into the frontend image: means we need a separate image for each env

Do we only need SSL on the prod image? In which case, we could get away with only having one image (the prod one), and have ssl just-not-work in other environments.

[paulbellamy]

Having thought about it, I prefer 3, as it means the certs only have to be setup and handled once (when the infra is created), but mean we will have to recreate all the infrastructure to deploy it. vs 1, where they have to be handled every time you want to make a new frontend image.

Edit: Upon reflection, I've decided for option 1. To just check in the prod certs, and compile them into the image. It will be incorrect hostname in dev/local, but it always would be anyway.

[paulbellamy]

We will not be able to use Strict-Transport-Security yet, until the scope client supports secure websockets.

Edit: And furthermore Chrome (and possibly others) block the insecure websocket when the page was loaded via https, so we can't do this at all until scope is fixed.

[paulbellamy]

And, even when scope is fixed we have no way to upgrade the scope-app-* nodes to 0.9 to support this. This is blocked on #202

[2opremio]

1. compile the certs into the frontend image: means we need a separate image for each env
2. have a cert-container and do volumes-from: means we have to colocate containers
3. have the certs on the host, and mount them from there: means we have the certs sitting on every host

With kubernetes we have
4) Use a k8s secret

which I think is what we should go for.

@paulbellamy I vaguely recall discussions with jim about buying certificates for scope.weave.works. Did this happen?

[paulbellamy]

Nope. Hasn't happened yet, as you'll have to fiddle with DNS (or do a deploy) to prove you own the domain.

[2opremio]

you'll have to fiddle with DNS (or do a deploy) to prove you own the domain.

How specifically? Please elaborate

[paulbellamy]

afaik most cert issuers have you add a dns record (rapidssl), or upload a file (comodo), to verify you own the domain.

[2opremio]

I bought a certificate in rapidssl through namecheap as @paulbellamy recommended. Now I am going through the exciting process of activating it.

[2opremio]

Do you guys think it's acceptable to keep the private key/csr in the respository? I don't feel like it is, but I don't see any good alternatives.

[paulbellamy]

For lack of a better option, that was the plan.

[2opremio]

OK, I have bought the certificate, if everything went well @apperly should receive it in his inbox soon.

[2opremio]

Got the certificate

[2opremio]

#176 is deployed, so the service now supports https, but there are a few things left which are reflected in following issues:

• Make probes use https with Scope Service scope#777
• Disable http (make service https-only) #270
• Incident: 10-min outage when switching the elb behind frontend.prod.weave.works #271

Closing