> ## Documentation Index
> Fetch the complete documentation index at: https://docs.domino.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 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 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](#prevent-package-installation-at-runtime).

## Restricted Projects

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

<Warning>
  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.
</Warning>

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](/cloud/platform-capabilities/core-concepts/projects/manage-git-projects/copy-project), 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 (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.
</Warning>

### 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.

```shell theme={null}
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.

```shell theme={null}
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.

```shell theme={null}
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:

```shell theme={null}
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 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.