# Example: Netbox

- Link: https://www.agilicus.com/anyx-guide/example-netbox/
- Published: 2025-02-17T23:25:06+00:00
- Author: Don Bowman

1. [Home](https://www.agilicus.com/)
 2. Example: Netbox

![Agilicus Example: Secure access to applications and infrastructure using zero 
trust network access (ZTNA). Image shows the Agilicus logo and a diagram of the 
ZTNA architecture.](https://www.agilicus.com/www/f3641e17-image-1024x686.png)

## Example: Netbox

Setup Netbox to be used via Agilicus AnyX

[CONTACT](https://www.agilicus.com/contact-us/)

## Overview

“NetBox is the leading solution for modeling and documenting modern networks.”. 
It can be simply run via e.g. a container or other methods.

In this example we show how to setup NetBox to be access by, and signed into by,
Agilicus AnyX, providing secure remote access with single sign on.

### Netbox setup

For this example, we are using the docker-compose environment [https://github.com/netbox-community/netbox-docker](https://github.com/netbox-community/netbox-docker)
of the community netbox-docker.

We modify the env/netbox.env file to add these lines:

    ```wp-block-code
    CSRF_TRUSTED_ORIGINS="https://netbox.__MYDOMAIN__ http://localhost"

    REMOTE_AUTH_ENABLED=True
    REMOTE_AUTH_BACKEND='netbox.authentication.RemoteUserBackend'
    REMOTE_AUTH_AUTO_CREATE_USER=True
    REMOTE_AUTH_AUTO_CREATE_GROUPS=True
    REMOTE_AUTH_GROUP_SYNC_ENABLED=True
    REMOTE_AUTH_HEADER=HTTP_X_GATEWAY_USER_EMAIL
    REMOTE_AUTH_GROUP_HEADER=HTTP_X_GATEWAY_PRIMARY_ROLE
    REMOTE_AUTH_DEFAULT_GROUPS=admin
    ```

These headers for REMOTE_AUTH_* are documented here: [https://netboxlabs.com/docs/netbox/en/stable/configuration/remote-authentication](https://netboxlabs.com/docs/netbox/en/stable/configuration/remote-authentication).

The CSRF_TRUSTED_ORIGINS allows the Agilicus external name to be allowed to sign
in.

Once we have done this, we run `docker compose up`, and, NetBox is now running.

From here, assuming we already have a connector installed, we can create an application
following the below steps. All except the last step are done through the ‘Resources/
Applications/New’ stepper. The last step (enabling User Context headers), navigate
to Resources/Applications/Overview, and select your new application, then select
the Proxy header.

![image](https://www.agilicus.com/www/7906e319-image-1024x643.png)

![image](https://www.agilicus.com/www/bf71ec27-image-1024x657.png)

![image](https://www.agilicus.com/www/278832f7-image-1024x590.png)

![image](https://www.agilicus.com/www/94b8f9f9-image-1024x754.png)

![image](https://www.agilicus.com/www/711d9130-image-1024x551.png)

![image](https://www.agilicus.com/www/402bcd78-image-1024x741.png)

![image](https://www.agilicus.com/www/e461a00d-image-1024x924.png)

![image](https://www.agilicus.com/www/250059ce-image-1024x658.png)

![image](https://www.agilicus.com/www/312d8e6e-image-1024x754.png)

![image](https://www.agilicus.com/www/15e1d2df-image-1024x723.png)

At this stage, you should be able to navigate to https://netbox.__MYDOMAIN__ (or,
https://profile.__MYDOMAIN__ and see the icon). You should be auto-logged in as 
a user in the admin group. You can later add users to Agilicus AnyX permissions 
with ‘self’ or ‘admin’ to give control of what they can do in netbox. Add additional
groups if desired.

NOTE: since we chose the ‘multiple roles’ option in the stepper, we must manually
configure the firewall rule, allowing each of the roles full HTTP access, and then
allowing NetBox to decide what sub-permissions to do based on group.