istio: ServiceEntry not working as expected
Describe the bug
I want to access an external HTTP API and I’m not able to do so. I’ve setted the ServiceEntry for other domain and it works, but for darksky.net
or api.darksky.net
it doesn’t. I’ve tried inside my Go app and with a curl
in the Alpine Linux. Running the docker image in my machine works OK.
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: googleapis
spec:
hosts:
- googleapis.com # this one works
ports:
- number: 443
name: tls
protocol: TLS
resolution: DNS
---
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: darksky
spec:
hosts:
- api.darksky.net # this one doesn't
ports:
- number: 443
name: tls
protocol: TLS
resolution: DNS
cURL output:
/ # curl -v https://api.darksky.net/forecast/APIKEYREDACTED/-33.3504409,-60.2558157?lang=es&units=si
[1]- Done(51) curl https://api.darksky.net/forecast/APIKEYREDACTED/-33.3504409,-60.2558157?lang=es
/ # * Trying 52.200.123.152...
* TCP_NODELAY set
* Connected to api.darksky.net (52.200.123.152) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* successfully set certificate verify locations:
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=www.google.com
* start date: Jun 19 11:40:49 2018 GMT
* expire date: Aug 28 11:32:00 2018 GMT
* subjectAltName does not match api.darksky.net
* SSL: no alternative certificate subject name matches target host name 'api.darksky.net'
* stopped the pause stream!
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):
curl: (51) SSL: no alternative certificate subject name matches target host name 'api.darksky.net'
My Go app tells me the same thing:
2018/08/02 18:07:59 Get https://api.darksky.net/forecast/REDACTEDAPIKEY/-33.3504409,-60.2558157?lang=es&units=si: x509: certificate is valid for www.google.com, not api.darksky.net
Expected behavior Make the HTTP request without problems.
Steps to reproduce the bug Use the yaml I copied above and have a container make a curl.
Version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.7", GitCommit:"dd5e1a2978fd0b97d9b78e1564398aeea7e7fe92", GitTreeState:"clean", BuildDate:"2018-04-19T00:05:56Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.5-gke.3", GitCommit:"6265b9797fc8680c8395abeab12c1e3bad14069a", GitTreeState:"clean", BuildDate:"2018-07-19T23:02:51Z", GoVersion:"go1.9.3b4", Compiler:"gc", Platform:"linux
/amd64"}
Istio 1.0.0 installed with the quickstart link in GKE.
Is Istio Auth enabled or not? I think yes (Installed with the quickstart link in GKE)
Environment Google Cloud
Cluster state I’ll upload this later if it’s necessary
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 2
- Comments: 25 (5 by maintainers)
Migrated to 1.1 and was still receiving the same SSL errors.
I ended up setting
and set
includeIPRanges
to my cluster cidr. This disabled all external traffic filtering and I was finally able to get my apps to call external services.Thanks. It’s working for me with the
resolution: NONE
. Amazing thatresolution: DNS
is still working with for the 1st ServiceEntry.@edalford11 VirtualService is not required starting from https://gcsweb.istio.io/gcs/istio-prerelease/daily-build/release-1.1-20190214-09-16/. We just updated the task to reflect that https://preliminary.istio.io/docs/tasks/traffic-management/egress/#access-an-external-https-service.
@toantc Istio is meticulous about using wildcard hosts and
resolution: DNS
. Here are some quotes from official docs:1.0.3 release notes:
Service Entry:
Give it a try by setting
resolution: NONE
, and see if it works.Another comment about this.
you will need to add a virtual service as well https://istio.io/docs/tasks/traffic-management/egress/#configuring-the-external-services