LATEST VERSION: 1.9 - CHANGELOG
Pivotal Cloud Foundry v1.9

Securing Traffic into Cloud Foundry

Page last updated:

This topic describes the options for securing HTTP traffic into your Elastic Runtime deployment with SSL/TLS certificates. You can configure the location where your deployment terminates TLS depending on your needs and certificate restrictions.

Protocol Support

Gorouter supports HTTP/HTTPS requests only. For more information about features supported by the Gorouter, see the HTTP Routing topic.

To secure non-HTTP traffic, terminate TLS at your load balancer or at the application. See TCP Routing for details.

SSL/TLS Termination Options

There are three options for terminating SSL/TLS for HTTP traffic. You can terminate TLS at the Gorouter, your load balancer, or at both.

The following table summarizes SSL/TLS termination options and which option to choose for your deployment.

If the following applies to you: Then configure SSL/TLS termination at: Related topic and configuration procedure
  • You want the most performant and recommended option, and
  • You can use a single SAN certificate for all system and application domains for your deployment.
Gorouter only Terminating SSL/TLS at the Gorouter Only
  • You cannot use a single SAN certificate for all system and application domains for your deployment, or
  • You require Extended Validation (EV) certificates.
Load Balancer only Terminating SSL/TLS at the Load Balancer Only
  • You want a higher level of security, and
  • You do not mind a slightly less performant deployment, and
  • You can use a single SAN certificate on the Gorouter, either for all system and application domains (but with a different key than for the same certificates hosted on your load balancer) or for a single domain (but with hostname verification disabled on the load balancer).
Load Balancer and Gorouter Terminating SSL/TLS at the Load Balancer and Gorouter

Certificate Requirements

The following requirements apply to the certificates you use to secure traffic into Elastic Runtime

  • In a production environment, use a signed SSL/TLS certificate (trusted) from a known certificate authority (CA).
  • In a development or testing environment, you can use a trusted CA certificate or a self-signed certificate generated with openssl or a similar tool.
  • The Gorouter currently only supports configuring a single HTTPS certificate. The certificate on the Gorouter must be associated with all the domains it may receive requests for so that HTTPS can validate the request. To associate multiple domains to a single certificate, including wildcard domains, use Subject Alternative Name (SAN), an X.509 extension.
  • If wildcard certificates are not supported for some or all of your domains, then terminate TLS at your load balancer.
  • If you cannot use a SAN certificate, terminate TLS at your load balancer.
  • Extended Validation (EV) certificates support multiple hostnames, like SAN, but do not support wildcards. For this reason, if EV certificates are required, then terminate TLS at the load balancer only.
  • If you must terminate TLS at your load balancer, you may optionally secure requests from the load balancer to the Gorouter by terminating TLS at the Gorouter also. To accomplish this without using a SAN certificate on the Gorouter, you will have to disable hostname validation on the load balancer, as the domain in the certificate hosted by the Gorouter will not match requests forwarded to it for applications on Elastic Runtime by the load balancer.

Terminating SSL/TLS at the Gorouter Only

In this configuration, the load balancer does not terminate TLS for CF domains at all. Instead, it passes through the underlying TCP connection to the Gorouter.

This option is the recommended and more performant option, establishing and terminating a single TLS connection.

The following diagram illustrates communication between the client, load balancer, Gorouter, and app.

Pass through

Traffic between the load balancer and the Gorouter is encrypted only if the client request is encrypted.

Certificate Guidelines

  • The Gorouter currently only supports configuring a single HTTPS certificate.
  • Use a SAN certificate because Elastic Runtime requires multiple wildcard domains.

About HTTP Header Forwarding

The Gorouter appends the X-Forwarded-For and X-Forwarded-Proto headers to requests forwarded to applications and platform system components. X-Forwarded-For is set to the IP address of the client, and X-Forwarded-Proto to the scheme of the client request.

If you terminate TLS/SSL at the Gorouter only, you do not need to configure any additional HTTP header forwarding on your load balancer.

Procedure: Gorouter Only

