Title
Page icon
Create new category
Edit page index title
Edit category
Edit link
Configuration reference
All configuration is supplied through Helm values. Read a chart's defaults with helm show values ./md-cluster-services (and the same for md-cluster-instances), then override what you need in your own values file, which is passed to both charts.
Only the keys you set are overridden — everything else falls back to the chart default. Keys under secrets: are rendered into the mdcluster-secrets Secret, keys under env: into the mdcluster-config ConfigMap, and both are exposed as environment variables to the MetaDefender Cluster Control Center, MetaDefender Cluster Identity Service, MetaDefender Cluster File Storage and MetaDefender Cluster Worker pods across both releases. The bundled PostgreSQL, Redis and RabbitMQ pods do not receive them — they read only the few credential values they need.
Images
Key | Default | Description |
|---|---|---|
|
| Registry and repository. Images resolve to |
|
| Default image tag version for every component. |
|
| Pull policy for the five MetaDefender Cluster images. The bundled PostgreSQL, Redis and RabbitMQ ignore it — each has its own |
| (unset) | List of pull secrets, e.g. |
The five images pulled are control-center, identity-service, file-storage, worker and installers. The installers runs only as the MetaDefender Cluster Control Center's initContainer.
Per-component settings
Key | Description |
|---|---|
| Image tag override for this component, e.g. |
| Desired pod count. Ignored for |
| Overrides the chart-wide policy. |
| Standard requests and limits. See Resource requirements. |
| Standard node selection. |
| Standard affinity and anti-affinity rules. |
| Standard taint tolerations. |
| Per-phase probe tuning. See Health probes. |
| Graceful shutdown window. Kubernetes default (30s) unless set; MetaDefender Cluster Workers default to 1800. |
Structural properties — Deployment versus StatefulSet, rollout strategy, pod security context, and whether a Service is headless — are fixed in the templates and not configurable. The Service settings that are exposed are listed below.
Service settings
Component | Key | Default | Notes |
|---|---|---|---|
|
|
|
|
|
| (auto-assigned) | Only applied when set; otherwise Kubernetes picks a port from |
|
| (unset — Kubernetes defaults to | Rarely changed — nothing outside the cluster needs it. |
|
| (unset → |
|
|
|
| The chart ships this as headless. Set to |
|
|
| External port; the target port is always |
The api-gateway Service is created by default — the chart ships service.clusterIP: None, so it exists as a headless Service until you change it. No other MetaDefender Cluster Worker may have one: setting service: on ometascan or callback-service fails the Helm render with an explicit error.
MetaDefender Cluster Worker specific settings
Key | Default | Description |
|---|---|---|
| per instance | Port the deployed instance listens on, passed to the pod as |
|
| Log level of the deployed instance. |
|
| Isolate the instance before undeploying it on shutdown, so in-flight work drains. |
|
| Seconds to wait for isolation to complete. |
| inherits the top-level flag | Run this instance's pre-upgrade Job on |
|
| Graceful shutdown window. Longer than other components because of isolation and undeploy. |
|
| Global opt-in to the per-instance pre-upgrade Jobs. Only takes effect on |
The map key under worker: is the instance type. Renaming ometascan to something else deploys a different (non-existent) instance type, not a renamed scan engine.
Bundled infrastructure
Key | Default | Description |
|---|---|---|
|
| Set to |
|
| |
|
| These three components ignore the chart-wide |
|
| |
|
| Database created on first start. The four cluster databases are created separately by the MetaDefender Cluster Control Center. |
|
| Raise this if you run many replicas. |
|
| Enable for any real deployment. |
|
| |
|
| Empty uses the cluster default. |
|
| |
|
| Set to |
|
| |
|
| |
|
| |
|
| |
|
| Set to |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| Number of MetaDefender Cluster File Storage pods. The chart builds the MetaDefender Cluster Control Center's endpoint list from this value at render time, so changing it requires |
|
| Enable for any real deployment. One PVC per replica. |
|
| Per replica, not total. |
| (unset) |
These three are single-pod deployments suitable for evaluation only. See High availability.
Secrets
Key | Default | Description |
|---|---|---|
| (empty) | Required. Must be exactly 32 characters — it is used directly as an AES-256 key, and the length is never validated. Empty stops the container immediately. Any other wrong length lets it launch but breaks every service registration, so the MetaDefender Cluster Control Center never becomes ready and ends up in |
| (empty) | Required. API key used for administrative and internal service calls. |
|
| Shared key between MetaDefender Cluster Control Center and MetaDefender Cluster Identity Service. Change this. |
|
| Shared key between MetaDefender Cluster Control Center and MetaDefender Cluster File Storage. Change this. |
|
| Shared key workers register with. Change this. |
|
| Bootstrap administrator account. |
|
| Change this. |
|
| |
| (empty) | Optional. See Licensing in Kubernetes. |
|
| MetaDefender Cluster Control Center database credentials. Also used as |
|
| Also used as |
|
| MetaDefender Cluster Identity Service database credentials. |
|
| Datalake database credentials. |
|
| Data warehouse database credentials. |
|
| Broker credentials. |
| (unset) | Optional; only needed if your Redis requires authentication. |
The connection keys are shared secrets, not per-service passwords: both sides of each link read the same value. Changing one after installation requires restarting both services involved.
The bundled PostgreSQL takes its superuser credentials from CONTROL_CENTER_DB_USER and CONTROL_CENTER_DB_PASSWORD, and that is the only role it creates. When using the bundled database, set all four credential pairs to the same values. If they differ, the MetaDefender Cluster Identity Service cannot log in and never becomes ready — which in turn crash-loops the MetaDefender Cluster Control Center — while the datalake and warehouse components stay unhealthy so the MetaDefender Cluster Control Center's own readiness check never passes.
Two consequences worth knowing before you install:
These credentials are applied only when PostgreSQL initialises an empty data directory. With
postgres.persistence.enabled: true, changingCONTROL_CENTER_DB_PASSWORDon a laterhelm upgradedoes not change the password inside the database, and every service then fails to authenticate. Change it withALTER ROLEin PostgreSQL, or delete thepostgresPVC to start fresh.An external PostgreSQL has no such coupling. The four pairs may name four different roles, as long as each can reach its database and one can create databases.
Environment
Rendered into the mdcluster-config ConfigMap. Defaults point at the bundled infrastructure.
Some variables are set directly on the pod by the templates, and a container-level value always wins over the ConfigMap. Setting these under env: is silently ignored on the very pod that reads them:
FILE_STORAGE_SERVICESon the MetaDefender Cluster Control Center — derived fromfile-storage.replicas.WORKER_INSTANCE_TYPE,WORKER_INSTANCE_PORT,WORKER_INSTANCE_LOG_LEVEL,WORKER_ISOLATE_INSTANCEandWORKER_ISOLATE_INSTANCE_TIMEOUTon worker pods — set these through the per-worker keyslistenPort,logLevelandisolate.*.
MetaDefender Cluster Control Center
Key | Default | Description |
|---|---|---|
|
| Also becomes the Service name. |
|
| Service port other components connect to. |
|
| Port inside the container. |
|
| |
|
| |
|
| MetaDefender Cluster Control Center service log level. |
|
| Rate limit. |
| — | Not supported. Unlike the MetaDefender Cluster Identity Service and MetaDefender Cluster File Storage equivalents, this is accepted but ignored — the MetaDefender Cluster Control Center always binds all interfaces. Setting it has no effect and produces no warning. |
MetaDefender Cluster Identity Service
Key | Default | Description |
|---|---|---|
|
| Also becomes the Service name. |
|
| |
|
| Bind address. |
|
| |
|
| |
|
| |
|
| MetaDefender Cluster Identity Service log level. |
MetaDefender Cluster File Storage
Key | Default | Description |
|---|---|---|
|
| Headless Service name; forms each replica's DNS name as |
|
| Bind address. |
|
| |
|
| MetaDefender Cluster File Storage log level. Applies to every replica. |
|
| Minimum copies of each file that must be written successfully — and the minimum number of MetaDefender Cluster File Storage instances that must be healthy. See the warning below. |
|
| How many copies of each file to write. Must be ≤ |
|
| Legacy single-value fallback for the two settings above. Deprecated — set the two explicitly instead. |
These are the file copy settings: FILE_STORAGE_MAX_REPLICA: 2 means every file is written to two MetaDefender Cluster File Storage instances, and each write picks up to that many instances. FILE_STORAGE_MIN_REPLICA: 2 means a write that reaches only one instance fails.
FILE_STORAGE_MIN_REPLICAalso gates the MetaDefender Cluster Control Center's own readiness. If fewer than this many MetaDefender Cluster File Storage instances are healthy, the MetaDefender Cluster Control Center reports MetaDefender Cluster File Storage unhealthy,/readyzstops returning 200, and it refuses writes and file lookups outright — it does not merely degrade.Because the MetaDefender Cluster Control Center's own startup waits for its
/readyzto return 200, setting this higher than the number of replicas you can keep healthy will crash-loop the MetaDefender Cluster Control Center on its next restart. Raise it only alongside enough replicas to sustain it.
FILE_STORAGE_MAX_REPLICA is validated against the number of MetaDefender Cluster File Storage instances registered with the MetaDefender Cluster Control Center, and only at the moment the setting is applied. Removing instances later does not re-validate it, so the ≤ file-storage.replicas rule can silently stop holding.
The two resolve independently, each in this order: its own value, then FILE_STORAGE_REPLICA_COUNT, then 1. An empty string counts as unset. The chart sets both explicitly, so the fallback only applies if you remove them. See Scaling.
MetaDefender Cluster Workers
Key | Default | Description |
|---|---|---|
|
| Shared headless Service name for all MetaDefender Cluster Worker instances. It is also the DNS suffix each MetaDefender Cluster Worker registers itself under ( |
|
| MetaDefender Cluster Worker agent port. Distinct from each instance's |
| (not set by the chart; the MetaDefender Cluster Worker image defaults to | License platform to match when activating. Add it under |
|
| Bind address of the MetaDefender Cluster Worker agent. |
|
| The MetaDefender Cluster Worker agent's own log level. |
Infrastructure endpoints
Key | Default | Description |
|---|---|---|
|
| Comma-separated |
|
| Comma-separated |
|
| Comma-separated |
|
| Comma-separated |
Global
Key | Default | Description |
|---|---|---|
|
| Seconds any service waits for a dependency before failing. Raise it on slow clusters or when external databases are slow to accept connections. |
Log levels
Accepted values, least to most severe: dump, debug, info, warning, error. Each service has its own key — CONTROL_CENTER_LOG_LEVEL, IDENTITY_LOG_LEVEL, FILE_STORAGE_LOG_LEVEL and WORKER_LOG_LEVEL, all defaulting to info. Logs go to the container's stdout, so kubectl logs is the only collection step needed.
Note the distinction on MetaDefender Cluster worker pods: WORKER_LOG_LEVEL sets the agent's level for every MetaDefender Cluster worker.
TLS certificates
MetaDefender Cluster Identity Service, MetaDefender Cluster File Storage and the MetaDefender Cluster Worker agents serve HTTPS. By default each generates a self-signed certificate for its own hostname at startup, so no configuration is needed for internal traffic.
To supply your own certificates, mount the PEM files into the pod and point both keys of a pair at the in-container paths. Setting only one key of a pair fails the container at startup.
Key | Default | Description |
|---|---|---|
| (unset) | MetaDefender Cluster Identity Service PEM certificate and private key. Leave both unset to auto-generate. |
| (unset) | Same, for MetaDefender Cluster File Storage. The same paths apply to every replica. |
| (unset) | Same, for the MetaDefender Cluster Worker agents. |
The chart does not create volume mounts for these files. You must add the mount yourself, or leave the keys unset and accept the generated certificates.
FILE_STORAGE_PATH is deliberately not configurable — it must stay at the PVC mount point, /app/storage.
Use external infrastructure
To run against existing PostgreSQL, Redis or RabbitMQ instead of the bundled single-pod deployments, disable the bundled component and repoint the endpoint. Both halves are required — disabling without repointing leaves the services pointed at a hostname that no longer resolves.
Two requirements on the external PostgreSQL:
The role must be able to create databases. The MetaDefender Cluster Control Center creates and migrates
md_cluster_control_center,md_cluster_datalake,md_cluster_datawarehouseandmd_cluster_identity_serviceon first start.Service names in a different namespace must be fully qualified:
<service>.<namespace>.svc.cluster.local.
For clustered external infrastructure with worked examples, see High Availability.