I am using istioingress gateway. How can I redirect non-www traffic to www?
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: my-gateway
namespace: some-config-namespace
spec:
selector:
app: my-gateway-controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- uk.bookinfo.com
- eu.bookinfo.com
- www.uk.bookinfo.com
- www.eu.bookinfo.com
tls:
httpsRedirect: true # sends 301 redirect for http requests
- port:
number: 443
name: https-443
protocol: HTTPS
hosts:
- uk.bookinfo.com
- eu.bookinfo.com
- www.uk.bookinfo.com
- www.eu.bookinfo.com
tls:
mode: SIMPLE # enables HTTPS on this port
serverCertificate: /etc/certs/servercert.pem
privateKey: /etc/certs/privatekey.pem
Currently, I am able to access the website using both endpoints. But, I want to redirect all traffic from non-www to www.
Istio Gateway receives the traffic, and the routing from there will be handled by VirtualService configuration. For your non-www to www traffic routing, the same question was raised in Istio discussion forum, so that may be of your help.
https://discuss.istio.io/t/simply-redirecting-non-www-to-www/3370
As to getting all the traffic, you may want to use a wildcard in the hosts definition in the Gateway configuration (ref: https://istio.io/docs/reference/config/networking/gateway/#Server).
Have you tried redirect feature of Istio?
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: server-vs
spec:
hosts:
- mysite.com
gateways:
- my-gateway
http:
- match:
- uri:
exact: /
redirect:
uri: /
authority: www.mysite.com
Also you could have done the redirection at DNS level. But I think some domain providers don't support it. Godaddy, for example, does.
Related
I am using Istio with mTLS enabled.
I am trying to mock some external requests using a mock service deployed inside my cluster.
For example, I want all requests to https://httpbin.org redirect to my internal service http://mock.default.svc.cluster.local
My mock service is a simple webservice serving on 80 port.
I was able to do this using service entry & virtualservices for http requests, but I also want to be able to do the same thing for https requests.
Here's my setup:
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: httpbin-ext
spec:
hosts:
- httpbin.org
ports:
- number: 80
name: http
protocol: HTTP
- number: 443
name: https
protocol: HTTPS
resolution: DNS
location: MESH_EXTERNAL
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: httpbin-mock
spec:
hosts:
- httpbin.org
http:
- route:
- destination:
host: mock.default.svc.cluster.local
tls:
- match:
- port: 443
sniHosts:
- httpbin.org
route:
- destination:
host: mock.default.svc.cluster.local
port:
number: 80
But when I curl the https://httpbin.org, I got the following error:
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
I am guessing it's because on my mock service 80 port, no one is handling the https protocol.
What's the best approach to do this? A self-signed nginx and destination rule with certificates? Or there's a better way?
I'm trying to migrate from ingress to istio gateway + virtual service routing, but I keep receiving a 404 Not Found error.
The only link that the app should be accessed to is using my-todos.com, configured locally.
What am I missing here?
Note: the ingress controller works just fine. Initially, todo-lb.default.svc.cluster.local in the istio.yaml file was just set to todo-lb, representing the configured load balancer, still with no success.
Here is the ingress.yaml file (to migrate from):
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: todo-ingress
spec:
rules:
- host: my-todos.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: todo-lb
port:
number: 3001
- path: /api
pathType: Prefix
backend:
service:
name: {{ .Values.api.apiName }}
port:
number: {{ .Values.api.apiPort }}
Here is the istio.yaml file (to migrate TO):
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: todo-istio-gateway
namespace: istio-system
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- my-todos.com
# - "*"
tls:
httpsRedirect: true
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: tls-secret
hosts:
- my-todos.com
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: todo-lb
spec:
hosts:
- my-todos.com
# - "*"
gateways:
- todo-istio-gateway
http:
- match:
- uri:
prefix: /
route:
- destination:
host: todo-lb.default.svc.cluster.local
port:
number: 3001
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: todo-api
spec:
hosts:
- my-todos.com
# - "*"
gateways:
- todo-istio-gateway
http:
- match:
- uri:
prefix: /api
route:
- destination:
host: {{ .Values.api.apiName }}
port:
number: {{ .Values.api.apiPort }}
From what I see you've wrong gateway configuration in your virtual service, that's why it might not work.
If gateway is not in the same namespace as virtual service, you have to specify that in virtual service
Check the spec.gateways section
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: bookinfo-Mongo
spec:
gateways:
- some-config-namespace/my-gateway # can omit the namespace if gateway is in same
namespace as virtual service.
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: my-gateway
namespace: some-config-namespace
There is related istio documentation about that.
So please move your todo-istio-gateway to default namespace.
or use
gateways:
- istio-system/todo-istio-gateway
Few things to check if that won't help:
Is your app deployed in default namespace?
Is your app injected?
Problem might be with your Gateway api:
404 errors occur when multiple gateways configured with same TLS certificate
Configuring more than one gateway using the same TLS certificate will cause browsers that leverage HTTP/2 connection reuse (i.e., most browsers) to produce 404 errors when accessing a second host after a connection to another host has already been established.
For example, let’s say you have 2 hosts that share the same TLS certificate like this:
Wildcard certificate .test.com installed in istio-ingressgateway
Gateway configuration gw1 with host service1.test.com, selector istio: ingressgateway, and TLS using gateway’s mounted (wildcard) certificate
Gateway configuration gw2 with host service2.test.com, selector istio: ingressgateway, and TLS using gateway’s mounted (wildcard) certificate
VirtualService configuration vs1 with host service1.test.com and gateway gw1
VirtualService configuration vs2 with host service2.test.com and gateway gw2
Since both gateways are served by the same workload (i.e., selector istio: ingressgateway) requests to both services (service1.test.com and service2.test.com) will resolve to the same IP. If service1.test.com is accessed first, it will return the wildcard certificate (.test.com) indicating that connections to service2.test.com can use the same certificate. Browsers like Chrome and Firefox will consequently reuse the existing connection for requests to service2.test.com. Since the gateway (gw1) has no route for service2.test.com, it will then return a 404 (Not Found) response.
You can avoid this problem by configuring a single wildcard Gateway, instead of two (gw1 and gw2). Then, simply bind both VirtualServices to it like this:
Gateway configuration gw with host *.test.com, selector istio: ingressgateway, and TLS using gateway’s mounted (wildcard) certificate
VirtualService configuration vs1 with host service1.test.com and gateway gw
VirtualService configuration vs2 with host service2.test.com and gateway
checkout this link:
https://istio.io/latest/docs/ops/common-problems/network-issues/#404-errors-occur-when-multiple-gateways-configured-with-same-tls-certificate
In addition to #Jakub answer, there can be one more reason you can get 404 error. Your current ingress rules in virtual service looks like this:
Hostname
Path
Route
my-todos.com
/
Forward to todo-lb.default.svc.cluster.local
my-todos.com
/api
Forward to {{ .Values.api.apiName }}
In Istio, each of the above is an ingress rule. If in Istio ingress-gateway, the rules are added in the above order, then all the URL path including the prefix /api gets routed to the first service i.e. todo-lb.default. It is better to create a single Virtual service like this and then see if the routing works as expected.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: todo-api
spec:
hosts:
- my-todos.com
gateways:
- <namespace>/todo-istio-gateway
http:
- match:
- uri:
prefix: /api
route:
- destination:
host: {{ .Values.api.apiName }}
port:
number: {{ .Values.api.apiPort }}
- match:
- uri:
prefix: /
route:
- destination:
host: todo-lb.default
port:
number: 3001
Cors preflight requests do not work when a Jwt Policy is configured on the istio-ingressgateway target.
Gateway
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: api-gateway
namespace: foo
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "api.example.com"
tls:
httpsRedirect: true # sends 301 redirects for http requests
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
privateKey: /etc/istio/ingressgateway-certs/tls.key
hosts:
- "api.example.com"
Virtual Service
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: backend-vs
namespace: foo
spec:
hosts:
- "api.example.com"
gateways:
- api-gateway
http:
- match:
- uri:
prefix: /api/v1/info
route:
- destination:
host: backend.foo.svc.cluster.local
corsPolicy:
allowOrigin:
- "https://app.example.com"
allowMethods:
- POST
- GET
- PUT
- DELETE
- PATCH
- OPTIONS
allowHeaders:
- authorization
- content-type
- accept
- origin
- user-agent
allowCredentials: true
maxAge: 300s
Security
apiVersion: "security.istio.io/v1beta1"
kind: "RequestAuthentication"
metadata:
name: "jwt-example"
namespace: foo
spec:
selector:
matchLabels:
app: backend
jwtRules:
- issuer: "http://keycloak.foo/auth/realms/example"
jwksUri: "http://keycloak.foo/auth/realms/example/protocol/openid-connect/certs"
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: require-jwt-example
namespace: foo
spec:
selector:
matchLabels:
app: backend
action: ALLOW
rules:
- from:
- source:
requestPrincipals: ["http://keycloak.foo/auth/realms/example/http://keycloak.foo/auth/realms/example"]
when:
- key: request.auth.claims[groups]
values: ["group1"]
when I test the web application in firefox it works fine, but in other browsers like opera, chrome, safari, it fails with the following error:
Access to XMLHttpRequest at 'https://api.example.com/api/v1/info' from origin 'https://app.example.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
What makes me more thoughtful is because in firefox it works well but in other browsers it fails
NOTE: To validate that the cors policy was correct in istio, what I did was disable this policy in istio and test in firefox to see what was happening, the result was that a problem with cors did indeed come out, but when I re-enabled the cors in istio when rerunning in firefox the request works fine.
Good after doing segmented tests and see what was causing the error, I found that the problem appeared when I created the keycloak gateway (keycloak.example.com) that was running on the same service port (backend.example.com) , which by default for https is 443 and for http is 80.
What I did was expose keycloak to another port on the gateway (ingressgateway). with the above and the angular application I stop putting problem of the cors.
We want to to route https traffic to an https endpoint using Istio Ingress Gateway.
We terminate the TLS traffic at the Ingress Gateway, but our backend service uses https as well.
I have the following manifests:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: datalake-dsodis-istio-gateway
spec:
selector:
istio: ingressgateway
servers:
- hosts:
- "gw-hdfs-spark.dsodis.domain"
- "spark-history.dsodis.domain"
port:
name: https-wildcard
number: 443
protocol: HTTPS
tls:
mode: SIMPLE
serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
privateKey: /etc/istio/ingressgateway-certs/tls.key
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: gw-spark-history-istio-vs
spec:
gateways:
- default/datalake-dsodis-istio-gateway
hosts:
- "spark-history.dsodis.domain"
http:
- match:
- uri:
prefix: /
route:
- destination:
host: gateway-svc-clusterip.our_application_namespace.svc.cluster.local
port:
number: 8443
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: originate-tls-for-spark-history
spec:
host: gateway-svc-clusterip.our_application_namespace.svc.cluster.local
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 8443
tls:
mode: SIMPLE
The problem is most likely, that we are sending TLS terminated traffic, (so to say) HTTP traffic, to the HTTPS backend. Therefore we might get 503 Service Unavailable when accessing the service through Istio.
The command accessing it is:
curl -vvvv -H"Host: spark-history.dsodis.domain" --resolve "spark-history.dsodis.domain:31390:IP" https://spark-history.dsodis.domain:31390/gateway/default/sparkhistory -k
My question is, how can I tell Istio to route traffic to the backend service using https?
Thanks in advance.
Best regards,
rforberger
As RonnyForberger mentioned in his comment this can be achieved by creating DestinationRule that tells the traffic to the destination service to be TLS connection.
So in this scenario:
HTTPS request gets TLS terminated at GateWay to HTTP.
Then the HTTP request is translated to TLS with DestinationRule to HTTPS.
HTTPS request reaches HTTPS backend.
I installed Istio with
gateways.istio-egressgateway.enabled = true
I have a service that consumes external services, so I define the following egress rule.
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-service1
spec:
hosts:
- external-service1.com
ports:
- number: 80
name: http
protocol: HTTP
- number: 443
name: https
protocol: HTTPS
resolution: DNS
location: MESH_EXTERNAL
But using Jaeger I can not see the traffic to the external service, and thus be able to detect problems in the network.
I'm forwarding the appropriate headers to the external service (x-request-id, x-b3-traceid, x-b3-spanid, b3-parentspanid, x-b3-sampled, x-b3-flags, x-ot-span-context)
Is this the correct behavior?
what is happening?
Can I only have statistics of internal calls?
How can I have statistics for egress traffic?
Assuming that your services are defined in Istio’s internal service registry. If not please configure it according to instruction service-defining.
In HTTPS all the HTTP-related information like method, URL path, response code, is encrypted so Istio cannot see and cannot monitor that information for HTTPS.
If you need to monitor HTTP-related information in access to external HTTPS services, you may want to let your applications issue HTTP requests and configure Istio to perform TLS origination.
First you have to redefine your ServiceEntry and create VirtualService to rewrite the HTTP request port and add a DestinationRule to perform TLS origination.
kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-service1
spec:
hosts:
- external-service1.com
ports:
- number: 80
name: http-port
protocol: HTTP
- number: 443
name: http-port-for-tls-origination
protocol: HTTP
resolution: DNS
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: external-service1
spec:
hosts:
- external-service1.com
http:
- match:
- port: 80
route:
- destination:
host: external-service1.com
port:
number: 443
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: external-service1
spec:
host: external-service1.com
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
portLevelSettings:
- port:
number: 443
tls:
mode: SIMPLE # initiates HTTPS when accessing external-service1.com
EOF
The VirtualService redirects HTTP requests on port 80 to port 443 where the corresponding DestinationRule then performs the TLS origination. Unlike the previous ServiceEntry, this time the protocol on port 443 is HTTP, instead of HTTPS, because clients will only send HTTP requests and Istio will upgrade the connection to HTTPS.
I hope it helps.