Perform the following steps to configure SSL termination on the Gorouter in Pivotal Cloud Foundry (PCF):

  1. Configure your load balancer to pass through requests from the client to the Gorouter.

  2. Navigate to the Ops Manager Installation Dashboard.

  3. Click the Elastic Runtime tile in the Installation Dashboard.

  4. Click Networking.

  5. Under Select one of the following point-of-entry options, select the first option, Forward SSL to Elastic Runtime Router.

  6. Enter your PEM-encoded certificate and your PEM-encoded private key in the fields under Router SSL Termination Certificate and Private Key. You can either upload your own certificate or generate an RSA certificate in Elastic Runtime. For options and instructions on creating a certificate for your wildcard domains, see Creating a Wildcard Certificate for PCF Deployments.

  7. If you want to use a specific set of SSL ciphers for the Router, configure Router SSL Ciphers. Enter a colon-separated list of custom SSL ciphers to pass to the router. Otherwise, leave this field blank.

  8. If you are not using SSL encryption or if you are using self-signed certificates, you can select Disable SSL certificate verification for this environment. Selecting this checkbox also disables SSL verification for route services.

    Use this checkbox only for development and testing environments. Do not select it for production environments.

  9. Click Save.

Terminating SSL/TLS at the Load Balancer Only

In this configuration, your load balancer terminates TLS, and passes unencrypted traffic to the Gorouter, which routes it to your app. Traffic between the load balancer and the Gorouter is not encrypted.

This option is recommended if you cannot use SAN certificates and if you do not require traffic to be encrypted between the load balancer and the Gorouter.

The following diagram illustrates communication between the client, load balancer, Gorouter and app.

Lb

Certificate Guidelines

You can use multiple certificates on your load balancer if the load balancer supports multiple VIPs or SNI.

About HTTP Header Forwarding

If you terminate SSL/TLS at your load balancer, then you must also configure the load balancer to append the X-Forwarded-For and X-Forwarded-Proto HTTP headers to the HTTP traffic it passes to the Gorouter.

Procedure: Load Balancer Only

Perform the following steps to configure SSL termination on the load balancer only in Pivotal Cloud Foundry (PCF):

  1. Create an A record in your DNS that points to your load balancer IP address. The A record associates the System Domain and Apps Domain that you configure in the Domains section of the Elastic Runtime tile with the IP address of your load balancer.

    For example, with cf.example.com as the main subdomain for your Cloud Foundry deployment and a load balancer IP address 198.51.100.1, you must create an A record in your DNS that serves example.com and points *.cf to 198.51.100.1.

    Name Type Data Domain
    *.cf A 198.51.100.1 example.com
  2. Navigate to the Ops Manager Installation Dashboard.

  3. Click the Elastic Runtime tile in the Installation Dashboard.

  4. Click Networking.

  5. For PCF deployments on OpenStack or vSphere, enter the load balancer IP address that you used to set up a wildcard DNS record in the Router IPs field. For more information, see the Elastic Runtime networking configuration topic for OpenStack or vSphere.

  6. Under Select one of the following point-of-entry-options, select the second option, Forward unencrypted traffic to Elastic Runtime Router.

  7. If you are not using SSL encryption or if you are using self-signed certificates, you can select Disable SSL certificate verification for this environment. Selecting this checkbox also disables SSL verification for route services.

    Use this checkbox only for development and testing environments. Do not select it for production environments.

  8. Click Save.

  9. After you complete the configuration in PCF, add your certificate or certificates to your load balancer, and configure its listening port. The procedures vary depending on your IaaS.

  10. Configure your load balancer to append the X-Forwarded-For and X-Forwarded-Proto headers to client requests.


    If the load balancer cannot be configured to provide the X-Forwarded-For header, the Gorouter will append it in requests forwarded to applications and system components, set to the IP address of the load balancer.

    Note: If the load balancer accepts unencrypted requests, it must provide the X-Forwarded-Proto header. Conversely, if the load balancer cannot be configured to send the X-Forwarded-Proto header, it should not accept unencrypted requests. Otherwise, applications and platform system components that require encrypted client requests will accept unencrypted requests when they should not accept them.

Terminating SSL/TLS at the Load Balancer and Gorouter

