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)

Most upvoted comments

Migrated to 1.1 and was still receiving the same SSL errors.

I ended up setting

outboundTrafficPolicy:
    mode: ALLOW_ANY

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 that resolution: DNS is still working with for the 1st ServiceEntry.

@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 no longer allows wildcard (*) DNS resolution. The API has never allowed this, however, ServiceEntry was erroneously excluded from validation in the previous release.

Service Entry:

The following example demonstrates the use of wildcards in the hosts for external services. If the connection has to be routed to the IP address requested by the application (i.e. application resolves DNS and attempts to connect to a specific IP), the discovery mode must be set to NONE.

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: external-svc-wildcard-example
spec:
  hosts:
  - "*.bar.com"
  location: MESH_EXTERNAL
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: NONE

Give it a try by setting resolution: NONE, and see if it works.

Another comment about this.