Setting up TLS and DNS on Google Cloud Platform


Cloud Infrastructure

First we will configure the cloud infrastructure requirements:

  • a GCP Service Account with the dns.admin role, see here for more information
  • a managed cloud dns zone, see here for more information

To satisfy these requirements go to your infrastructure repository (contains Terraform and add to your the following:

apex_domain = ""

Most people prefer to use a subdomain for a specific installation rather than purchasing one domain per cluster. For example in a multi cluster setup you will probably want all using the same parent domain but two clusters using a different subdomain like, leaving production using just the parent domain

To use a subdomain for this cluster add the following configuration:

subdomain     = "dev"

We will now add details that will be passed to Jenkins X as requirements when booting the cluster.

Add these to

lets_encrypt_production = true
tls_email               =

Now apply these changes:

git add
git commit -m 'feat: enable DNS cloud resources'
git push

You may want to set two environment variables here so that Terraform does not prompt for values

export TF_VAR_jx_bot_username=
export TF_VAR_jx_bot_token=

now run

terraform plan
terraform apply

If using a subdomain you will now see your managed zone in GCP here

Once terraform has finished for now there is a manual trigger of the Jenkins X cluster repository required. This will not be needed in the future but for now please make a dummy commit on your cluster git repository and follow the boot job as in applies the updates to your cluster.

To follow the jx boot installation using the instructions given in the terraform output, connect to the cluster and run:

jx admin logs

There is a timing issue with cert-manager and the admission controller so the first boot job may fail but second will run automatically and succeed.

It can take a short while for DNS to propagate so you may need to wait for 5 - 10 minutes. is a useful way to check the status of DNS propagating.

To verify using the CLI run:

kubectl get ingress -n jx

and use the hook URL

jx verify tls  --production=false --timeout 20m

You should be able to verify the TLS certificate from Lets Encrypt in your browser (beware of browser caching if you don’t see any changes)

Working TLS

Once this is working you can switch any of the configuration using your cluster git repository and change the jx-requirements.yaml, e.g. toggling the cert-manager production service or editing the email address used:

  externalDNS: true
  namespaceSubDomain: -jx.
    email: ""
    enabled: true
    production: true

Git commit and push the change back to your remote git repository and follow the installation:

jx admin logs

You will now be issued a valid TLS certificate

jx verify tls  --production=true --timeout 20m