Production security checklist

Before an environment goes live, work through the items below - each one names a security concern and links to the page with the mechanism. For the wider pass over an environment, beyond security alone, see the production checklist.

Set your own passwords

A container generates random passwords for everything that you do not set, and nobody knows a generated password. Set your own before the first start:

• Zato_Dashboard_Password - the Dashboard's admin account
• Zato_SSH_Password - the zato user's SSH access
• Zato_IDE_Password - the ide_publisher user for IDE integration

All three, and what they protect, are in the environment variables reference. For the accounts themselves, see security defaults, and to rotate a password later, see changing passwords.

Publish the TLS ports only

Every port that takes traffic has a TLS variant, and a production environment publishes only the TLS ports:

• Publish 11224, the load balancer's TLS port - this is how API clients reach you
• Do not publish 11223 or 8183 - the same traffic without TLS
• Publish 8184, the Dashboard's TLS port, only to your own network - a VPN, an office range, a bastion
• Do not publish 22 - docker exec and kubectl exec do the same job without an open port

The whole table, with what goes over each port, is under ports and network.

Serve your own certificate

A container without a mounted certificate generates a self-signed certificate, which browsers and API clients do not trust. Mount your own zato.pem and set the minimum TLS version through Zato_SSL_Protocols - the whole subject, including where the files go and how the load balancer serves them, is under SSL/TLS.

Require client certificates at the handshake

With a client CA mounted, Zato_SSL_Client_Verify=required rejects clients without a valid certificate at the handshake - the variable is in the environment variables reference and the certificate side is under SSL/TLS.

Authenticate every channel

Every channel takes a security definition, and a channel without one is unauthenticated. Assign one of the supported authentication methods to each channel - the types and how to pick one are under channel security, and the credentials that your own outgoing connections present are under outgoing connections.

Limit callers and filter addresses

Cap how much traffic any one caller sends and block the address ranges that should never reach you - both are part of rate limiting and firewall. To reuse one rate-limit plan across many API clients, assign quota tiers.

Protect the metrics endpoint

The /metrics Prometheus endpoint is behind HTTP Basic Auth whose password is Zato_Metrics_Password - set your own, and for the details see the environment variables reference and monitoring.

Cap request sizes

Zato_TCP_Max_Msg_Size caps the size of a single incoming HTTP message, in megabytes, and the server rejects requests over the limit - the variable is in the environment variables reference.

Keep secrets out of YAML

Enmasse never exports passwords, and the way to supply them at import time is environment variables with the Zato_Enmasse_Env. prefix - the configuration in git stays free of credentials. For how the references work, see enmasse.

Allow only the outbound access the platform needs

If your firewall blocks outbound traffic by default, allow outbound access for your own outgoing connections, for alert notifications, for health checks and for shipping logs out - the list is under ports and network.

See also

Learn more