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). Separate 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:

Use CaseCommunity Edition or a Single Business UnitMultiple business Units in a CompanyMultiple End-user Customers
Number of OrganizationsOneManyMany
DomainsOne (analytics.company.com)All organizations share the same domain (sales.company.com, analytics.company.com)Different domain names (analytics.foo.com, reports.bar.com)
CertificatesOne (analytics.company.com)One wildcard (*.company.com) or per domainPer domain
SuggestionTLS terminated on Ingress or LoadbalancerTLS terminated on Ingress or LoadbalancerTLS terminated on Ingress

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 the Elastic Load Balancer (ELB) in Amazon AWS or use other cloud providers that offer similar services.

Shared Domain, TLS terminated on Load Balancer

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.
  • 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 this setup does add overhead to managing certificates. A certificate manager is recommended to automate issuing certificates.

Shared Domain, TLS terminated on Ingress Controller

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:

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:

Any hostname, manual certificate management

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 .