Skip to content

ingress.yaml hardcodes pathType: Prefix, preventing use with regex paths on modern NGINX Ingress Controllers #441

@Aliskaa

Description

@Aliskaa

Description

The Ingress template (templates/ingress.yaml) hardcodes pathType: Prefix with no option to override it via values.yaml. This causes deployment failures when using regex-based paths (e.g., /?(.*), /api/?(.*)) with recent versions of the NGINX Ingress Controller that enforce strict path type validation.

Problem

In templates/ingress.yaml, the pathType is hardcoded:

{{- if $.Capabilities.APIVersions.Has "networking.k8s.io/v1" }}
pathType: Prefix
backend:
  service:
    name: {{ .serviceName }}
    port:
      number: {{ .servicePort }}
{{- end }}

Starting with NGINX Ingress Controller v1.x (chart ingress-nginx >= 4.x), the admission webhook performs strict validation between pathType and the actual path value. When pathType: Prefix is set, regex patterns like /?(.*) are rejected with an error similar to:

Error: UPGRADE FAILED: failed to create resource: admission webhook "validate.nginx.ingress.kubernetes.io" 
denied the request: spec.rules[0].http.paths[0].path: Invalid value: "/?(.*)": cannot be used with 
pathType Prefix

The only valid pathType for regex-based paths is ImplementationSpecific.

Expected Behavior

Users should be able to configure pathType per path entry in values.yaml, for example:

ingress:
  enabled: true
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$1
    nginx.ingress.kubernetes.io/use-regex: "true"
  hosts:
    - host: stackstorm.example.com
      paths:
        - path: /?(.*)
          pathType: ImplementationSpecific
          serviceName: stackstorm-st2web
          servicePort: 80
        - path: /auth/?(.*)
          pathType: ImplementationSpecific
          serviceName: stackstorm-st2auth
          servicePort: 9100
        - path: /api/?(.*)
          pathType: ImplementationSpecific
          serviceName: stackstorm-st2api
          servicePort: 9101
        - path: /stream/?(.*)
          pathType: ImplementationSpecific
          serviceName: stackstorm-st2stream
          servicePort: 9102

Proposed Fix

Make pathType configurable with a sensible default for backward compatibility:

# templates/ingress.yaml (proposed change)
{{- if $.Capabilities.APIVersions.Has "networking.k8s.io/v1" }}
pathType: {{ .pathType | default "Prefix" }}
backend:
  service:
    name: {{ .serviceName }}
    port:
      number: {{ .servicePort }}
{{- end }}

And update the default path entry in the else branch as well:

pathType: {{ $.Values.ingress.defaultPathType | default "Prefix" }}

Workaround

Currently, the only workaround is to:

  1. Set ingress.enabled: false in the Helm values
  2. Manually deploy the Ingress resource via kubectl apply with pathType: ImplementationSpecific

This breaks the GitOps/Helm-managed lifecycle of the Ingress resource.

Environment

  • Helm chart: stackstorm-ha v1.1.0 (also affects v0.110.0)
  • Kubernetes: v1.28+
  • NGINX Ingress Controller: v1.12.1 (chart ingress-nginx-4.12.1)
  • Admission webhook: validate.nginx.ingress.kubernetes.io with strict path validation enabled

Additional Context

Older Ingress resources created before the NGINX admission webhook was deployed (or before strict validation was enabled) continue to work with pathType: Prefix + regex paths. However, any new Ingress creation or modification that touches the paths section will be rejected by the webhook. This makes it impossible to deploy new StackStorm HA environments using the chart's Ingress feature when regex-based routing is needed.

Impact

  • ❌ Cannot use ingress.enabled: true with regex paths on clusters running modern NGINX Ingress Controllers
  • ❌ Forces manual Ingress management outside of Helm
  • ❌ Breaks infrastructure-as-code workflows

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions