I am trying to add ext_authz filter to istio ingress-gateway for requests authentication. But when I'm adding this filter to cluster it seems like it is not added to envoy configuration, i.e. it is not working.
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: authn-filter
namespace: istio-system
spec:
filters:
- insertPosition:
index: FIRST
listenerMatch:
portNumber: 433
listenerType: GATEWAY
listenerProtocol: HTTP
filterType: HTTP
filterName: "envoy.ext_authz"
filterConfig:
http_service:
server-uri:
uri: http://auth.default.svc.cluster.local:8080
cluster: outbound|8080||auth.default.svc.cluster.local
timeout: 2s
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: auth-virtualservice
spec:
hosts:
- "*"
gateways:
- gateway.default.svc.cluster.local
http:
- match:
- uri:
prefix: "/auth"
route:
- destination:
host: auth.default.svc.cluster.local
I figured that out, the problem was caused by the old version of istio deployed on the cluster
Related
I am trying to override Istio's default retry back off interval with the help of an EnvoyFilter.
I have three services, each calling it's successor. Service-2 has retries enabled with a VirtualService.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
labels:
app: service-2
name: service-2-vs
namespace: retry-test
spec:
hosts:
- service-2
http:
- route:
- destination:
host: service-2
retries:
attempts: 5
retryOn: 5xx
The retries are working, but when I apply an EnvoyFilter to override the default retry back off interval I see no effects.
I used the following EnvoyFilter for overriding the back off intervals.
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: service-2-envoy-config
namespace: retry-test
spec:
workloadSelector:
labels:
app: service-2
configPatches:
- applyTo: HTTP_ROUTE
match:
context: SIDECAR_OUTBOUND
routeConfiguration:
vhost:
name: "service-2.retry-test.svc.cluster.local:5002"
patch:
operation: MERGE
value:
route:
retry_policy:
retry_back_off:
base_interval: "1s"
max_interval: "5s"
I also tried configuring the EnvoyFilter for Service-1 since this would be the service sending requests to Service-2, but this didn't work either.
When checking with Kiali I can see that the EnvoyFilter gets applied to the correct service and when looking at Envoy configs of the workload I can see the following got applied.
"route": {
"cluster": "outbound|5002||service-2.retry-test.svc.cluster.local",
"max_grpc_timeout": "0s",
"retry_policy": {
"host_selection_retry_max_attempts": "5",
"num_retries": 5,
"retry_back_off": {
"base_interval": "1s",
"max_interval": "5s"
},
...
}
}
Can someone help me to figure out how to apply the right EnvoyFilter to override the default back off interval?
Posting this if anyone runs into the same problem and finds this question.
When using an EnvoyFilter you need to apply the filter for the service that will send the requests with the vhost being the service the requests are sent to.
In this case this would mean the Envoyfilter gets applied to service-1 with vhost of the routeConfiguration being service-2.
The according yaml file looks like this:
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: service-1-envoy-config
namespace: retry-test
spec:
workloadSelector:
labels:
app: service-1
configPatches:
- applyTo: HTTP_ROUTE
match:
context: SIDECAR_OUTBOUND
routeConfiguration:
vhost:
name: "service-2.retry-test.svc.cluster.local:5002"
patch:
operation: MERGE
value:
route:
retry_policy:
retry_back_off:
base_interval: "1s"
max_interval: "5s"
I have an Istio gateway, Istio VirtualService, and app deployed running as a service. The virtual service is deployed like so:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-app-route
spec:
hosts:
- "*"
gateways:
- my-gateway
http:
- match:
- uri:
prefix: "/my-app"
route:
- destination:
host: my-app-service
port:
number: 8000
When I navigate to http://myurl.com/my-app I would expect to see a JSON response from the service it is pointing to, but I just get a 404. However if I remove the match and redeploy like so:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-app-route
spec:
hosts:
- "*"
http:
- route:
- destination:
host: my-app-service
port:
number: 800
And then go to http://myurl.com/my-app I can see the expected JSON response. Any help?
I was trying to access OpenFaaS through istio in which I have included gateway and virtual service.
I need to create a separate endpoint for the OpenFaaS eg.: "http://istio_ingress_Loadbalancer/openfaas" - This should give me OpenFaaS UI.
Can anyone please help me, regarding I have hard time accessing this?
Below is the code I have written for gateway and virtual service.
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: openfaas-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: openfaas-vs
spec:
hosts:
- "*"
gateways:
- openfaas-gateway.openfaas.svc.cluster.local
http:
- match:
- uri:
prefix: /openfaas
route:
- destination:
host: gateway.openfaas.svc.cluster.local
port:
number: 8080
Add the namespace property in your Gateway yaml file.
Reference the gateway in your VirtualService yaml file with the following format : <gateway-namespace>/<gateway-name>
https://istio.io/latest/docs/reference/config/networking/virtual-service/#VirtualService
Goal
I'm trying to setup a
Cloud LB -> GKE [istio-gateway -> my-service]
This was working before, however, I have to recreate the cluster 2 days ago and run into this problem. Maybe some version change?
This is my ingress manifest file
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: "my-dev-ingress"
namespace: "istio-system"
annotations:
kubernetes.io/ingress.global-static-ip-name: "my-dev-gclb-ip"
ingress.gcp.kubernetes.io/pre-shared-cert: "my-dev-cluster-cert-05"
kubernetes.io/ingress.allow-http: "false"
spec:
backend:
serviceName: "istio-ingressgateway"
servicePort: 80
Problem
The health check issue by the Cloud LB failed. The backend service created by the Ingress create a /:80 default health check.
What I have tried
1) I tried to set the health check generated by the gke ingress to point to the istio-gateway StatusPort port 15020 in the Backend config console. Then the health check passed for a bit until the backend config revert itself to use the original /:80 healthcheck that it created. I even tried to delete the healthcheck that it created and it just create another one.
2) I also tried using the istio-virtual service to route the healthcheck to 15020 port as shown here with out much success.
3) I also tried just route everything in the virtual-service the healthcheck port
hosts:
- "*"
gateways:
- my-web-gateway
http:
- match:
- method:
exact: GET
uri:
exact: /
route:
- destination:
host: istio-ingress.gke-system.svc.cluster.local
port:
number: 15020
4) Most of the search result I found say that setting readinessProbe in the deployment should tell the ingress to set the proper health check. However, all of my service are under the istio-gateway and I can't really do the same.
I'm very lost right now and will really appreciate it if anyone could point me to the right direction. Thanks
i got it working with gke 1.20.4-gke.2200 and istio 1.9.2, the documentation for this is non existent or i have not found anything, you have to add an annotation to istio-ingressgateway service to use a backend-config when using "istioctl install -f values.yaml" command
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
components:
ingressGateways:
- name: istio-ingressgateway
enabled: true
k8s:
serviceAnnotations:
cloud.google.com/backend-config: '{"default": "istio-ingressgateway-config"}'
then you have to create the backend-config with the correct healthcheck port
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: istio-ingressgateway-config
namespace: istio-system
spec:
healthCheck:
checkIntervalSec: 30
port: 15021
type: HTTP
requestPath: /healthz/ready
with this the ingress should automatically change the configuration for the load balancer health check pointing to istio port 80
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: web
namespace: istio-system
annotations:
kubernetes.io/ingress.global-static-ip-name: web
networking.gke.io/managed-certificates: "web"
spec:
rules:
- host: test.example.com
http:
paths:
- path: "/*"
pathType: Prefix
backend:
service:
name: istio-ingressgateway
port:
number: 80
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: direct-web
namespace: istio-system
spec:
hosts:
- test.example.com
gateways:
- web
http:
- match:
- uri:
prefix: "/"
route:
- destination:
port:
number: 8080 #internal service port
host: "internal-service.service-namespace.svc.cluster.local"
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: web
namespace: istio-system
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- test.example.com
you could also set hosts to "*" in the virtualservice and gateway
I am trying to expose kiali on my default gateway. I have other services working for apps in the default namespace but have not been able to route traffic to anything in the istio namespace
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- '*'
tls:
httpsRedirect: true
- port:
number: 443
name: https
protocol: HTTPS
hosts:
- '*'
tls:
mode: SIMPLE
privateKey: /etc/istio/ingressgateway-certs/tls.key
serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: kiali
namespace: default
spec:
hosts:
- kiali.dev.example.com
gateways:
- gateway
http:
- route:
- destination:
host: kiali.istio-system.svc.cluster.local
port:
number: 20001
The problem was I had mTLS enabled and kiali does not have a sidecar thus can not be validated by mTLS. the solution was to add a destination rule disabling mTLS for it.
apiVersion: 'networking.istio.io/v1alpha3'
kind: DestinationRule
metadata:
name: kiali
namespace: istio-system
spec:
host: kiali.istio-system.svc.cluster.local
trafficPolicy:
tls:
mode: DISABLE
You should define an ingress gateway and make sure that the hosts in the gateway match the hosts in the virtual service. Also specify the port of the destination. See the Control Ingress Traffic task.
For me this worked!
I ran
istioctl proxy-config routes istio-ingressgateway-866d7949c6-68tt4 -n istio-system -o json > ./routes.json
to get the dump of all the routes. The kiali route got corrupted for some reason. I deleted the virtual service and created it again, that fixed it.
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: kiali
namespace: istio-system
spec:
gateways:
- istio-system/my-gateway
hosts:
- 'mydomain.com'
http:
- match:
- uri:
prefix: /kiali/
route:
- destination:
host: kiali.istio-system.svc.cluster.local
port:
number: 20001
weight: 100
---
apiVersion: 'networking.istio.io/v1alpha3'
kind: DestinationRule
metadata:
name: kiali
namespace: istio-system
spec:
host: kiali.istio-system.svc.cluster.local
trafficPolicy:
tls:
mode: SIMPLE
---
Note: hosts needed to be set, '*' didnt work for some reason.