Skip to content

MinIO tenant

This package deploys a MinIO Tenant for S3-compatible object storage. It wraps the upstream MinIO Operator tenant chart and adds Big Bang integration resources. For MinIO product architecture, administration, and tenant configuration, use the MinIO Kubernetes documentation and the versioned tenant chart values.

Tenant and operator boundary

This repository owns the tenant chart, tenant data-plane integration resources, and its package tests. The separate MinIO Operator package owns the controller and CRDs. The Big Bang umbrella deploys the tenant into the minio namespace and ensures the operator release is available; the tenant HelmRelease depends on that operator release.

Enable the tenant with the canonical packages.minio configuration. The legacy addons.minio path remains supported for the current compatibility contract. Use the package values entry point to pass configuration to this chart. General tenant-chart configuration belongs under upstream; shared network, route, and Istio settings belong under bb-common. Big Bang-owned monitoring, bucketInit, waitJob, and bbtests settings remain top-level values. See the Big Bang values documentation for package configuration and source selection.

Storage and tenant configuration

The default tenant pool uses persistent volumes. Pool definitions are arrays, so an override replaces the default pool list rather than merging with it. Repeat all required pool fields, including hardened pod and container security contexts, when overriding a pool. Server count, volumes per server, volume size, storage class, and placement affect PVCs, erasure layout, capacity, and failure tolerance; treat changes to them as data migrations rather than routine value updates.

The wrapper uses the locked upstream tenant chart version shown in Chart.yaml. Configure tenant-specific settings through upstream.tenant and consult the versioned upstream values for supported fields. For pool placement guidance, see Affinity. Plan backups and prove restores before changing storage or upgrading; see Backups and disaster recovery.

Authentication and bucket initialization

By default, the chart renders the minio-access Secret from upstream.tenant.configSecret. Prefer an externally managed, encrypted Secret for production credentials and select it through the upstream tenant configuration. Do not commit access keys or secret keys in values files.

When bucketInit.enabled is enabled and upstream.tenant.buckets declares buckets, this package renders a post-install/post-upgrade Job that waits for the tenant and creates those buckets through the configured S3 endpoint. Coordinate the endpoint and TLS configuration with the tenant, and keep credentials out of logs. This is a package-specific workaround for environments where namespace admission webhooks interfere with MinIO Operator reconciliation; it is not a replacement for upstream bucket lifecycle administration.

Networking, routes, and Istio

The default network-policy configuration permits cluster consumers to reach the tenant S3 API on port 9000. Restrict this for production consumers and coordinate any change with dependent packages. The bb-common subchart renders resources configured through bb-common.networkPolicies, bb-common.routes, and bb-common.istio; configure those values rather than duplicating generated resources. See the bb-common network policy guide, routes guide, and Istio guide.

The umbrella supplies API and console route defaults when it deploys the tenant. If restrictive Istio outbound policy is used, explicitly authorize any external service that tenant workloads must reach using the applicable bb-common Istio configuration.

Granting Egress to Blocked Services

Tenant integrations such as an external identity provider, notification target, or replication peer may need explicit network and mesh configuration. Entering an endpoint in MinIO configuration or the Console does not grant connectivity. Check which tenant workload makes the request; traffic from a separate client or the MinIO Operator has a different source and policy boundary.

In sidecar mode, traffic captured by a proxy with effective REGISTRY_ONLY policy can be denied if its destination is unregistered. The shared interface is bb-common.istio.sidecar.outboundTrafficPolicyMode; rendering a Sidecar does not inject a proxy. Check actual pod injection, namespace enrollment, and capture exceptions.

Discovering Blocked Hosts

Confirm the intended kubeconfig. List tenant pods with their operator-managed tenant label, then select a pod belonging to the affected Tenant:

kubectl -n minio get pods -l v1.min.io/tenant --show-labels

Inspect the selected pod’s regular and init containers:

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

If it has an istio-proxy, inspect recent proxy logs during the failing integration request:

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

With proxy access logging enabled, BlackHoleCluster entries can help identify unregistered destinations. No match does not prove connectivity: inspect tenant errors, DNS, NetworkPolicies, TLS trust, and remote authentication too. In ambient mode, inspect the relevant ztunnel/waypoint path rather than assuming a pod proxy; see the umbrella’s ambient guidance. Redact credentials, signed URLs, and object metadata before sharing logs.

Configuring Istio with bb-common

These umbrella values register one HTTPS destination through the supported custom ServiceEntry interface. Replace the example host with the actual integration host, and review any additional destinations separately:

packageConfiguration:
  version: v1
packages:
  minio:
    values:
      bb-common:
        istio:
          enabled: true
          serviceEntries:
            custom:
              - name: tenant-integration
                spec:
                  hosts:
                    - integration.example.com
                  exportTo: ["."]
                  location: MESH_EXTERNAL
                  resolution: DNS
                  ports:
                    - number: 443
                      name: https
                      protocol: TLS

The mesh and its APIs must already be available; this does not enable injection or configure the MinIO integration. Legacy umbrella values use addons.minio.values.bb-common.istio; direct chart values omit the umbrella nesting but retain the bb-common.istio prefix. The custom array replaces existing entries, so retain those still needed.

ServiceEntries do not grant destination IP/port access through NetworkPolicies. Review bb-common.networkPolicies.egress for the affected tenant selector, including DNS access and the destination’s changing IPs. Do not switch to ALLOW_ANY or broad internet egress as a routine fix. Commit reviewed configuration through GitOps and verify the actual integration with disposable data; do not use replication testing against production objects as a connectivity probe.

See the bundled bb-common 1.6.1 Istio and NetworkPolicy guides; match the version to Chart.yaml.

Metrics and operations

Set monitoring.enabled to render the package Grafana dashboard and enable the corresponding tenant metrics configuration. For metric definitions and Prometheus collection details, use the MinIO monitoring documentation.

The default wait Job observes Tenant health. Optional live tests perform an S3 object round trip and should run only against disposable data. Consult Troubleshooting for basic tenant inspection, and do not use documentation examples as a substitute for a tested backup and restore plan.