Run Your First Secure and DNS with Rancher | SUSE Communities

Run Your First Secure and DNS with Rancher


In the previous article, we installed Rancher on the localhost and run the necessary CI/CD tools. This article will look at how to make our environment liveable on the Internet. We will use Route53 – domain registration and DNS-zones hosting, cert-manager – Let’s Encrypt wildcard certificates and external-dns – synchronizing Ingresses with DNS Route53.

A little personal experience

Why is Rancher good? Because those who do not want to understand the code of manifests and want to run what is required in manual mode can do this through an excellent graphical interface.

Register domain

I’m using Route53, but you can choose another supported provider for cert-manager and external-dns. The reason is that many applications work well with it and the integration is usually not difficult.

Register a new domain using the input field on the Dashboard screen. After completing the registration process in the Hosted zones section, you will see a new zone. Since we want to provide public access, we will use this zone for the production.

Create subdomain Hosted Zones

We will also have three zones: for dev.domain, stage.domain and release.domain as subdomains. Use the Create hosted zone button to create subdomains. For the subdomains to work, it is necessary to add records of NS-servers to the primary hosted zone, the way they are indicated in the subdomain zones. Create the same A-records in the main zone, this is domain and www.domain and dev.domain, stage.domain, release.domain in subdomains hosted zones. This is needed to issue certificates, since the provider checks for A-record before issuing a certificate.

The provider gives me a static IP-address and on the router, I made a forwarding to the bridge interface server IP address where we deployed everything in the previous article. It is this external address that needs to be specified in the A-records.

Create IAM for cert-manager and external-dns

In the IAM management console, create two policies with the following content:

Next, you need to create two users, assign them policies, and copy their credentials. In the documentation on cert-manager and external-dns, this is not an obvious point since they deal with cases with roles and this is misleading, but we will not use roles.

There are many articles on the Internet on how to do this in the cloud in various variations, but if you install on your local server everything is a little different.

Run cert-manager in Rancher-cluster

Add helm-char repo for cert-manager:

For cert-manager use default values.

  enabled: false
installCRDs: true

Create ClusterIssuers for Hosted Zones


kind: ClusterIssuer
  name: letsencrypt-prod
      name: domain-io-cluster-issuer-account-key
        - selector:
                 - ""
          region: eu-central-1
          accessKeyID: AKIAXXXXXXXXXXXXX
            name: prod-route53-credentials-secret
            key: secret-access-key

And repeat this for,,, change ClusterIssuer name, and dnsZone, change privateKeySecretRef:

Request wildcard certificates for you Ingresses

We will use a wildcard certificate with validation through the provider’s DNS:

kind: Certificate
  name: domain-io
  namespace: domain
  secretName: domain-io-tls
    name: letsencrypt-prod
    kind: ClusterIssuer
  - '*' 

And repeat this for *, *, * change namespace, secretName, ClusterIssuer Name.

Changes should occur in the section, certificates should appear, the normal status is Active and the color is green:

Run Ingresses for Your App

Since we issued wildcard certificates in advance and they will be updated independently, we can specify this secret for different domains in the settings. To synchronize secrets between namespaces, you can, for example, use a kubed.

Secure access for non-production zones

You can use client certificate validation to secure your development and test environments. To do this, you need to issue several self-signed certificates and add annotations to the ingress settings: "true" feature/ingresses-cert-dev <--feature - namespace "on" "1"

More details can be found here.

For convert pem and key copy to different files, then give the command:

openssl pkcs12 -export -out developer.pfx -inkey developer.key -in developer.pem

and add pfx to chrome in settings.

Run external-dns

Add helm-chart repo:


  apiRetries: 3
  assumeRoleArn: ''
  batchChangeSize: 1000
    mountPath: /.aws
    secretKey: -->secret-from-iam<--
    secretName: ''
  evaluateTargetHealth: ''
  preferCNAME: ''
  region: eu-central-1
  zoneTags: []
  zoneType: ''
  create: true
  kind: DNSEndpoint
  - service
  - ingress
  - crd
txtOwnerId: sandbox
policy: sync

Create CRD: CRDmanifest

Create DNSendpoint


kind: DNSEndpoint
  name: examplednsrecord
  namespace: feature
  - dnsName:
    recordTTL: 180
    recordType: A

In log:

time="2021-11-25T23:19:37Z" level=info msg="All records are already up to date"
time="2021-11-25T23:20:38Z" level=info msg="Applying provider record filter for domains: []"


time="2021-11-25T23:54:57Z" level=info msg="Desired change: CREATE A [Id: /hostedzone/ZXXXXXXXXXXXDN]"
time="2021-11-25T23:54:57Z" level=info msg="Desired change: CREATE TXT [Id: /hostedzone/ZXXXXXXXXXXXXXXXXDN]"
time="2021-11-25T23:54:57Z" level=info msg="2 record(s) in zone [Id: /hostedzone/ZXXXXXXXXXXXXXXXDN] were successfully updated"


time="2021-11-25T23:59:59Z" level=info msg="Desired change: DELETE A [Id: /hostedzone/ZXXXXXXXXXXXXXDN]"
time="2021-11-25T23:59:59Z" level=info msg="Desired change: DELETE TXT [Id: /hostedzone/ZXXXXXXXXXXXXXDN]"
time="2021-11-25T23:59:59Z" level=info msg="2 record(s) in zone [Id: /hostedzone/ZXXXXXXXXXXXXXXXXXXDN] were successfully updated"


As it turns out for your own development, it is quite easy to raise the full stack on a single server and even post it on the Internet.

Test zones: – secure access – secure access – secure access

(Visited 2 times, 1 visits today)