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.
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.
prometheus: enabled: false installCRDs: true
Create ClusterIssuers for Hosted Zones
apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: letsencrypt-prod spec: acme: email: firstname.lastname@example.org server: https://acme-v02.api.letsencrypt.org/directory privateKeySecretRef: name: domain-io-cluster-issuer-account-key solvers: - selector: dnsZones: - "domain.io" dns01: route53: region: eu-central-1 accessKeyID: AKIAXXXXXXXXXXXXX secretAccessKeySecretRef: name: prod-route53-credentials-secret key: secret-access-key
And repeat this for dev.domain.io, stage.domain.io, release.domain.io, 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:
apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: domain-io namespace: domain spec: secretName: domain-io-tls issuerRef: name: letsencrypt-prod kind: ClusterIssuer dnsNames: - '*.domain.io' - domain.io
And repeat this for *.dev.domain.io, *.stage.domain.io, *.release.domain.io 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:
nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true" nginx.ingress.kubernetes.io/auth-tls-secret: feature/ingresses-cert-dev <--feature - namespace nginx.ingress.kubernetes.io/auth-tls-verify-client: "on" nginx.ingress.kubernetes.io/auth-tls-verify-depth: "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.
Add helm-chart repo:
aws: apiRetries: 3 assumeRoleArn: '' batchChangeSize: 1000 credentials: accessKey: AKIAXXXXXXXXXXXXX mountPath: /.aws secretKey: -->secret-from-iam<-- secretName: '' evaluateTargetHealth: '' preferCNAME: '' region: eu-central-1 zoneTags:  zoneType: ''
crd: apiversion: externaldns.k8s.io/v1alpha1 create: true kind: DNSEndpoint
sources: - service - ingress - crd
txtOwnerId: sandbox policy: sync
Create CRD: CRDmanifest
apiVersion: externaldns.k8s.io/v1alpha1 kind: DNSEndpoint metadata: name: examplednsrecord namespace: feature spec: endpoints: - dnsName: test1.dev.domain.io recordTTL: 180 recordType: A targets: - <YOU-EXTERNAL-IP-ADDRESS>
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: [domain.io. .domain.io. release.domain.io. .release.domain.io. stage.domain.io. .stage.domain.io. dev.domain.io. .dev.domain.io.]"
time="2021-11-25T23:54:57Z" level=info msg="Desired change: CREATE test1.dev.domain.io A [Id: /hostedzone/ZXXXXXXXXXXXDN]" time="2021-11-25T23:54:57Z" level=info msg="Desired change: CREATE test1.dev.domain.io TXT [Id: /hostedzone/ZXXXXXXXXXXXXXXXXDN]" time="2021-11-25T23:54:57Z" level=info msg="2 record(s) in zone dev.domain.io. [Id: /hostedzone/ZXXXXXXXXXXXXXXXDN] were successfully updated"
time="2021-11-25T23:59:59Z" level=info msg="Desired change: DELETE test1.dev.domain.io A [Id: /hostedzone/ZXXXXXXXXXXXXXDN]" time="2021-11-25T23:59:59Z" level=info msg="Desired change: DELETE test1.dev.domain.io TXT [Id: /hostedzone/ZXXXXXXXXXXXXXDN]" time="2021-11-25T23:59:59Z" level=info msg="2 record(s) in zone dev.domain.io. [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.
https://dev.pregap.io – secure access
https://stage.pregap.io – secure access
https://release.pregap.io – secure access