Welcome, Guest Login

Enterprise Support

Wildcard DNS and TLS/SSL Certificates in Anaconda Enterprise

Last Updated: Aug 08, 2018 04:52PM CDT
Version: 5.2.0

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, the DNS entries would be as follows:
anaconda.yourdomain.com IN A
*.anaconda.yourdomain.com IN A

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:

  • https://d99235d1.anaconda.yourdomain.com
  • https://h93756v5.anaconda.yourdomain.com
  • https://n92857p2.anaconda.yourdomain.com

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:
  • https://anaconda.yourdomain.com/apps/friendly/
  • https://anaconda.yourdomain.com/apps/hostile/

The hostile deployment will be sent cookies from the friendly deployment, and also from the primary user interface, and can therefore impersonate the accessing user. Javascript served by the hostile deployment can access the friendly deployment and the main user interface since they are in the same origin.

With subdomain routing

With subdomain routing, URLs for deployments would appear as:

  • https://friendly.anaconda.yourdomain.com/
  • https://hostile.anaconda.yourdomain.com/

The hostile deployment is in a different web origin from the friendly app, so the browser will not send the friendly app's cookies or the primary user interface's cookies to the hostile app. Javascript served by the hostile deployment cannot access the friendly deployment because they are in different origins/domains.
seconds ago
a minute ago
minutes ago
an hour ago
hours ago
a day ago
days ago
Invalid characters found