0

I have a domain (example.com) already configured in Cloud DNS. With this domain I can access microservices that are in a GKE cluster. I use istio-ingressgateway IP in CloudDNS to make the association between the cluster

Now I have another domain (newexample.com) with a custom certificate for https connections. Is there a way to redirect all the requests to newexample.com to example.com? I do not want to change anything in gke/istio configuration if possible.

Edgar Peixoto
  • 543
  • 1
  • 5
  • 23
  • You can add `A` record to the `DNS` servers to point your domain to the `ingress-gateway` loadbalancer service of Istio however the question is how do you want to add your ssl certificates without modifying your `ingress-gateway` configuration. – Dawid Kruk May 29 '20 at 13:48
  • You cannot redirect a domain using `A` records alone. The target SSL certificate must support the domain name that you are redirecting, otherwise you will get a security error in the browser/application. – John Hanley May 30 '20 at 18:56
  • As correctly stated in previous comment by John Hanley it will be necessary to change the certificates bound to the `ingress-gateway`. This would require additional changes to your `ingress-gateway` definition as the host would be different (assuming it's not `*`). – Dawid Kruk Jun 02 '20 at 12:00

1 Answers1

2

Each method will require some of the reconfiguration in either GKE/Istio side.

One of the solutions to this is to have a CNAME record in a Cloud DNS and a SSL certificate with Alternative Names.

With above solution you will be able to send requests to your GKE/Istio cluster with both domain names assuming correct Istio configuration.


What is CNAME?

CNAME is a Canonical Name Record or Alias Record.

A type of resource record in the Domain Name System (DNS), that specifies that one domain name is an alias of another canonical domain name.

Example of a CNAME record:

DNS name       Type      TTL     Data
old.domain.    A         60      1.2.3.4
new.domain.    CNAME     60      old.domain.

Alternative Names:

A SAN or subject alternative name is a structured way to indicate all of the domain names and IP addresses that are secured by the certificate.

Enstrustdatacard.com: What is a san and how is it used

You can create SSL cerificate create to support both:

  • old.domain
  • new.domain

There are plenty options to do that for example Let's Encrypt or Cert Manager.


Example

I've created an example to show you how to do it:

  • Configure DNS zone in Cloud DNS
  • Create a basic app with a service
  • Create a certificate for example app
  • Create Istio resources to allow connections to example app
  • Test

Configure DNS zone in Cloud DNS

You will need to have 2 records:

  • A record with IP of your Ingress Gateway and name: old.domain
  • CNAME record pointing to old.domain with name: new.domain

Please take a look on official documentation: Cloud.google.com: DNS: Records

Create a basic app with a service

Below is example app with a service which will respond with a basic hello:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-dp
spec:
  selector:
    matchLabels:
      app: hello-dp
  replicas: 1
  template:
    metadata:
      labels:
        app: hello-dp
    spec:
      containers:
      - name: hello
        image: "gcr.io/google-samples/hello-app:2.0"
        env:
        - name: "PORT"
          value: "50001"
---
apiVersion: v1
kind: Service
metadata:
  name: hello-sv
spec:
  selector:
    app: hello-dp
  ports:
    - name: hello-port
      protocol: TCP
      port: 50001
      targetPort: 50001
  type: ClusterIP

Create a certificate for example app

As said previously, certificate with Alternative Names can be created with Let's Encrypt. I created it with:

  • GCE VM with Ubuntu 16.04
  • Open port 80
  • Domain name old.domain pointing to public ip address of a VM
  • Guide: Linode.com: Docs: Install let's encrypt to create a SSL certificate
  • Command to create certificate:

    $ ./letsencrypt-auto certonly --standalone -dold.domain-dnew.domain

  • Certificate created in /etc/letsencrypt/archive/ used in creating tls secret for GKE with command:

    $ kubectl create secret tlsssl-certificate--cert cert1.pem --key privkey1.pem

Please have in mind that this certificate was created only for testing purposes and I strongly advise using dedicated solution like: Cert-manager

PS: If you used this method please revert back changes in the Cloud DNS to point the Istio gateway.


Create Istio resources to allow connections to example app

Below are example Istio resources allowing connections to example app with support for HTTPS:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: hello-gw
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: ssl-certificate
    hosts:
    - "old.domain"
    - "new.domain"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: hello-vs
spec:
  hosts:
  - "old.domain"
  - "new.domain"
  gateways:
  - hello-gw
  http:
  - route:
    - destination:
        host: hello-sv
        port:
          number: 50001

Please take a specific look on:

    tls:
      mode: SIMPLE
      credentialName: ssl-certificate

This part will ensure that connection to the cluster will use HTTPS

Additionally:

  hosts:
  - "old.domain"
  - "new.domain"

Above definition in both resources will allow only connections with specified domains.

Test

When applied all of the above resources you should be able to enter in your browser:

  • https://old.domain
  • https://new.domain

and be greeted with below message and valid SSL certificate:

Hello, world!
Version: 2.0.0
Hostname: hello-dp-5dd8b85b56-bk7zr
Dawid Kruk
  • 8,982
  • 2
  • 22
  • 45