Using App Engine Flexible behind a CDN (Fastly)

[Alex G]

We are currently using Fastly as our CDN that reads from the origin App Engine Flexible (GAE) app. When trying to enable a TLS connection between Fastly and GAE, we have noticed that ghs.googlehosted.com does not support TLS. We have also tried using myapp.appspot.com as the origin, but a 404 is returned. It seems related to the Host HTTP header, which is not supported in this case.

Is there any alternative to ghs.googlehosted.com that we could use that supports TLS?

[George (Cloud Platform Support)]

You may use HTTPS and SSL to connect to your instance, in which case you should: 

- Register a domain name

- Acquire an SSL certificate from a certificate authority

- Register the certificate with your HTTPS load balancer and its connected instances, or configure an SSL-terminated web server or proxy on one or more Compute Engine instances.

More related detail may be found on the "Securely Connecting to VM Instances" documentation page. 

The information above should cover your TLS functionality. There is no point in speculating on TLS implementation right now. 

[Alex G]

Thanks for your reply, George.

Isn't the GAE load balancer hidden to the user?  

[Ben Kraft]

We do this and it works well for us!  You need to send to yourapp.appspot.com, and make sure to set the Host header appropriately.  Fastly can do this, e.g. https://docs.fastly.com/guides/basic-configuration/specifying-an-override-host.html.

[George (Cloud Platform Support)]

You are right, the user does not get involved in running the load balancer. This is, by contrast, about how to use HTTPS or SSL load balancing: you must create at least one SSL certificate that can be used by the target proxy for the load balancer. More detail may be read on the "SSL Certificates" documentation page. 

[Alex G]

So far, this is what we have found out when choosing the origin host of our CDN (Fastly):

• myapp.appspot.com: Supports TLS but requires the Host HTTP header to be exactly "myapp.appspot.com". Therefore, the Host header needs to be overridden.
  
• ghs.googlehosted.com: Does not support TLS, but accepts any Host HTTP header, so you can use any of your App Engine custom domains.

@Ben, thanks for the answer! We will follow this approach, too, but we will need to send an extra header (for example, X-Host) in order to convey the actual site requested. Otherwise, the GAE app has no way of knowing what is the requested site since the Host header needs to be hardcoded to "myapp.appspot.com". Our GAE app hosts several sites with slightly different content.

@George, not sure if I understand what you are saying. I believe your instructions are geared towards Compute Engine, where you need to configure the load balancer. AFAIK, GAE abstracts this from us, so we have no way of dealing with the load balancer.

On Tuesday, May 15, 2018 at 1:57:16 PM UTC+2, Alex G wrote:

[Alex G]

Just another update here. I've realized that I was missing an SNI in the Fastly request to the origin.

You can test this with the following command (ensure your curl is up to date):

curl --resolve ghs.googlehosted.com:443:mydomainA.com https://mydomainB.com/ -v -I

Basically, if there is a valid certificate for mydomainA.com on App Engine (which should be automatic), then you can do a request to https://mydomainB.com/.

On Tuesday, May 15, 2018 at 1:57:16 PM UTC+2, Alex G wrote:

[George (Cloud Platform Support)]

Is Fastly a must for your architecture? You may consider using Google Cloud CDN instead. If Fastly is a must, you are invited to open a feature request in the public tracker. 

[Alex G]

@George, is Google Cloud CDN compatible with App Engine (Flexible)? I thought it was just possible to use it with GCE.

On Tuesday, May 15, 2018 at 1:57:16 PM UTC+2, Alex G wrote:

[George (Cloud Platform Support)]

You are right, Cloud CDN content can originate from Google Compute Engine virtual machine (VM) instance groups or from Google Cloud Storage buckets. This is one option. If you prefer alternatively to use Fastly in the configuration already described, you are encouraged to log a feature request in the public tracker by including content already present here, and a reference to this groups thread. If you need more assistance, or if you prefer us to open this feature request instead, you are welcome to reply accordingly.