Istio hardening with bb-common

Loki uses the bb-common subchart for PeerAuthentication, Sidecar, AuthorizationPolicy, ServiceEntry, and route resources. The examples below are direct Loki chart values. For Big Bang umbrella values, place them under packages.loki.values. The migration guide shows a complete umbrella example and how to upgrade root-level istio, networkPolicies, or routes overrides.

Prerequisites and REGISTRY_ONLY egress

Install Istio and inject Loki’s workload pods before enabling mesh policies. The umbrella manages injection; enabling bb-common.istio.enabled alone does not inject pods in a direct chart installation.

bb-common:
  istio:
    enabled: true
    mtls:
      mode: STRICT
    sidecar:
      enabled: true
      outboundTrafficPolicyMode: REGISTRY_ONLY
    authorizationPolicies:
      enabled: true

The Sidecar permits outbound traffic only to destinations registered with Istio. Kubernetes Services are normally registered automatically; external object storage and other external endpoints may need explicit ServiceEntries. NetworkPolicies remain a separate layer of enforcement. Do not enable the Sidecar resource in ambient mode.

Register an external destination

For example, add an external HTTPS destination with a custom ServiceEntry:

bb-common:
  istio:
    enabled: true
    sidecar:
      enabled: true
    serviceEntries:
      custom:
        - name: allow-external-api
          enabled: true
          spec:
            hosts:
              - api.example.mil
            location: MESH_EXTERNAL
            ports:
              - number: 443
                protocol: TLS
                name: https
            resolution: DNS

Replace the hostname with the required destination and configure matching network-policy egress when NetworkPolicies are enabled. See the Istio ServiceEntry reference for the resource specification.

Authorization policies

With bb-common.istio.authorizationPolicies.enabled: true, bb-common creates default-deny and same-namespace allow policies. It can generate additional allow policies from supported ingress network-policy rules, including the configured Alloy, Grafana, and Prometheus identities. A denied request can return 403 RBAC: access denied.

Custom policies are additive. For example, this allows Alloy to push logs to the selected Loki workloads; it does not remove other generated allow rules:

bb-common:
  istio:
    enabled: true
    authorizationPolicies:
      enabled: true
      custom:
        - name: allow-loki-push-only
          enabled: true
          spec:
            selector:
              matchLabels:
                app.kubernetes.io/name: logging-loki
            action: ALLOW
            rules:
              - from:
                  - source:
                      namespaces:
                        - alloy
                to:
                  - operation:
                      methods: [POST]
                      paths: [/loki/api/v1/push]

Review all policies affecting the workload before relying on a path restriction. Istio applies matching CUSTOM and DENY policies before ALLOW policies. See the AuthorizationPolicy reference.

Loki VirtualService access

The Loki VirtualService remains disabled by default with bb-common.routes.inbound.loki.enabled: false. Enabling it exposes the log API (reads and writes) to clients that can reach the gateway. Pair external access with appropriate authentication and authorization; generated integration allow rules are not a substitute for reviewing the ingress gateway’s access.

bb-common:
  istio:
    enabled: true
    authorizationPolicies:
      enabled: true
  routes:
    inbound:
      loki:
        enabled: true

The umbrella maps the route to the monolith service or the scalable gateway for the selected strategy. For a direct chart installation, also configure the route’s service, port, container port, and selector for your deployment mode. Use global.domain to change the default templated hostname or set the route’s hosts explicitly.