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 Case||Community Edition or a Single Business Unit||Multiple business Units in a Company||Multiple End-user Customers|
|Number of Organizations||One||Many||Many|
|Domains||One (analytics.company.com)||All organizations share the same domain (sales.company.com, analytics.company.com)||Different domain names (analytics.foo.com, reports.bar.com)|
|Certificates||One (analytics.company.com)||One wildcard (*.company.com) or per domain||Per domain|
|Suggestion||TLS terminated on Ingress or Loadbalancer||TLS terminated on Ingress or Loadbalancer||TLS 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.
- TLS terminated on Load Balancer (fast).
- Wildcard certificate loaded on Load Balancer.
- Simplified DNS configuration (either wildcard DNS record or external-dns integration).
- All Organization hostnames must belong to a single DNS domain.
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 this setup does add overhead to managing certificates. A certificate manager is recommended to automate issuing certificates.
- Data encryption on transit (TLS terminated on Ingress controller).
- Wildcard certificate not needed.
- You can use multiple certificate manager Issuers (configurable per organization).
- Independent of TLS support on Load Balancer.
- 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.company.com and you have two customers:
- Alpha Corp. wants to see their reports on URL https://analytics.alpha.example.com/
- Bravo Inc. wants to use https://visualizations.bravo.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
Bravo Inc. adds
visualizations.bravo.example.com as a CNAME to
To make TLS work, you need an SSL certificate issued for your deployment hostname (
gooddata-cn.company.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:
- 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.
- 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 Set Up Organizations.