Security

This guide covers recommended security hardening for production deployments of the Zilla Console on Kubernetes.

Zilla Console ships with strong defaults, including Istio-based mutual TLS (mTLS) for internal service communication.

This document outlines additional optional controls commonly required in regulated or high-security environments.

Security Overview

Zilla Console uses Istio mTLS to encrypt and authenticate all pod-to-pod traffic between platform services. The chart renders PeerAuthentication and DestinationRule unconditionally, so Istio is a prerequisite for installing the chart at all, not an optional hardening step.

Additional security features can be layered on top depending on your environment and compliance requirements.

Feature	Purpose	Default
Istio mTLS	Encrypts all internal service traffic	Enabled
Network Policies	Restrict pod-to-pod communication	Enabled (CNI-dependent)
PostgreSQL SSL	Encrypts database connections	Optional
Internal Kafka auth	Credentials for the platform's Kafka	Required
Bootstrap Token Secret	Secures gateway bootstrap credentials	Recommended

Network Policies

Zilla Console includes Kubernetes NetworkPolicies to restrict communication between components.

Prerequisites

Your cluster CNI must support NetworkPolicies.

Supported CNIs include:

• Calico
• Cilium
• Weave Net

If your CNI does not support NetworkPolicies, the policies will be ignored safely without causing failures.

Install Calico (if required)

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/calico.yaml

Verify Network Policies

kubectl get networkpolicies -n zilla-platform

External PostgreSQL with SSL

For production deployments, an external PostgreSQL database with SSL enabled is recommended.

Self-hosted PostgreSQL with SSL

management:
  db:
    host: postgres.example.com
    port: 5432
    database: zilla
    username: zilla_user
    password: YourSecurePassword
    ssl:
      enabled: true
      mode: require
  postgres:
    enabled: false

External Kafka

Caution

Pointing the control plane at an external Kafka cluster is not supported by the chart today. control.kafka.enabled, control.kafka.security.*, and control.connect.kafkaBootstrapServers are accepted as values but no template reads them: every control component hardcodes its bootstrap server to the in-chart control-kafka:9092. Setting kafka.enabled: false therefore removes the Kafka deployment while leaving every component still pointed at it, and the control plane never starts.

Leave control.kafka.enabled: true and secure the internal Kafka with control.kafka.auth (a secretName, or a username and password) until external Kafka support lands.

control:
  kafka:
    enabled: true
    auth:
      secretName: kafka-credentials

Warning

The internal Kafka has no persistent volume. control.kafka.persistence.* is likewise dead config, there is no PersistentVolumeClaim template in the control chart, so Kafka runs on an emptyDir and loses control-plane state (bootstrap tokens, deploy state) if its pod is replaced.

Summary

For production deployments, Zilla Console recommends defense-in-depth using Istio mTLS, NetworkPolicies, an encrypted external PostgreSQL, secret-based credentials for the internal Kafka, and secret-based bootstrap tokens.