Securing Decisions Container Environment

Overview

This article demonstrates how to secure a Decisions Container Environment by defining the multiple Environment variables.

Securing connection - HTTPS

Ensure that the HTTPS port 443 is open and that the correct certificate has been saved on the system. Following is the list of variables to enable the HTTPS connection.

Local install must manually edit the container's URL in-browser by adding "https://" before the domain name and ":433" after the domain name e.g., "http//:localhost:443".

The browser may display a warning against this redirect. If prompted, select the Advanced button, then select Proceed to continue.

DECISIONS_FORCEBASEURI=<PortalbaseURL>
DECISIONS_ENABLEHTTPS=true
DECISIONS_HTTPSCERTIFICATEPATH=<certificate.pfx>
DECISIONS_HTTPSCERTIFICATEPASSWORD=<Certificate Password>
DECISIONS_ENABLEHTTPTOHTTPSREDIRECTION=true

Securing Cookies

DECISIONS_DEFAULTSAMESITECOOKIEMODE=<Cookie Value>

HSTS

HSTS (HTTP Strict Transport Security) is a web security policy mechanism that forces web browsers to interact with websites only via secure HTTPS connections and never with HTTP.

DECISIONS_ENABLEHTTP=false
DECISIONS_ENABLEHTTPS=true
DECISIONS_ENABLEHSTS=true

HSTS on the Subdomain

To support HSTS on a subdomain, users need to add an optional parameter known as includesubdomain. Users need to define custom headers to add includesubdomain on the Environment Variable. Following is the list of variables to be added to enable HSTS on the Subdomain.

DECISIONS_ENABLEHTTP=false
DECISIONS_ENABLEHSTS=false
DECISIONS_ENABLEHTTPS=true
DECISIONS_CUSTOMHEADERS=[{"Name": "Strict-Transport-Security","Value": "max-age=31536000;includeSubDomains"}]

Root Users

Running a container as a Root User is not recommended for production environments. Beginning in v9.17, all Decisions containers by default run as non-Root Users. 

Users that have existing deployments on v9.16 and below with persistent volumes containing data created by the root user, must apply one of the migration strategies below to ensure proper file permissions.

Files in /opt/decisions/data owned by Root will be inaccessible to the new non-root user. New deployments and fresh volumes are not impacted by the change and will work as expected after upgrading.

Migration Options

Choose the appropriate method based on the deployment environment:

Option 1: Using fsGroup (Recommended for Kubernetes)

Add the following security context to the Pod/Deployment specification:

apiVersion: apps/v1

kind: Deployment

metadata:

  name: decisions

spec:

  template:

    spec:

      securityContext:

        runAsUser: 1000

        runAsGroup: 1000

        fsGroup: 1000

        fsGroupChangePolicy: "OnRootMismatch"  # Optimizes performance

      containers:

      - name: decisions

        image: decisionscore/platform

        volumeMounts:

        - name: decisions-data

          mountPath: /opt/decisions/data

      volumes:

      - name: decisions-data

        persistentVolumeClaim:

          claimName: decisions-pvc

When to use:

• Using PersistentVolumeClaims with cloud storage (AWS EBS, GCP PD, Azure Disk).
• Standard Kubernetes deployments.
• Quick migration with minimal configuration.

Limitations:

• Does not work with hostPath volumes.
• May cause slow startup for volumes containing millions of files.

Option 2: Using Init Container (For Advanced Scenarios)

Use this approach if fsGroup does not work with the storage type or you need explicit permission control:

apiVersion: apps/v1

kind: Deployment

metadata:

  name: decisions

spec:

  template:

    spec:

      initContainers:

      - name: fix-permissions

        image: busybox:latest

        command:

        - sh

        - -c

        - |

          echo "Fixing permissions for /opt/decisions/data..."

          chown -R 1000:1000 /opt/decisions/data

          chmod -R 755 /opt/decisions/data

          echo "Permission fix complete"

        volumeMounts:

        - name: decisions-data

          mountPath: /opt/decisions/data

        securityContext:

          runAsUser: 0  # Init container runs as root



      containers:

      - name: decisions

        image: decisionscore/platform

        volumeMounts:

        - name: decisions-data

          mountPath: /opt/decisions/data

        securityContext:

          runAsUser: 1000

          runAsGroup: 1000

          allowPrivilegeEscalation: false

      securityContext:

        fsGroup: 1000



      volumes:

      - name: decisions-data

        persistentVolumeClaim:

          claimName: decisions-pvc

Best used if:

• Using hostPath volumes
• fsGroup not supported by the storage driver
• Need explicit ownership change (not just group)
• Complex permission requirements

Option 3: Docker Compose (Docker/Non-Kubernetes)

If there is existing data created by the Root User, perform a one-time permission fix before starting:

docker run --rm -v file_path:/data alpine sh -c "chown -R 1000:1000 /data && chmod -R 755 /data"

Replace file path with the named volume.

For Docker Compose deployments, the container will handle permissions automatically:

• Using named volumes:

version: '3.8'

services:
  decisions:
    image: decisionscore/platform

    volumes:
      - decisions-data:/opt/decisions/data

    ports:
      - "8080:8080"

volumes:
  decisions-data:

• Using bind mounts (host path):

version: '3.8'

services:

  decisions:
    image: decisionscore/platform

    volumes:
      - /path/on/host/decisions/data:/opt/decisions/data

    ports:
      - "8080:8080"