Domains and Certificates Management

GoodData.CN can host multiple separated environments, so-called Organizations. Each Organization has its own set of data sources and workspaces. It also has its own configuration of external Identity Provider (using OIDC), allowing every Organization to separate its user accounts from other Organizations.

An Organization has exactly one DNS hostname assigned and this hostname is configured using Kubernetes Ingress resource. The way how the Ingress is configured depends on the topology of your deployment, notably how the Load Balancer is configured and where the TLS is terminated. In the following paragraphs, we will describe basic deployment types, their benefits, and drawbacks.

Shared Domain, TLS terminated on Load Balancer

This deployment type is specific by terminating incoming TLS/SSL traffic on your publicly facing Load Balancer. Decrypted traffic is further directed to Kubernetes worker nodes and eventually hits the Kubernetes Ingress Controller that delivers the request to a pod responsible for processing the request. You can use Elastic Load Balancer (ELB) in Amazon AWS, other cloud providers offer similar services.

Advantages

• TLS terminated on Load Balancer (fast)
• Hassle-free TLS setup (wildcard certificate loaded on Load Balancer)
• Simple DNS configuration (either wildcard DNS record or external-dns integration)

Drawbacks

• Limited to have all Organization hostnames belonging to a single DNS domain
• Requires wildcard TLS certificate

The shared domain model limitation comes from the fact that Load Balancer usually supports just a single (or a few) TLS certificates. Some cloud providers offer TLS certificates free of charge if they are issued by their own Certificate Authority and used on Load Balancer.

Shared Domain, TLS terminated on Ingress Controller

This deployment type is different from the previous one mainly in the fact that TLS is passed through the Load Balancer directly to Kubernetes Ingress Controller. Such setup doesn’t require a wildcard TLS certificate but brings some burden with certificate management. Hopefully, you can integrate with cert-manager that will provide certificates automatically.

Advantages

• Data encryption on transit (TLS terminated on Ingress controller)
• Wildcard certificate not needed
• You can use multiple cert-manager Issuers (configurable per organization)
• Let’s Encrypt supported by cert-manager
• Independent of 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 your use-case requires using hostnames belonging to domains you can’t control (typically are part of customers’ DNS zones), you must manage certificates and DNS records manually in cooperation with your customers. To explain this use-case more in detail, suppose your deployment runs on hostname anywhere.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 anywhere.example.com. Beta Inc. adds insights.beta.example.com as a CNAME to anywhere.example.com.

To make TLS working, you need an SSL certificate issued for Organization’s hostname and its related private key. Basically, there are two options for how to get some:

• Customers provide you with a certificate/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 Secret will be later used during creating the Organization itself
• If the customer already created DNS CNAME pointing to your deployment, you may use the Cert-manager tool to automatically provision the certificate for this Organization. In this case, you do not need to ask the customer for a certificate.

In the picture above, you can see both options at once.

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 cert-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 are, well, manual. Certificate renewal and the whole lifecycle of Kubernetes Secrets containing keys and certificates are up to you.
• Manually managed certificates require active customer involvement and a secure channel for certificate delivery.

More about creating Organizations and how to manage certificates will be described in the chapter Organization Custom Resource.