Skip to main content

Harden DIAL for production

Reduce DIAL's attack surface and control how it retains sensitive data before going live. This guide is a checklist that builds on the chart's already-secure defaults: network isolation, TLS, secret hygiene, audit-log retention, and Toolset encryption. It assumes a Helm deployment with kubectl and Helm access.

Prerequisites​

  • DIAL deployed with the dial umbrella chart
  • An ingress controller and a TLS certificate source (for example cert-manager or a cloud certificate)

Step 1: Keep the secure container defaults​

The chart already runs services with hardened pod settings — verify a custom values file has not weakened them:

  • runAsNonRoot: true, with runAsUser/runAsGroup: 1001
  • capabilities.drop: ["ALL"] and allowPrivilegeEscalation: false
  • seccompProfile.type: RuntimeDefault
  • automountServiceAccountToken: false

Leave these on. Only relax a setting (for example for OpenShift) when the platform requires it, and document why.

Step 2: Restrict network traffic​

Network policies are disabled by default, so any pod can reach any other. Enable them and scope ingress and egress to what each service needs:

core:
networkPolicy:
enabled: true
allowExternal: false # only allow traffic from selected pods/namespaces

Pair this with cluster-level controls — a web application firewall and security groups or their equivalent — from your cloud deployment guide.

Step 3: Terminate TLS and force HTTPS​

Serve every external endpoint over TLS and redirect plain HTTP. Configure the certificate and policy on the ingress:

core:
ingress:
enabled: true
tls:
- hosts:
- dial.example.com
secretName: dial-core-tls

Use a modern TLS policy (TLS 1.2 or higher) and enable HTTP-to-HTTPS redirection. The per-cloud guides show the provider's ingress annotations for certificates and redirects.

Step 4: Manage secrets in a vault​

Plaintext credentials in values files are a primary exposure. Move every secret to a Kubernetes Secret or a cloud secret manager, and protect the irreplaceable encryption key:

Step 5: Control audit-log and conversation retention​

DIAL records conversation data in two places, and you control retention of both.

  • Application audit logs. When an application calls DIAL with an API key, Core records the conversation in an audit log. To stop storing it for a given key, set "secured": true on that key in Core's dynamic settings. See Keys configuration.
  • Blob storage. When a user signs in to DIAL Chat with a JWT, their conversations are also stored as files in blob storage. Manage retention with the object store's lifecycle and time-to-live policies; DIAL adds metadata to stored files to help those policies target the right objects. Deleting a conversation from blob storage does not remove it from audit logs.

Set retention to match your privacy and compliance obligations.

Step 6: Encrypt Toolset secrets with a KMS​

Toolsets can hold credentials of their own. Encrypt them with a managed key service instead of storing them unencrypted:

toolsets.security.kms.provider: aws   # aws | azure | gcp | unencrypted
toolsets.security.kms.keyId: <KMS_KEY_ID>

Content is encrypted with AES-256-GCM. See Toolsets and security configuration.

Step 7: Scan images and dependencies​

Pin image tags or digests rather than latest, pull from a registry you control, and scan images and dependencies for known vulnerabilities in your build pipeline. Apply security updates through the upgrade procedure.

Result​

DIAL runs with least-privilege pods, restricted network paths, enforced TLS, vaulted secrets, deliberate data retention, encrypted Toolset secrets, and scanned images — a substantially reduced attack surface ready for a production security review.

Coming soon

DIAL's repositories publish no formal compliance attestations (such as SOC 2, HIPAA, or GDPR readiness) or penetration-testing guidance, because these depend on your specific deployment and organization. Map the controls above to your framework with your security team.

Further reading​