Documentation Index

Fetch the complete documentation index at: https://docs.insys-icom.com/llms.txt

Use this file to discover all available pages before exploring further.

Installing icom Router Management with Docker

Prev Next
This content is currently unavailable in German. You are viewing the default (English) version.

Preface

This guide covers the installation of the iRM in Version 2026.05.0 running in docker. The guide is split into two parts; The basic setup of the application and securing the application with TLS or mTLS.


System Requirements

Application Server

Requirements

1 - 1.500 Routers

1.500 - 3.000 Routers

CPU

8 vCPUs

16 vCPUs

RAM

16 GB

32 GB

Storage

100 GB HDD

200 GB HDD


Optional: Dedicated Database Server for Larger Environments

  • Ubuntu 22.04 server (preferred)

  • 8 vCPUs

  • 16 GB RAM

  • 100 GB HDD


Prerequisites before Installation


Getting up and running

Configuring the VM

Extract the archive to your desired location (we recommend using /opt/insys-irm). Make sure to own that directory to prevent permission issues.

sudo mkdir /opt/insys-irm
sudo tar -xzf insys-irm-2026_05_0.tar.gz -C /opt/insys-irm
sudo chown -R <USER>:<GROUP> /opt/insys-irm

Please note!

If you don’t have access to dockerhub or another docker registry hosting the official containers for traefik and (if using the internal database) postgres, icom Router Management will use the included containers.


Configuring the instance

In the .env file, located at the root of the application files, you need to provide information for:

  • Connecting to the database

  • Hosts IP or FQDN

  • Usage of an external database (optional)


Starting the application

To start the application execute ./start.sh and follow the instructions.


Configuring the icom Router Management

To configure your application login into icom Router Management using the default accounts credentials.

Username: default
Password: secret

Please note!

Please change the password of the default account by navigating to AdministrationMy User Profile. Default credentials in production environments pose a security risk.

Navigate to the System Settings page and adapt the following values:

Key

Value

CONNECTION_PROFILE_HOSTNAME

IP-Address or FQDN of your server

DEVICECONTROL_SERVER_CERT

NONE

AUTOUPDATE_SERVER_CERT

NONE

With these settings, the icom Router Management is in a basic functional state. Systems running in a controlled environment with no external network communication may be operated this way. If your application server does have an external network connection and is reachable from outside, please continue with the next chapter.


Securing the application

In order to harden the application, a few configurations should be done. The application offers the possibility to change the login flow to one using OIDC and implementing the Oauth2 Protocol, as well as being reachable via TLS and using mTLS for the device connections.

Here is an overview over the different network modes and their usage:

Mode

Description

http

Runs the network services without encryption. State of the basic application setup.

https

Runs the network services with encryption. Enables the usage of OIDC and 2FA for the application.

https-mtls

Runs the network services with encryption. Additionally secures the communication between icom Router Management and devices with mutual TLS. The preferred network mode.

Please note!

When switching to https-mtls later, every device already connected previously, has to be added again or fitted with valid certificates!

After choosing a desired network mode, fitting certificates need to be issued. Another sub domain will also be needed for your application server, to enable the router to path your requests to the authentication service.

TLS

Domains

Systems that can be accessed through a domain (e.g. irm.mycompany.com) need an additional domain, that leads to the same IP address. The following setup is needed:

  • Domain 1 (Your servers domain name): irm.mycompany.com

  • Domain 2 (Additional domain for authentication): auth.irm.mycompany.com

Both domains route to the same place, which is your application server. The reverse proxy (traefik) will internally route the requests to their respective place.

Certificates

Depending on which network mode you want iRM to operate in, different certificates and their keys are required. For https, both domains of your application server need to be present in the server certificate in the SAN field. Please contact the instance providing your certificates, or refer to the documentation of the used product.

Server certificate extensions example:

X509v3 Basic Constraints critical:

CA:FALSE


X509v3 Subject Key Identifier:

...


X509v3 Authority Key Identifier:

...


X509v3 Key Usage:

Digital Signature, Non Repudiation, Key Encipherment, Key Agreement


X509v3 Extended Key Usage:

TLS Web Server Authentication


X509v3 Subject Alternative Name:

URI:irm.mycompany.com, URI:auth.irm.mycompany.com


For added mTLS, a certificate authority with certificate signing capabilities and the respective key are needed.

Certificate authority extensions example:

X509v3 Basic Constraints critical:

CA:TRUE, pathlen:1


X509v3 Key Usage critical:

Digital Signature, Key Encipherment, Certificate Sign, CRL Sign

Installing the certificates

Stop the application before making changes to it:

./stop.sh

To supply the certificates to the application, the certificates need to be present in the certs folder with a specific name.
For https the following certs are required:

Certificate Type

Name

Note

Server Certificate

cert.crt

A server certificate that has the ability to support TLS for a web server (e.g. a certificate issued via LetsEncrypt)

Server Certificate Key

cert.key

The corresponding key of the server certificate.

Certificate Authority for mTLS

client-ca.crt

The certificate authority which will later issue certificates for the routers doing mTLS. The key of the certificate authority is not needed in the network, as the iRM backend will have the key in order to be able to issue certificates.

You should now have some or all of the certificates mentioned above in the certs folder.

Setting the network mode

Now that the certificates have been placed in the correct directory, we can tell the application in which network mode we want it to run. To do that, edit the .env file and set the network mode to one of the three possible values mentioned above:

sudo vim .env

Starting the application

To start the application execute ./start.sh again and follow the instructions. Check the traefik logs for error messages regarding certificates. To do that, either stay in attached mode and scroll through the logs, or execute the command docker logs irm-traefik. Should there be no errors, the certificates were accepted by the reverse proxy and should be used.

Configuring TLS

HTTPS

Navigate to Certificate ManagementCertificates, upload your server certificate, select it and use it as server certificate via the Action button.

HTTPS with added mTLS

Navigate to the Administration => System settings page to adapt the following values:

Key

Value

INVENTORY_CONNECTION_PROFILE_PORT

8443

Navigate to the Certificate Management => Certificate Authorities table and upload the client-ca certificate together with its key as a PKCS #12 container. After successful import, select the certificate and click on use as ... . The corresponding settings will now have been set, and routers will receive certificates issued by this authority in the future.

Enabling OIDC for the login flow

In Order to use the OpenID Connect (OIDC) login flow and possibly MFA authentication via TOTP, Oauth2 needs to be enabled for the application. This flow ensures compliance with the latest security standards in authentication and elevates security of the application. This can be easily done via the UI.

Change to the system namespace via the Switch account button in the top bar and navigate to the Administration => System Settings page to adapt the following values:

Key

Value

CLIENT_CONFIGURATION_AUTH_MODE

INTERNAL => OAUTH2

This value tells the frontend to rely on OIDC and talk to the running OIDC server for authentication and authorization. After changing this value you will be logged out. The application may show unexpected behaviour in the login because of the login flow switch. In that case clear the browser cache and start a new browser session.