--- title: "Securing Decisions Container Environment" slug: "securing-decisions-container-environment-1" updated: 2025-10-17T19:23:17Z published: 2025-10-17T19:23:17Z --- > ## Documentation Index > Fetch the complete documentation index at: https://documentation.decisions.com/llms.txt > Use this file to discover all available pages before exploring further. # Securing Decisions Container Environment ## Overview This article demonstrates how to secure a Decisions Container Environment by defining the multiple Environment variables. Reference Article:To learn more about Decision Environment Variables, refer to the article [Decisions Environment Variables](https://documentation.decisions.com/v9/docs/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. ```actionscript DECISIONS_FORCEBASEURI= DECISIONS_ENABLEHTTPS=true DECISIONS_HTTPSCERTIFICATEPATH= DECISIONS_HTTPSCERTIFICATEPASSWORD= DECISIONS_ENABLEHTTPTOHTTPSREDIRECTION=true ``` | Variable | Description | | --- | --- | | DECISIONS_FORCEBASEURI | This environment variable must be used if SSL terminates at the Load Balancer. If an ingress controller or load balancer service is in front of containers, this will be used, and no other HTTPS variables need to be configured. | | DECISIONS_ENABLEHTTPS | This will allow enabling SSL over HTTP. | | DECISIONS_HTTPSCERTIFICATEPATH | Enter the name of the SSL certificate (.pfx format only). By default, this variable will search the certificate in "C:\" | | DECISIONS_HTTPSCERTIFICATEPASSWORD | Use this variable if the SSL certificate is password-protected. | | DECISIONS_ENABLEHTTPTOHTTPSREDIRECTION | This setting will redirect the connection from HTTP to HTTPS. | --- ## Securing Cookies ```actionscript DECISIONS_DEFAULTSAMESITECOOKIEMODE= ``` | Value | Description | | --- | --- | | Strict | Indicates the client should only send the cookie with "same-site" requests. It is a highly secure option. | | Lax | Indicates the client should send the cookie with "same-site requests and with "cross-site" top-level navigation. It is a default value. | | None | Indicates the client should disable same-site restrictions. It is the least secure option. | --- ## 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. ```actionscript 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. ```actionscript 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: ```none 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: ```none 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: ```none 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: ```none 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): ```none version: '3.8' services: decisions: image: decisionscore/platform volumes: - /path/on/host/decisions/data:/opt/decisions/data ports: - "8080:8080" ```