In this configuration two TLS connections are established: one from the client to the load balancer, and another from the load balancer to the Gorouter. This configuration secures all traffic between the load balancer and the Gorouter.

The following diagram illustrates communication between the client, load balancer, Gorouter, and app.

Lb and router

This option is less performant, but it does allow for use of multiple certificates under certain circumstances.

Certificate Guidelines

In this deployment scenario, the following guidelines apply:

  • Certificates for the Elastic Runtime domains must be stored on the load balancer.
  • On the Gorouter you can use a SAN certificate for all domains, or a standard certificate for a single domain that the load balancer has been configured to trust. In the latter case, however, you must disable hostname validation on the load balancer, as the domain of the certificate served by the Gorouter will not match requests sent to applications on Elastic Runtime.
  • If you are concerned about hosting a certificate key on the Gorouter, you can generate certificates for your load balancer for the same domains with a different key. If the key for the certificate on the Gorouter is compromised, then the certificate on the load balancer is not at risk, and vice versa.

About Hostname Verification

Hostname verification between the load balancer and Gorouter is unnecessary when the load balancer is already configured with the Gorouter’s IP address to correctly route the request.

If the load balancer uses DNS resolution to route requests to the Gorouters, then you should enable hostname verification.

About HTTP Header Forwarding

If you terminate SSL/TLS at your load balancer, then you must also configure the load balancer to append the X-Forwarded-For and X-Forwarded-Proto HTTP headers to requests it sends to the Gorouter.

Procedure: Load Balancer and Gorouter

Perform the following steps to configure SSL termination on the Gorouter and load balancer in Pivotal Cloud Foundry (PCF):

  1. Create an A record in your DNS that points to your load balancer IP address. The A record associates the System Domain and Apps Domain that you configure in the Domains section of the Elastic Runtime tile with the IP address of your load balancer.

    For example, with cf.example.com as the main subdomain for your Cloud Foundry (CF) deployment and a load balancer IP address 198.51.100.1, you must create an A record in your DNS that serves example.com and points *.cf to 198.51.100.1.

    Name Type Data Domain
    *.cf A 198.51.100.1 example.com
  2. Navigate to the Ops Manager Installation Dashboard.

  3. Click the Elastic Runtime tile in the Installation Dashboard.

  4. Click Networking.

  5. For PCF deployments on OpenStack or vSphere, enter the load balancer IP address that you used to set up a wildcard DNS record in the Router IPs field. For more information, see the Elastic Runtime networking configuration topic for OpenStack or vSphere.

  6. Under Select one of the following point-of-entry options, select the first option, Forward SSL to Elastic Runtime Router.

  7. Enter your PEM-encoded certificate and your PEM-encoded private key in the fields under Router SSL Termination Certificate and Private Key. You can either upload your own certificate or generate a RSA certificate in Elastic Runtime. For options and instructions on creating a certificate for your wildcard domains, see the Creating a Wildcard Certificate for PCF Deployments topic.

  8. If you want to use a specific set of SSL ciphers for the Router, configure Router SSL Ciphers. Enter a colon-separated list of custom SSL ciphers to pass to the router. Otherwise, leave this field blank.

  9. If you are not using SSL encryption or if you are using self-signed certificates, you can select Disable SSL certificate verification for this environment. Selecting this checkbox also disables SSL verification for route services.

    Use this checkbox only for development and testing environments. Do not select it for production environments.

  10. Click Save.

  11. After you complete the configuration in PCF, add your certificate or certificates to your load balancer, and configure its listening port. The procedures vary depending on your IaaS.

  12. Configure your load balancer to append the X-Forwarded-For and X-Forwarded-Proto headers to client requests.


    If you cannot configure the load balancer to provide the X-Forwarded-For header, the Gorouter appends it in requests forwarded to applications and system components, set to the IP address of the load balancer.

    Note: If the load balancer accepts unencrypted requests, it must provide the X-Forwarded-Proto header. Conversely, if the load balancer cannot be configured to send the X-Forwarded-Proto header, it should not accept unencrypted requests. Otherwise, applications and platform system components that require encrypted client requests will accept unencrypted requests when they should not accept them.

Was this helpful?
What can we do to improve?
View the source for this page in GitHub