Required Platform Secrets

The Zend Enterprise Web Platform expects a small number of Kubernetes Secrets to exist before you deploy the chart. These provide the MySQL credentials used by ZendHQ and the ZendHQ admin credentials and license. You will also create your own secrets for your applications' environment configuration.

This section describes the two platform secrets, how to create them, where to reference them in your values, and how to manage them over time. For the broader workflow of preparing secrets during initial setup, see Getting Started — Preparing secrets.

How the platform consumes secrets

ZEWP uses two secrets by default:

1. A MySQL secret holding the credentials ZendHQ uses to connect to its MySQL database.
2. A ZendHQ secret holding the default admin user, password, ZendHQ license, and a pointer to the MySQL secret.

You can combine these into a single secret if you prefer; the important thing is to note the name of the secret used for each set of values, because you reference those names in your chart values.

The values configuration exposes several places where you supply a secret name, including:

For each, provide the relevant secret name you created (mysql-secret and zendhq-secret, respectively).

Create secrets before deploying. Create the namespace first, then create the secrets, then deploy. Pods read secrets at startup; a missing secret shows up as a pod stuck in error with a telling message in kubectl describe pod.

MySQL

The MySQL secret provides the credentials ZendHQ uses to reach its database. Create it with three key/value pairs:

kubectl -n <namespace> create secret generic mysql-secret \
  --from-literal=mysql-username=username_you_will_use \
  --from-literal=mysql-password=associated_password \
  --from-literal=mysql-root-password=root_password_for_instance

This creates a secret named mysql-secret. The keys correspond to the values referenced in your configuration:

Reference the secret in your global values:

The bundled MySQL subchart (zendphp-mysql) can also reference a pre-existing secret directly via zendphp-mysql.auth.existingZendhqSecret (and existingClusterSecret for root/cluster credentials), which is more secure than placing credentials inline in values. See MySQL in the values reference.

ZendHQ

The ZendHQ secret provides the default admin user and password, the ZendHQ license file, and a pointer telling ZEWP which secret holds the MySQL credentials. Create it with:

kubectl -n <namespace> create secret generic zendhq-secret \
  --from-literal=zendhq-user=admin \
  --from-literal=zendhq-password=somesecretpassword \
  --from-literal=zendphp-mysql-secret=mysql-secret \
  --from-file=license-file=path/to/zendhq/license

The keys are:

Note that zendphp-mysql-secret holds the name of the MySQL secret, not the credentials themselves — it is how ZendHQ is told where to find the MySQL username and password.

Reference the secret in your ZendHQ values:

The ZendHQ metrics exporter authenticates to the ZendHQ API using the same secret by default; its keys are configurable under zendphp-exporters.zendhq.auth (userKey defaults to zendhq-user, tokenKey to zendhq-token). See Metrics exporters.

Validating, changing, and rotating secrets

Validate

kubectl -n <namespace> get secret <secret-name> -o yaml

Values are masked with base64 encoding; decode them with a base64 tool if you need to verify the actual contents.

Change or rotate

Secrets are immutable once created and persist between chart revisions, so changing one, including adding a key, is a delete-and-recreate operation:

# 1. Delete
kubectl -n <namespace> delete secret <secret-name>

# 2. Recreate with the new values (see the create commands above)

# 3. Restart consuming pods so they pick up the change
kubectl -n <namespace> rollout restart deployment/<deployment-name>

A rolling restart is the preferred way to apply the change with no downtime, and is the recommended approach when autoscaling is enabled: Kubernetes brings up new pods with the new secret before terminating the old ones. Alternatively, delete the pod(s) to force a redeploy. See Changing secrets and Restarting a deployment.

Application secrets

Beyond the two platform secrets, you will typically create secrets to seed your applications' environment variables (database URLs, API keys, and so on). Create them as generic secrets and reference them from your application values via envFrom:

The same envFrom block applies to Job Queue workers under zendphp-job-queue.applications.<app_name>. See PHP Application and web server values.