I am little confused about the mTLS flow of istio. In the bookinginfo example, I see that services are doing calls over http instead of https. If there is mTLS between services then service make http calls?
Can it be that HTTP from service goes to envoy proxy which converts it into https? But, then in envoy-proxy logs of server, I see http in logs.
Can any body please explain how this works?
Regards
HTTP from service goes to envoy proxy which converts it into https
Correct, but only if you enable this feature in Istio. To enable it, see the installation step 5 in https://istio.io/docs/setup/kubernetes/quick-start.html#installation-steps:
Install Istio and enable mutual TLS authentication between sidecars:
kubectl apply -f install/kubernetes/istio-auth.yaml
You may also want to read about testing this feature: https://istio.io/docs/tasks/security/mutual-tls.html .
Related
Is it possible to configure Istio sidecar(envoy) that runs along side with application to terminate tls as Istio Ingress Gateway?
The goal is to terminate my application TLS on outbound/inbound and encrypt with Istio mTLS when connecting to other sidecar and encrypt it back with my certificates before forwarding the traffic to upstream.
If so, please refer to some documentation.
I've installed WSO2 Api Manager 4.0.0 on internal server and I have no idea how to tell it to use proxy server to connect to Choreo analytics.
I see following error in the log:
:Provided authentication endpoint https://analytics-event-auth.choreo.dev/auth/v1 is not reachable.
I've tried to set http_proxy, https_proxy, HTTP_PROXY and HTTPS_PROXY environment variables with flag java.net.useSystemProxies=true to api_manager.sh but they seem to not work and I don't see any traffic coming from this server through proxy.
Adding java flags http.proxyHost and http.proxyPort didn't helped too.
If I start it from server with internet access then it works just fine with Choreo.
Is there any way to set the proxy for APIM?
WSO2 API Manager's gateway component talks to an API in the Analytics cloud in order to fetch required credentials to publish events to the cloud. The failure that you have pointed out occurs at the point of talking to this API. It appears that proxy settings have not been configured for this particular HTTP client. Please see here.
Event publishing is the next step and uses AMQP protocol. Therefore I think it would not go through the HTTP/S proxy. However, if the gateway has no access to the internet, this step will fail again regardless of the API call is fixed to honour the proxy settings.
Currently, analytics does not have the support to publish events through a proxy. It seems that in order to honour proxy settings in event publishing, the protocol needs to be changed to Websocket.
We have a number of services behind an API gateway which is itself behind ingress-nginx. We're trying to use HTTP/2 to speed up data transfer to the front-end but all of our connections are still being done with HTTP/1.1.
The connection from client to nginx is over HTTPS, but nginx communicates with our API gateway using HTTP, and the gateway also uses HTTP to communicate with the backend services.
Do we need to use HTTPS from end-to-end to get HTTP/2 to work? If so, what's the best way to set this up re: using certificates? If not, what could be causing the connection to drop to HTTP/1.1?
We are using ingress-nginx version 0.21.0, which has nginx 1.15.6 and OpenSSL 1.1.1, which should be sufficient to support TLS 1.3/ALPN/HTTP2. Our nginx-configuration configmap has use-http2 set to true and I can see that the pod's /etc/nginx.conf has a listen ... http2; line.
Edit 10/05/2019:
Further to the comments of #Barry Pollard and #Rico, I've found out that AWS Elastic Load Balancer, which sits in front of our ingress-nginx controller, doesn't support HTTP/2. I've cut nginx out of the stack and our API Gateway is being provisioned its own Network Load Balancer. However, we're still on HTTP/1.1. It looks like ASP.Net Core 2.2's HTTP server Kestrel uses HTTP/2 by default, so I'm not sure why the connection is still dropping to 1.1.
Like #BarryPollard said you shouldn't need HTTP/2 end to end to establish HTTP/2 connections on your browser.
It sounds like whatever you are using for a client is dropping to HTTP/1.1, make sure you try with one of the following:
Chrome 51
Firefox 53
Edge 12
Internet Explorer 11
Opera 38
You didn't specify what architecture is fronting your nginx. Is it connected directly to the internet? or it's going through cloud load balancer? CDN? You can also test with Wireshark as described here.
I'm running Istio Ingress Gateway in a GKE cluster. The Service runs with a NodePort. I'd like to connect it to a Google backend service. However we need to have an health check that must run against Istio. Do you know if Istio expose any HTTP endpoint to run health check and verify its status?
Per this installation guide, "Istio requires no changes to the application itself. Note that the application must use HTTP/1.1 or HTTP/2.0 protocol for all its HTTP traffic because the Envoy proxy doesn't support HTTP/1.0: it relies on headers that aren't present in HTTP/1.0 for routing."
The healthcheck doesn't necessarily run against Istio itself, but against the whole stack behind the IP addresses you configured for the load balancer backend service. It simply requires a 200 response on / when invoked with no host name.
You can configure this by installing a small service like httpbin as the default path for your gateway.
You might also consider changing your Service to a LoadBalancer type, annotated to be internal to your network (no public IP). This will generate a Backend Service, complete with healthcheck, which you can borrow for your other load balancer. This method has worked for me with nesting load balancers (to migrate load) but not for a proxy like Google's IAP.
I would like to setup a public kubernetes service in AWS that listens on https.
I know that kubernetes services currently only support TCP and UDP, but is there a way to make this work with the current version of kubernetes and AWS ELBs?
I found this. http://blog.kubernetes.io/2015/07/strong-simple-ssl-for-kubernetes.html
Is that the best way at the moment?
Https usually runs over TCP, so you can simply run your service with Type=Nodeport/LoadBalancer and manage the certs in the service. This example might help [1], nginx is listening on :443 through a NodePort for ingress traffic. See [2] for a better explanation of the example.
[1] https://github.com/kubernetes/kubernetes/blob/release-1.0/examples/https-nginx/nginx-app.yaml#L8
[2] http://kubernetes.io/v1.0/docs/user-guide/connecting-applications.html
Since 1.3, you can use annotations along with a type=LoadBalancer service:
https://github.com/kubernetes/kubernetes/issues/24978
service.beta.kubernetes.io/aws-load-balancer-ssl-cert=arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012
service.beta.kubernetes.io/aws-load-balancer-ssl-ports=* (or e.g. https)
The first annotation is the only one you need if all you want is to support HTTPS, on any number of ports. If you also want to support HTTP on one or more additional ports, you need to use the second annotation to specify explicitly which ports will use encryption (the others will use plain HTTP).
In my case I setup an elb in aws and setup the ssl cert on that, choosing https and http for the connection types in the elb and that worked great. I setup the elb wroth kubectl expose.