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.
To enable Restricted Environments in your Domino instance, set the central configuration option com.cerebro.domino.workbench.restrictedAssets.enabled to true.
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 will become unrestricted.
Once you mark a revision as Restricted, that Environment can’t be unrestricted. You can, however, choose which revision is the Restricted (i.e., frozen) revision. This limitation ensures that anyone using the environment will always be 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.
To enforce that a Project only uses Restricted Environments, mark the Project as Restricted when you create the Project.
|
Important
| A Restricted can only be classified as Restricted at the time of creation. Existing Projects cannot be classified as Restricted. Once a Restricted is classified as Restricted, it cannot be reverted to unrestricted. This ensures that every action in a Restricted Restricted uses a Restricted Environment at all times. |
When running workloads from a Restricted Project, Domino will limit 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 or fork a Restricted Project
When you fork a Restricted Project, the forked Restricted is also classified as Restricted. This ensures that any work performed on the forked Restricted is guaranteed to be done in a Restricted Environment in case you merge the forked Restricted back into the main Restricted.
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.
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 (e.g., 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.
|
Warning
| 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/RenvironOverwrite 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/.RprofileBlock 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-
If a Job is rerun and the previous Environment revision is no longer Restricted, the rerun will use the current Restricted revision of the Environment. If there is no Restricted revision available, the rerun will fail.
-
Scheduled runs will use the Restricted Environment revision at the time of scheduling. If the Environment revision changes before the scheduled run executes, it will continue to use the revision from the time of scheduling.