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
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:
einnovator.cloud. So a user with username
joe25 member of an organization named
Acme, will be assigned the domains
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.
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:
|Domain Name||Parent Domain||FQDN||Hostname||Route DNS||Service URLs|
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
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).
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:
Secure HTTPS access via certification requires three pieces of information to be configured in PEM format:
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:
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
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.