Cloud Manager » DNS Domains

In Kubernetes Services can be made accessible via a DNS host.domain name by relying on the mechanism of Ingress. An Ingress specifies the details to make a service accessible via DNS qualified names, and in case of secured https access a (SSL/TLS) certificate. In CloudManager, assignment of DNS names to Services is organized with the concept of Domain and Routes. Each user an defined a set of

Listing Domains

A Domain represent a top-level DNS name or a sub-domain, that can be optionally configured with a (SSL/TLS) certificate for https secure access. In Cloud Manager, Domains are a top-level resources that can be created and managed like Spaces and other top-level resources. From the top-right toolbar the button Domains navigates to the Domains listing page.

In a particular installation in CloudManager, some Domain are pre-defined as root-domains with auto-assignment. This means that when a user logs in in first time a set of sub-domains are created automatically for the user, and groups it belongs to (assuming these domain names are available). For EInnovator Public Cloud cloud.einnovator.org, several root domains with auto-assignment are predefined including: nativex.cloud and einnovator.cloud. So a user with username joe25 member of an organization named Acme, will be assigned the domains joe25.nativex.cloud, joe25.einnovator.cloud, acme.nativex.cloud and acme.einnovator.cloud.

If a pre-assigned domain is delete it may be used by other users. As such, if ownership of a domain is desired (pre-assigned or custom) but its not intended for current use for new Routes it can be disabled.

The image below show an example of a Domain list, including auto-created domains, and some custom.

Defining DNS Domains and Sub-Domains

In addition or as alternative to pre-assigned domains, user can defined additional Domains by clicking on Add New from the domain list. In the domain creation form only the field domain name is required. For sub-domain, a root domain should be specified. The root-domain, if specified defines the suffix of the fully-qualified domain-name (FQDN). Domain names need to be unique across the CloudManager installation and can be checked for availability while being defined.

Once a Domain is defined it can be used to defined Routes for Services. Namely, a Route is defined as a hostname concatenated with a Domain DNS fully-qualified domain-name. Many Routes can share the same Domain. A service can also have several Routes, with same or different domain name.

Table below show-cases some examples of Domains and Routes:

The following options can be specified when creating a Domain:

• Enabled — If Routes can use the Domain
• Sub-Domains – If the Domain can be used as parent/root domain to defined sub-domains
• SSL/TLS — If a SSL/TLS certificated should be configured to support HTTPS access
• an optional decorative media thumbnail

In addition to the above fields, a fews other are available to editing for Administrators only:

• Global [Admin only] — If the Domain is visible globally to all users as parent/root domain.
• Auto [Admin only] — If users are assigned domains automatically from this domain (as suffix, with username/group name as prefix)
• Sandbox [Admin only] — If the Domain can be used in routes of Solution flagged as sandboxed (e.g. multi-tenant deployments).
• Verified [Admin only] — The Domain DNS real-world ownership is verified.

The domain verification flag is intended as a help to Administrators in conflict management/resolution. It is not used in any way by CloudManager. Currently, CloudManager does not provide a mechanism to automatically or semi-automatically implement the verification of a domain. However, the flag can set by the Administrator as well details about the method used to make the verification.

Image below shows an examples of Domains being created as a sub-domain (left-hand side), and as a root-domain (right-hand side).

Domain HTTPS Certificates (SSL/TLS)

Secure access to a service with HTTPS protocol requires that a SSL/TLS certificate by provided. In CloudManager, the certificate can be configure at the domain-level or at the individual route-level. For domain-level configuration, the certificate should be either a wild-card certificate — i.e. with domain of the form *.domain or exhaustively specify the set of fully-qualified host.domain that are covered by the certificate.

In the UI, the option SSL/TLS is used to specify that HTTPS ingresses/routes are supported by the domain. Two sub-options are provided to specify the certificate:

• Default Certificate — inherit certificate from parent domain (if any)
• Custom Certificate — Provide a custom certificate

Secure HTTPS access via certification requires three pieces of information to be configured in PEM format:

• The certificate of the Certificate Authority that signed the domain certificate
• The certificate of the domain (i.e. containing the signed public key)
• The private key corresponding to the public key of the certificate

Images below show an example of a Domain being created with SSL/TLS certificate.

Certificates can be obtained for free from some certification authorities, or purchased by a wide variety of service providers that issue certificates (usually with a annual renewal rate). Some popular free certificate issuers are listed below:

• SSLforFree (requires renewal after 90days)
• LetsEncrypt as back-end to CertBot
• MrDomain (90-days free-trial)
• SSL.com (90-days free-trial)
• Comodo (90-days free-trial)

Using Domains

Domains are not used directly by services, but rather are part of the Route definition. Each Service can have one or more Routes bound to it, with each Route specifying a hostname and a Domain from the list of enabled Domains available to a user.

Routes can also specify a custom SSL/TLS certificate to support secure access. The certificate specified for a Route overrides the one specified at the domain-level (if any). Furthermore, the Domain used by a Route does not need to have SSL/TLS enabled, even if the Route specifies a SSL/TTLS to support secure access.

In Kubernetes the abstraction to setup DNS access to a service is with the Ingress abstraction. A Route in CloudManager is simply a convenient and organization abstraction that maps directly to an Ingresses. For each service of a managed Deployment, CloudManager creates and manages up to two Ingress — one for non SSL/TLS (unsecured) access, and another for SSL/TLS (secured) access. For a Deployment and Service named myapp, these two ingresses are created (in same Space/Namespace) with names myapp and myapp-tls, respectively.

Different web-browsers and browser versions have different policies regarding which certificates are accepted, with feedback is provided to users, and which accesses are allowed with invalid, expired, or non-provided certificates. Developers are encouraged to experiment and evaluate the behavior of different browsers with the certificates configured for their services.

Learning More

• Ingress (K8s Docs)
• Public Key Certificate (Wikipedia)