Skip to content

TLS & Credentials

The operator manages all TLS material and credentials itself — no cert-manager dependency and no manual wazuh-cert-tool step.

Certificates

On first reconcile the operator generates a self-signed CA and signs the leaf certificates the stack needs, storing each in a Secret (created once, reused afterwards):

Secret Contents Used by
<name>-ca CA cert + key signing all leaves
<name>-indexer-certs node cert/key, CA, admin client cert/key indexer transport/HTTP, securityadmin
<name>-manager-certs filebeat client cert/key, CA manager → indexer (9200, TLS)
<name>-dashboard-certs dashboard server cert/key, CA dashboard HTTPS

Keys are PKCS#8 (required by the OpenSearch security tooling). The indexer node cert carries SANs for the service and per-pod headless DNS names.

Bring your own CA

Set spec.tls.caSecretRef to an existing Secret holding tls.crt/tls.key and the operator signs all leaves from it instead of generating one.

Credentials

Generated once into <name>-credentials:

Key Purpose
admin-password indexer admin (also used by filebeat)
kibanaserver-password dashboard → indexer
api-password Wazuh API
cluster-key manager cluster key
authd.pass agent registration password
admin-hash, kibanaserver-hash bcrypt hashes for internal_users.yml

Passwords are injected into pods via environment variables and are never written into ConfigMaps. The bcrypt hashes are stored so the rendered internal_users.yml stays stable across reconciles. A one-shot securityadmin Job applies the hashed users to the running indexer.

Rotation

Credential and certificate rotation is not automated in this release — see the Roadmap.