You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
service-route.yaml has servicePort hardcoded (8200), and should be equivalent of service-ingress.yaml. Additionally, passthrough is selected for tls termination, but by default 8200 is not a secure port, so same as ingress should apply.
To Reproduce
Steps to reproduce the behavior:
Install chart in OpenShift with server.route.enabled=true and ui.enabled=true
Try to access the url
When route tls is deleted, the ui is accessed without any issues.
Expected behavior
Route configuration consistent with ingress.
Environment
Kubernetes version:
Distribution or cloud vendor (OpenShift, EKS, GKE, AKS, etc.): OpenShift 4.7
Other configuration options or runtime services (istio, etc.): N/A
In general the helm chart lacks of the ability to customize the ingress/route for OpenShift, e.g. currently it is not possible to switch to a reencrypt route.
Also i would prefer to use a Ingress object, because this object has some advantages over to the route object (e.g. external tls secret).
OpenShift 4 automatically creates route objects when you try to create an ingress object. Currently the chart ignores the Ingress configuration when global.openshift is true.
This covers, in part, issue hashicorp#490. Namely, the route currently hardcodes
the termination mode to "passhtrough". Let's parametrize this so a user
can customize it. The use-case here being that we can deploy the vault
in http mode and expose it via https externally and by choosing 'edge'
as the termination type we let the TLS be taken care of by the route
object.
The default remains 'passthrough' in order to not disrupt any existing
setup.
Describe the bug
service-route.yaml has servicePort hardcoded (8200), and should be equivalent of service-ingress.yaml. Additionally, passthrough is selected for tls termination, but by default 8200 is not a secure port, so same as ingress should apply.
To Reproduce
Steps to reproduce the behavior:
When route tls is deleted, the ui is accessed without any issues.
Expected behavior
Route configuration consistent with ingress.
Environment
Chart values:
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: