A complete writeup of the overview, security model, and architecture of the wildcard DNS/SSL requirements is available in the following document: Anaconda Enterprise 5 - Wildcard DNS/SSL Certificate Requirements. A summary of the document is shown below.
Anaconda Enterprise uses wildcard DNS entries and TLS/SSL certificates to provide cookie isolation between domains for content created by data science users. This configuration is required for project deployments and to launch editor sessions in a future version of Anaconda Enterprise.
Configuring wildcard DNS entries
For example, if you are using the FQDN anaconda.yourdomain.com with a master node IP address of 172.31.49.70, the DNS entries would be as follows:
anaconda.yourdomain.com IN A 172.31.49.70
*.anaconda.yourdomain.com IN A 172.31.49.70
How DNS subdomains are used in deployments
Anaconda Enterprise assigns a unique hostname to each deployment based on the project's UUID. This hostname is random and is automatically generated. For example, if your master node's DNS name is anaconda.yourdomain.com, the URLs for various deployments would appear as:
Alternatively the wildcard domain can be a separate domain, for example, *.deployments.anaconda.yourdomain.com.
In either of the above cases, the wildcard subdomain’s DNS entry would need to point to the master node. Additionally, the wildcard cert can be an SAN in the same cert as the master node's hostname or a separate cert altogether.
Security model for cookie and content isolation with DNS subdomains
Data science user deployments are presented within an iframe within the primary Anaconda Enterprise user interface so they appear without transitions, but the end user's browser actually accesses the underlying URL directly when it loads the iframe.
Without subdomain routing
Without subdomain routing, URLs for deployments would appear as:
With subdomain routing
With subdomain routing, URLs for deployments would appear as: