TransparentChoice - On Premises Setup

dockerhero

While our online software is highly secure, some Enterprise IT teams prefer to upgrade to an onsite deployment of TransparentChoice. To do this, we leverage Docker and Kubernetes. Docker makes software delivery faster than ever. It is the most popular open-source technology 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.

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.

Frequently Asked Questions

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 only, 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. 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 frequently, often several times a week. These include fixes for high-risk vulnerabilities.

We only support the current release and one prior release. Customers are advised to keep their installations always 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 ping 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 hardware virtualization
  • 4 GB RAM (8+ GB recommended)
  • 50 GB disk spaced (SSD recommended)

NOTE: Based on number of users and specific portfolios' (such as number of projects or criteria) the above-mentioned pre-requisites may change and will require an upgrade.

Operating system requirements:

  • Linux 64-bit (tested on Fedora, Debian and Ubuntu)
  • Windows 10 (64-bit only) or Windows 11. Server derivatives should work assuming fully functional Docker engine and firewall rules in place.
  • FreeBSD 13+, via Minikube Docker engine under VirtualBox

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 FreeBSD (VirtualBox), Azure AKS. Incoming support for Red Hat OpenShift and Amazon EKS.
  • 2GiB memory allocation for the Web Application.
  • Minimum limit of 1500Mi of CPU allocation.

Other requirements:

  • Your Docker or Kubernetes 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://transparentchoice.yourcompany.com/
  • SSL certificate (cer file + passwordless keyfile). It is possible to configure it without SSL, but not recommended.

IMPORTANT!

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.