Domains and Certificates Management
GoodData.CN ready for Kubernetes will be published during May 2021. Stay tuned and watch GoodData Developers website.
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.
- 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)
- 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.
- 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
- 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
Beta Inc. adds
insights.beta.example.com as a CNAME to
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.
- 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
- 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.