Domains and Certificates Management

GoodData.CN can host multiple separated environments. These separated environments are what we call Organizations. Each Organization has its own set of data sources and workspaces. Organizations also have their own configurations of the external Identity Provider (using OIDC). Separte OIDC configurations allow Organizations to have separate user accounts from other Organizations.

An Organization has exactly one DNS hostname assigned. The hostname is configured using the Kubernetes Ingress resource. How you configure Ingress depends on the topology of your deployment, including how the Load Balancer is configured and where the TLS terminates. The following table provides a brief overview of how you might configure your site:

Shared Domain, TLS terminated on Load Balancer

This deployment type terminates incoming TLS/SSL traffic on your publicly facing Load Balancer. Decrypted traffic is directed to Kubernetes worker nodes. The Kubernetes Ingress Controller then delivers the request to a pod for processing. You can use Elastic Load Balancer (ELB) in Amazon AWS or other cloud providers that offer similar services.

Advantages

• TLS terminated on Load Balancer (fast).
• Wildcard certificate loaded on Load Balancer.
• Simplified DNS configuration (either wildcard DNS record or external-dns integration).

Drawbacks

• All Organization hostnames must belong to a single DNS domain.

  Note

  Load Balancer usually supports only a single TLS certificate. However, some cloud providers offer TLS certificates free of charge if they are issued by their own Certificate Authority and used on Load Balancer.

• Requires wildcard TLS certificate.

Shared Domain, TLS terminated on Ingress Controller

This deployment type passes the TLS through the Load Balancer directly to the Kubernetes Ingress Controller. This setup doesn’t require a wildcard TLS certificate, but does add overhead to managing certificates. A certificate manager is recommended to automate issuing certificates.

Advantages

• Data encryption on transit (TLS terminated on Ingress controller).
• Wildcard certificate not needed.
• You can use multiple certificate manager Issuers (configurable per organization).
• Independent from TLS support on Load Balancer.

Drawbacks

• Higher CPU load on the Ingress Controller (TLS encryption/decryption).
• Hostnames limited to domains you own.

Any hostname, manual certificate management

When you need to use hostnames belonging to domains you don’t control (typically these domains are part of a customers’ DNS zones), you must manage certificates and DNS records manually in cooperation with your customers. As an example of this cooperation, suppose your deployment runs on hostname gooddata-cn.example.com and you have two customers:

• Alpha Corp. wants to see their reports on URL https://analytics.alpha.example.com/
• Beta Inc. wants to use https://insights.beta.example.com/

First, ask both companies to update their own DNS zones so that their desired hostnames point to your deployment: Alpha Corp. needs to add analytics.alpha.example.com as a CNAME to gooddata-cn.example.com. Beta Inc. adds insights.beta.example.com as a CNAME to gooddata-cn.example.com.

To make TLS work, you need an SSL certificate issued for your deployment hostname (gooddata-cn.example.com) and a private key for the certificate. You can acquire these in one of two ways:

• Customers provide you with a certificate and key pair as they are owners of the domain. You need to upload this certificate and key as a Kubernetes Secret resource. The name of the Secret is used while creating the Organization itself.
• If the customer already updated their DNS CNAME to point to your deployment, you may use a certificate manager to automatically provision the certificate for this Organization. In this case, you do not need to ask the customer for a certificate.

The following image shows the topology of both options:

Advantages

• The most versatile approach. You can use both auto-provisioned certificates and manually managed certificates using secrets
• A wildcard certificate is not needed.
• Option to use a certificate manager for automatic certificate generation.

Drawbacks

• When using hostnames belonging to different domains, cooperation from the customer’s side is needed to properly configure the DNS record in the customer’s domain.
• Manually managed certificates leave certificate renewal and managing the lifecycle of Kubernetes Secrets containing keys and certificates as your responsibility.
• Manually managed certificates require active customer involvement and a secure channel for certificate delivery.

For more information about creating Organizations and how to manage certificates, see Create and Manage Organizations.