Enable HTTPS connection between ALB and ECS Task ENI

[ritchiey]

We're deploying a Load-balanced web service. It consists of a Rails app container with an Apache Modproxy based reverse proxy container running as a sidecar.

In our current deployment, Apache is configured to server HTTPS traffic. To deploy with Copilot, we currently need to disable this and serve HTTP traffic instead. This is likely to raise questions from our auditors about whether we truly still have end-to-end encryption. It also means that we can't easily use the same image in an environment where there isn't something else to terminate the SSL connection.

Ideally, we could indicate in our manifest.yml that a service is listening on port 443 and it would be assumed to be expecting HTTPS. Alternatively, an explicit flag would be fine.

As I understand it, we can use any self-signed certificate because the ALB won't verify it. We would use Copilot's existing secrets feature to supply the certificate and key to our Apache sidecar. Alternatively, we could generate a certificate in the container on startup.

We do not need HTTP in addition to HTTPS. It would be sufficient for the ALB to redirect HTTP -> HTTPS.

To make this feature easy for anyone to incorporate into their project, you could provide a Docker image that acts as a reverse proxy that generates its own certificate. It might be documented as follows:

Copilot terminates your HTTPS connection at the ALB. The connection from the ALB to your container is HTTP (unencrypted). This is adequate security for most purposes. If you have audit requirements that require end-to-end encryption, you may achieve this by adding an HTTPS enabled reverse-proxy sidecar. Update your manifest to include:

http:
    targetContainer: 'reverse_proxy'

sidecars:
  reverse_proxy:
    port: 443
    protocol: HTTPS
    image: "copilot-reverse-proxy-sidecar:latest"

[efekarakus]

Hi folks!

I just built a tiny prototype to get an understanding of how we could support this in Copilot and the changes are pretty tiny from our end! I just wanted to validate a few things:

1. Is it fair to assume that for end-to-end encryption the certificate attached to the Load Balancer will be imported? https://aws.github.io/copilot-cli/docs/manifest/environment/#http-public-certificates

2. I assume that you have a sidecar container such as Envoy ready that's going to terminate TLS is that accurate?
   For example, in my prototype I have a manifest that looks like this:

   http:
     alias: domain.com
     path: "/"
     target_container: "envoy"
   
   image:
     build: "./example/Dockerfile-app"
     port: 8080
   
   sidecars:
     envoy:
       port: 443
       image: "615288112214.dkr.ecr.us-west-2.amazonaws.com/demo/envoy-proxy:v2"

I know the issue mentions creating a sidecar that generates a self-signed cert, but wouldn't that require importing the self-signed certificate to ACM and attaching it to the load balancer by the sidecar? that seems to go against IaC best practices.

[ritchiey]

Hi @efekarakus

Thanks for your effort, but we're no longer using Copilot, so I can't really provide any more feedback for this. We were running Apache in the sidecar to terminate TLS.

WRT self-signed certificates, yes generating them in the container probably isn't the best idea.

[efekarakus]

This feature is now released in v1.22 🚀 !

For the blog post: https://aws.github.io/copilot-cli/blogs/release-v122/
Release notes: https://github.com/aws/copilot-cli/releases/tag/v1.22.0