Use Restricted Environments

You may want to ensure that a Compute Environment remains frozen and unmodifiable to guarantee that only certain packages are used for modeling or analysis. This can be important to ensure compliance with internal policies or external regulations. Domino lets you designate Compute Environments as “Restricted”. Environment Restriction ensures that users can’t use an Environment that has been modified after it has been certified as restricted. Restricted Environments provide the following benefits:

Improve security and reduce compliance risk by enforcing sensitive workloads to use only approved environments.
Reduce costs and management overhead by providing flexibility to run sensitive and non-sensitive workloads on the same Domino deployment, without compromising on compliance. By marking certain environments as “Restricted”, admins can ensure that they can enforce compliance for sensitive workloads while allowing data scientists the flexibility to use the latest innovations (new tools and libraries) on the same Domino deployment.

Use restricted environments

To enable Restricted Environments in your Domino instance, please reach out to Domino Support. Only an admin can mark a revision of an Environment as Restricted. To designate a Compute Environment as Restricted, go to Environments, select the environment and mark a specific Revision of the Environment as Restricted. You can also quickly set the latest environment revision to Restricted from the environment’s Overview tab by clicking the Restricted checkbox. Only a single Environment revision can be Restricted. If you mark another revision as Restricted, the previous revision becomes unrestricted. Once you mark a revision as Restricted, that Environment can’t be unrestricted. You can, however, choose which revision is the Restricted (that is, frozen) revision. This limitation ensures that anyone using the environment is always using a revision that was explicitly designated as Restricted. Even when an Environment is Restricted and changes to its Dockerfile aren’t permitted, data scientists can still install packages at runtime. To prevent these types of modifications, see prevent dynamic installation.

Restricted Projects

To enforce that a Project only uses Restricted Environments, mark the Project as Restricted when you create the Project.

A Restricted project can only be classified as Restricted at the time of creation. Existing Projects cannot be classified as Restricted. Once a Restricted project is classified as Restricted, it cannot be reverted to unrestricted. This ensures that every action in a Restricted project uses a Restricted Environment at all times.

When running workloads from a Restricted Project, Domino limits your choice of Compute Environment to Restricted Environments for all actions including but not limited to:

Start a manual job run.
Start a scheduled job run.
Start a Workspace.
Rerun a Job.
Start an App.
Start a Launcher.

Copy a restricted Project

When a Restricted Project is copied, the copied Restricted is also classified as Restricted. This is especially useful when the source Restricted is a Restricted template, since it ensures that Projects created from a template are Restricted if the template is Restricted.

Prevent package installation at runtime

Even when an Environment is frozen and changes to its Dockerfile aren’t permitted, data scientists may still install packages at runtime through various ways (for example, running a pip command or installing an R package from CRAN). To prevent these types of modifications, we recommend adding the below commands in your Environment’s Dockerfile. These commands prevent common ways of installing packages at runtime.

These examples are not meant to be exhaustive. We highly recommend that you include additional instructions depending on your organization’s policies and technologies.

Set read-only libpath and block well known R package repositories

Add the following lines to the compute environment’s Dockerfile to set the R_LIBS_USER directory to a folder the Domino user can’t write to.

RUN chmod 755 /usr/local/lib/R/site-library &&
    sed -i 's/^R_LIBS_USER/#&/' /usr/local/lib/R/etc/Renviron

Overwrite package install functions

Add the following lines to the compute environment’s Dockerfile to modify the package install functions to empty functions that produce a message that the environment is frozen.

RUN echo 'assign("utils::install.packages", function ()  cat("
 Frozen R environment, no package installation allowed

"), envir = globalenv())' >> /home/domino/.Rprofile &&
    echo 'assign("install.packages", function (pkg)  cat("
 Frozen R environment, no package installation allowed

"), envir = globalenv())' >> /home/domino/.Rprofile &&
    echo 'assign("devtools::install_github",  function () cat("
 Frozen R environment, no package installation allowed

"), envir = globalenv())' >> /home/domino/.Rprofile &&
    echo 'assign("install_github",  function (pkg) cat("
 Frozen R environment, no package installation allowed

"), envir = globalenv())' >> /home/domino/.Rprofile &&
    echo 'assign("devtools::install_gitlab",  function () cat("
 Frozen R environment, no package installation allowed

"), envir = globalenv())' >> /home/domino/.Rprofile &&
    echo 'assign("install_gitlab",  function (pkg) cat("
 Frozen R environment, no package installation allowed

"), envir = globalenv())' >> /home/domino/.Rprofile &&
    chown domino: /home/domino/.Rprofile

Block package repos by routing package repo requests to loopback address

The following pre-setup script modifies the /etc/hosts file to re-route requests to a popular package repo back to localhost.

echo "127.0.0.1 packagemanager.rstudio.com" >> /etc/hosts
echo "127.0.0.1 cran.r-project.org" >> /etc/hosts
echo "127.0.0.1 cran.microsoft.com" >> /etc/hosts
echo "127.0.0.1 bioconductor.org" >> /etc/hosts

Block pip installs by routing pip to a non-existent URL

One way to disable dynamic installation of packages from within a Workspace or a Job is to set the global index URL in the pip configuration to a non-existing URL:

pip config set global.index-url [https://path/to/a/non-existing/URL]

Limitations & caveats

If a Job is rerun and the previous Environment revision is no longer Restricted, the rerun uses the current Restricted revision of the Environment. If there is no Restricted revision available, the rerun fails.
Scheduled runs use the Restricted Environment revision at the time of scheduling. If the Environment revision changes before the scheduled run executes, it continues to use the revision from the time of scheduling.

Architecture & deployment

Identity & access

Infrastructure & compute

Platform configuration

Data administration

Operations, monitoring & cost

Security & compliance

Use Restricted Environments