TransparentChoice - On Premises Setup

dockerhero

While our online software is highly secure, some Enterprise IT teams prefer to deploy via an onsite version of TransparentChoice.

To do this, we leverage Docker and Kubernetes as popular open-source technologies used for developing, shipping, and running containerized applications.

The main advantage of using Docker images is that applications are packaged in 'containers' so that they are portable to any system that supports Docker or Kubernetes.

 

Getting Started

Please review our guide here to understand the system requirements we recommend for a standard deployment, and if you have any questions reach out to our engineering team via: saulo@transparentchoice.com.

For non-standard deployments please speak with our sales team to discuss support options.

 

What infrastructure services do you need to provide?

TransparentChoice sometimes sends e-mails to users (links to surveys, notifications, etc.). To enable this functionality, you need to give us access to SMTP. We provide, for testing purposes or air-gapped deployments, a mail trap application that stores e-mail messages in a simple web page.

 

Which services are installed in the image?

  • TransparentChoice web application (based on Microsoft's ASP.NET Core images)

  • SQL Server 2022 Express edition. During installation time, customers can choose to use another SQL Server edition, as long as they possess licenses to do so. It is possible to install to an external database.

  • HAProxy. The TransparentChoice web application is exposed to users through this proxy.

  • HashiCorp Vault. The configuration parameters are encrypted and stored in this vault.



How is user access control implemented? 

The user access control can be implemented in two ways:

  • Local user database - this is built in to our system.

  • Connect to Microsoft Active Directory or other external directory service. Configuration is required if you want to connect to the Active Directory. 


Are login and logout events logged? What is the storage duration for the entries and where can they be viewed?

Sign-in attempts are recorded in the customers' machine's FILE SYSTEM DIRECTORY (Docker Volume). The logs are stored for as long as the customer wants however, the daily file size limit is 100 MB. If the data exceeds 100 MB then the old logs are overwritten.

Note: Log rolling interval is 1 day.

The proxy keeps source IP addresses, if available, in memory, tracking all requests forwarded the application. They disappear if the proxy is restarted.

 

Do you scan the image for software vulnerabilities, and can you submit the report?

Yes, TransparentChoice's Azure security centre automatically scans the Azure container registry for vulnerabilities.

 

What is the planned update cycle, i.e. how old is the image? Are updates on demand planned for high risk vulnerabilities? How often do I have to update my image?

Customers who use the on-site version of TransparentChoice via Docker will have access to our image registry. We publish new images every 2-4 weeks as we develop the software. While these can include fixes for high-risk vulnerabilities, most are iterative roadmap based features. As such we will proactively encourage our on-premises customers to take a quarterly update with a consolidation of changes made that period.

We support the current release and one quarter prior so encourage clients to keep up to date.

 

Is it possible to monitor the availability of the application using systems such as Nagios?

 Yes. TransparentChoice has URL-based navigation and so your monitoring tool can simply ping the root URL in order to monitor system availability. For example, if you set your TransparentChoice application root page as https://transparentchoice.example.com/, then you would attempt a HTTP-request that page to test system availability.

 

System Requirements

Docker:

The minimum hardware you will need is as follows:

  • 2 GHz processor with SLAT enabled (Second Level Address Translation)

  • Enabled BIOS-level and OS-level hardware virtualization. If running within a virtual machine, nested virtualization must be activated.

  • 4 GB of available RAM (8+ GB recommended)

  • 50 GB of available disk space (SSD recommended)

NOTE: Based on number of users and specific portfolios (such as number of projects or criteria), the requirements may be higher than specified. 

 Supported operating systems:

  • Linux 64 bit (tested on Fedora, Debian and Ubuntu).

  • Windows 10 (64 bit only), Windows 11 or 64 bit Windows Server 2019 or newer with WSL2.

For ease of management, we recommend using our WSL2 image under Windows with all the requirements already installed and configured.

Kubernetes:

  • Person executing the installation must have access rights to run kubectl against the hosting cluster, including executing commands in the pods and exposing services. The environment must be pre-configured by the customer.

  • As determined by your cluster administrator, you must have FsGroup and RunAsUser values for the Web Application, the Vault and, if applicable, MSSQL.

  • If using your own MSSQL cluster, it must have a valid certificate and working network connectivity between the Kubernetes cluster and the MSSQL cluster.

  • Tested under Minikube in Linux (native) and Azure AKS.

  • 2GiB memory allocation for the Web Application.

  • 1500Mi of CPU allocation at least.

Other requirements:

  • Your Docker, Kubernetes or WLS2 environment must be prepared.

  • SMTP settings for sending emails (e.g. notifications) from the application to the users.

  • Hostname and port (SSL).

  • Email and display name to set as "From" in the email headers.

  • Emails of users who will access the admin panel.

  • Base URL for the application, used to generate links. E.g.: https://yourcompany.tch.com/

  • SSL certificate (cer file + passwordless keyfile). It is possible to configure it without SSL, but not recommended.

Important note on Backups

The customer is responsible to back up the folder which contains the entire application state and configuration:

  • database files

  • files uploaded by users

  • configuration files

  • encryption keys and certificates

  • application logs

The customer can use the provided tool to take backups. Customers using their own MSSQL cluster are responsible for its maintenance and backups.

 

 NOTE: This page is TransparentChoice Limited confidential information. Please do not share it with anyone not covered by our non-disclosure terms and only share it with people who need access to this information.