Istio Ingress Fails for Redis on Kubernetes with Partial Wildcard Hostnames – Redis Knowledge Base

When deploying a RedisEnterpriseCluster (REC) with Istio ingress (ingressOrRouteSpec.method=istio) on Kubernetes, ingressOrRouteSpec.dbFqdnSuffixshould be set to a dot-prefixed subdomain to prevent the Istio validation webhook from rejecting the generated configurations.

Otherwise, the generated configuration would contain a pattern with a partial wildcard, which Istio does not support.

A partial wildcard occurs when a wildcard (*) appears in the middle of or as part of a domain, rather than as a full subdomain prefix — for example: *foo.example.com or foo.*.example.com

Istio only allows full subdomain wildcards that replace exactly one DNS label at the start of the host — for example: *.example.com

This guide explains how to:
Identify and understand the error, use supported hostname patterns, configure Istio-based external routing, troubleshoot ingress and DNS issues, and apply best practices for stable external routing.

Prerequisites

Redis Enterprise Operator 7.22.0 or later
Kubernetes cluster with Istio 1.24 or later
Access to modify and apply REC manifests
Ability to update DNS records and TLS certificates
Familiarity with Ingress, Istio Gateway, or OpenShift Route

Quick Fix Table

Issue	Likely Cause	Fast Fix
Istio webhook error: “partial wildcard not allowed”	It means that a Kubernetes resource (like a VirtualService, Gateway, or DestinationRule) is using a host or domain pattern with a partial wildcard.	Use a valid full wildcard (e.g., `*.redis.example.com`) or an explicit hostname
Database ingress fails to reconcile	`dbFqdnSuffix` is not set to a dot-prefixed subdomain	Use a dot-prefixed subdomain instead (e.g., `.redis.example.com`)
TLS SNI mismatch after fix	Certificate doesn’t include new SANs	Regenerate or update TLS certificates to match the new FQDNs
DNS resolution fails	Wildcard DNS not configured	Create a `*.redis.example.com` A/AAAA record pointing to the Istio ingress gateway

Istio Hostname Wildcard Restrictions

Partial Wildcards Not Supported
Hostnames such as *-myhost.example.com or myhost-*.example.com are invalid.
Istio only allows full leftmost wildcards (e.g., *.example.com) or absolute FQDNs.

Example Error:

admission webhook "validation.istio.io" denied the request: configuration is invalid: partial wildcard "*-redis.example.com" not allowed

Scope of Restriction
This limitation applies to Istio Gateway and VirtualService resources.
Other ingress controllers such as NGINX, HAProxy, and OpenShift Route do not enforce this rule.

Supported External Routing Methods

Method	Partial Wildcards Supported?	Notes
Istio	❌ No	Only leftmost `*.` wildcards or full FQDNs allowed
NGINX / HAProxy	✅ Yes	Flexible patterns supported
OpenShift Route	✅ Yes	No wildcard restrictions

Configure External Routing with Istio

Install Istio and Redis Enterprise Operator
Follow the Configure Istio for external routing to install both components.
Configure DNS Records
Create wildcard or explicit DNS records (for example, *.redis.example.com) pointing to the Istio ingress gateway’s external IP or load balancer hostname.
Edit the REC Specification
```
ingressOrRouteSpec:
  method: istio
  apiFqdnUrl: api.redis.example.com
  dbFqdnSuffix: .redis.example.com
```
✅ Use a dot-prefixed suffix (e.g., .redis.example.com).
❌ Avoid hyphenated suffixes such as -redis.example.com.

Create the Istio Gateway

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: redis-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - hosts:
        - '*.redis.example.com'
      port:
        number: 443
        name: https
        protocol: HTTPS
      tls:
        mode: PASSTHROUGH

Create the VirtualService

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: redis-vs
spec:
  gateways:
    - redis-gateway
  hosts:
    - '*.redis.example.com'
  tls:
    - match:
        - port: 443
          sniHosts:
            - api.redis.example.com
      route:
        - destination:
            host: rec1
            port:
              number: 9443
    - match:
        - port: 443
          sniHosts:
            - db1.redis.example.com
      route:
        - destination:
            host: db1

Replace hostnames and ports as needed for your environment.

Apply the Resources

kubectl apply -f gateway.yaml
kubectl apply -f virtualservice.yaml

Verify External Access

openssl s_client -connect api.redis.example.com:443 -servername api.redis.example.com

Confirm a successful TLS handshake and correct SNI.

Troubleshooting

Validation Error
Update dbFqdnSuffix to use a full FQDN or leftmost wildcard only.
The apiFqdnUrl parameter should remain a fixed FQDN. Wildcards are not supported for this field.

DNS or Certificate Issues
Ensure wildcard DNS and certificates match the updated FQDNs.

TLS Handshake Failures
Verify that clients use the correct SNI and trust the proper CA.

Alternative Routing Options
If you require partial wildcards, use NGINX, HAProxy, or OpenShift Route instead of Istio.

Best Practices

Always use valid FQDNs or full leftmost wildcards in Istio Gateway hosts.
Document hostname conventions in internal deployment guides.
Keep Istio and Redis Operator versions aligned.
Review Istio hostname validation behavior when upgrading versions.
For OpenShift environments, Route provides simpler wildcard flexibility.

Verification

No Istio webhook errors in kubectl describe rec/<name> output.
Gateway and VirtualService show status: Ready.
DNS resolves correctly and TLS connections succeed.

Key Takeaway

When using Istio ingress for Redis on Kubernetes, avoid partial wildcard hostnames in your REC configuration.
Use only valid FQDNs or leftmost wildcards for Istio compatibility and stable external routing.

Related to