Skip to content

Authservice

Authservice integrates the upstream Authservice 1.1.8 release with Istio’s external authorization to provide OIDC login for selected Big Bang application routes. It is not a replacement for an application’s own authorization model.

Protection boundary

The chart creates RequestAuthentication plus ALLOW and CUSTOM AuthorizationPolicy resources in istio-system. By default, they select workloads labeled protect: keycloak; because istio-system is Istio’s root namespace, that selector can match workloads across the mesh. Treat selector changes as security-sensitive and use the umbrella’s protected-package mapping rather than applying the label broadly.

The umbrella owns package enablement, global identity-provider settings, client credentials, protected-service selection, and dependency ordering. Its canonical package key is authservice; the legacy value path is addons.authservice. The umbrella passes chart settings through packages.authservice.values and supplies additional chains through packages.authservice.chains. See the Big Bang Authservice values entry for the supported parent configuration.

A chain identifies a protected host match and its callback URI. The chart requires a callback URI for every rendered chain and gives chain-specific OIDC, client, session, and logout settings precedence over applicable global values. Use Secret references for client credentials where supported; do not place secrets in documentation or ordinary values files. The upstream Authservice configuration is authoritative for Authservice behavior.

Sidecar and ambient enforcement

CUSTOM external authorization is an L7 Envoy feature. In a sidecar deployment, the selected workload’s Envoy can enforce the policies. In ambient mode, ztunnel alone cannot enforce them. Deploy a downstream application waypoint or enforce at an Envoy ingress gateway; this package does not create a waypoint. The ambient guide describes the supported enforcement paths and bypass considerations.

Do not assume that labeling an ambient application pod protects traffic. Verify the enforcement point and test traffic that could bypass the selected waypoint or gateway.

Sessions and Redis

The default configuration uses in-process session state. Redis is optional and can be enabled with the bundled Redis dependency or by setting an external Redis URI at the global or chain level. Redis changes availability and network requirements: align the URI, credentials, Redis deployment choice, and network policy before scaling Authservice replicas.

The umbrella generates one outbound route for an external Redis host, preferring the global URI and otherwise the first chain URI. Configure explicit additional outbound routes for any other chain-specific Redis hosts. Keep endpoint and credential material in your deployment’s protected configuration.

Identity, mesh, and network integration

Additional JWT issuers are rendered into RequestAuthentication and AuthorizationPolicy resources. A host-restricted issuer excludes the primary and unrestricted issuers from its listed hosts. The chart also creates external ServiceEntries for configured issuer/JWKS endpoints; bb-common Istio behavior is configured under bb-common.istio. Review issuer host restrictions, egress, and certificate trust together. See additional issuers and network policy integration.

allow_unmatched_requests controls whether the CUSTOM policy matches all requests. When using custom policy rules instead, ensure each intended protected route is covered and validate access outcomes before deploying.

Operations

When enabled by the umbrella, the package can expose Redis metrics through the bundled Redis integration. The application itself does not add a custom Prometheus metrics endpoint; use the surrounding platform observability and Istio telemetry appropriate to your deployment. For operational investigation, start with the rendered policies, chain configuration, Envoy enforcement point, and Authservice logs; see troubleshooting.

The package’s chart-level checks validate rendered configuration and policies, not a live login, callback, session failover, or bypass-resistant enforcement path. Validate those flows in an authorized integration environment after any change to chains, issuers, Redis, selectors, or ambient topology.