Mattermost

Overview

This package deploys the Big Bang Mattermost application chart. The chart creates an installation.mattermost.com/v1beta1 Mattermost custom resource that is reconciled by the separately deployed Mattermost Operator. The operator, its CRDs, and its RBAC are owned by the Mattermost Operator package; this package owns the application custom resource and its Big Bang integration.

For Mattermost product administration, architecture, and feature behavior, see the Mattermost documentation. The bundled application version is recorded in the chart metadata.

Big Bang integration

When enabled through the umbrella’s packages.mattermost configuration (or the legacy addons.mattermost path), Mattermost is released to the mattermost namespace. The umbrella owns its Flux source, release pin, sensitive inputs, and dependency ordering. Mattermost is ordered after Mattermost Operator; MinIO Operator and Elasticsearch/Kibana are additional dependencies when their corresponding integrations are selected.

This chart configures the Mattermost custom resource, application route, network-policy and Istio resources through bb-common, an optional ServiceMonitor, and wait/test integration. See Granting Egress to Blocked Services for diagnosing and configuring external integration access.

Configuration entry points

The umbrella maps its Mattermost settings into this chart. Use the parent configuration keys below; do not copy product-specific nested configuration from upstream documentation into Big Bang values.

Integration	Big Bang entry point	Behavior
Enterprise	packages.mattermost.enterprise	Enables enterprise wiring and accepts either a Helm-managed license value or the name of an existing Secret. Do not commit license data. Product editions and entitlements are documented by Mattermost.
SSO	packages.mattermost.sso	Supplies the client identifier, secret, and identity-provider endpoints to the Mattermost environment Secret. Enable only with managed secret input; see the maintained Keycloak integration guide and Mattermost GitLab SSO documentation.
PostgreSQL	packages.mattermost.database	A complete external connection configuration causes the umbrella to create the database Secret; otherwise this chart deploys its chart-managed PostgreSQL dependency.
Object storage	packages.mattermost.objectStorage	A complete external S3-compatible configuration causes the umbrella to create the object-store Secret; otherwise this chart deploys its chart-managed MinIO dependency.
Monitoring	Global monitoring plus package monitoring settings	The chart renders a ServiceMonitor when monitoring and service monitoring are enabled. Metrics availability and licensing remain Mattermost product concerns.
Elasticsearch	packages.mattermost.elasticsearch	Enables the chart’s Elasticsearch integration. Configure and operate Elasticsearch according to the relevant Mattermost and Elasticsearch documentation.
Application overrides	packages.mattermost.values	Passes chart values to this Big Bang-owned Mattermost chart. Refer to the package values for supported package settings.

The canonical path above is used with packageConfiguration.version: v1. Existing legacy configurations remain supported through addons.mattermost.

Granting Egress to Blocked Services

External services configured in the Mattermost System Console, such as an S3-compatible file store or an integration endpoint, may also require mesh and NetworkPolicy configuration. Successful configuration in the UI does not grant network access from the Mattermost pods.

In sidecar mode, traffic captured by an Istio proxy using REGISTRY_ONLY can be denied when its destination is not registered in the mesh. The package exposes this policy through bb-common.istio.sidecar.outboundTrafficPolicyMode; rendering a Sidecar resource does not itself inject a proxy. Check the actual namespace enrollment, pod injection, capture exceptions, and effective policy before attributing a connection failure to Istio. Existing outbound routes already register selected Mattermost services, and the umbrella configures the SSO route when SSO is enabled; additional destinations are not automatically registered because they were entered in the UI.

Discovering Blocked Hosts

Confirm the intended kubeconfig and namespace before these read-only checks. List application pods using the chart’s default label, adjusting the selector if the application name was overridden:

kubectl -n mattermost get pods -l app.kubernetes.io/name=mattermost --show-labels

Choose an application pod from that list, then inspect its containers:

SOURCE_POD="replace-with-application-pod-name"
kubectl -n mattermost get pod "$SOURCE_POD" \
  -o jsonpath='{.spec.containers[*].name}{"\n"}{.spec.initContainers[*].name}{"\n"}'

If it has an istio-proxy container, reproduce the failed integration request and inspect recent proxy logs:

kubectl -n mattermost logs "$SOURCE_POD" -c istio-proxy --since=10m \
  | grep -i 'BlackHoleCluster'

BlackHoleCluster entries can identify unregistered destinations when proxy access logging is enabled. No matching entries do not establish connectivity: check application errors, DNS, NetworkPolicies, and TLS trust as well. In ambient mode there may be no application-pod proxy; use the umbrella’s ambient guidance and inspect the relevant ztunnel/waypoint path instead. Redact sensitive URLs and request metadata before sharing logs.

Registering External Destinations

Add only the hosts and ports required by the integration to the package’s bb-common.routes.outbound mapping. For example, these umbrella values register one HTTPS destination; replace api.example.com with the actual host:

packageConfiguration:
  version: v1
packages:
  mattermost:
    values:
      bb-common:
        routes:
          outbound:
            external-integration:
              enabled: true
              hosts:
                - api.example.com
              ports:
                - number: 443
                  name: https
                  protocol: TLS

This assumes the umbrella already configures the mesh; it does not enable injection. With the Istio networking API available, bb-common renders a namespace-local ServiceEntry for the destination. Existing routes are retained when adding this new mapping. Legacy umbrella configurations use addons.mattermost.values.bb-common.routes.outbound; direct chart installations use bb-common.routes.outbound without the umbrella nesting. Advanced custom ServiceEntries use the package’s bb-common.istio.serviceEntries.custom interface, not the old package istio.hardened.customServiceEntries example.

Mesh registration and network permission are separate controls. For direct external access, this route does not itself allow the destination IP and port through an enabled NetworkPolicy. Review the package’s bb-common.networkPolicies.egress rules and the destination’s DNS/IP behavior. If an egress waypoint is configured, also review that waypoint’s authorization and network path. Do not switch to ALLOW_ANY or broad internet egress as a routine fix. Commit the narrowly scoped configuration through GitOps and verify the actual Mattermost integration afterward; a rendered ServiceEntry is not proof of delivery.

For shared configuration details, consult the bundled bb-common 1.6.0 routes, Istio, and NetworkPolicy guides. Match those references to the dependency in Chart.yaml when using another package version.

Storage and operations

Mattermost state spans PostgreSQL and object storage. Plan backups, restores, upgrades, and rollbacks for both stores; an application rollback does not undo database migrations. For product upgrade preparation and compatibility details, use Mattermost’s upgrade guidance and important upgrade notes.

The package wait integration depends on the Mattermost custom resource reaching its stable state. Local chart rendering does not verify operator reconciliation, SSO trust, licenses, external storage, data durability, or disaster recovery. Use the package’s development and maintenance guide when performing a package upgrade or integration test.

Scheduling

The chart exposes node selection, affinity, anti-affinity, and tolerations for the Mattermost application custom resource. See Scheduling Mattermost for the supported package values and link to Kubernetes documentation for the underlying scheduling concepts.

See the Big Bang 4.0 migration guide before upgrading.