Let’s Encrypt Example for Federal Frontier API Services

Using Let’s Encrypt with Federal Frontier API Services

In this tutorial, we will applying Let’s Encrypt with Federal Frontier API Services. Please ensure to prepare your environment by viewing the Let’s Encrypt base installation guide.

Let’s Encrypt Configuration

To begin, start by navigating to your cert-manager namespace in Kubernetes. Be sure kubectx into your local machine.

kubens cert-manager

Generate CloudFlare API Key Secret

Similar to the base installation guide, we will start by generating your CloudFlare API Key Secret.

Step 1: To generate the secret, create a manifest api-secret.yaml within your local machine and paste the contents below. Be sure to have your CloudFlare API Key ready for insertion. The API Token will be inserted into data.api-key.txt within the manifest. Note: You can name the .yaml file to your preference.

apiVersion: v1
kind: Secret
metadata:
  name: cloudflare-api-key
  namespace: cert-manager

type: Opaque
data:
  api-key.txt: xxxxxxxxxxxxxxxxxxxxxxxxxxxxx # <=== API_TOKEN GOES HERE
  # Key is in base64 representation

Step 2: Apply the secret manifest into Kubernetes using the command below.

kubectl apply -f api-secret.yaml

Step 3: Confirm application by getting secrets from your cert-manager Kubernetes namespace.

kubectl get secret -n cert-manager

Your response should be similar to that shown below.

NAME                     TYPE               DATA   AGE
cloudflare-api-key       Opaque             1      5m

Create the ClusterIssuer Configuration

Once you have generated your CloudFlare API Key Secret, we can start on configuring your ClusterIssue.

Step 1: Start by creating a new manifest clusterissuer.yaml within your local machine and paste the contents below. Be sure to insert your email registered with CloudFlare in fields spec.acme.email and spec.acme.solvers.dns01.cloudflare.email before saving. Note: You can name the .yaml file to your preference.

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    email: xxxxxxx@xxxx.com # <=== YOUR EMAIL GOES HERE
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-prod

    # The HTTP01 and DNS01 fields are now **deprecated**.
    # We leave them in place here so that any Certificates that still
    # specify a ``certificate.spec.acme`` stanza will continue to operate
    # correctly.
    # cert-manager will decide which configuration to use based on whether
    # the Certificate contains a ``certificate.spec.acme`` stanza.
    #    http01: {}
    solvers:
      - dns01:
          #      providers:
          cloudflare:
            email: xxxxxxx@xxxx.com # <=== YOUR EMAIL GOES HERE
            apiKeySecretRef:
              name: cloudflare-api-key
              key: api-key.txt

Step 2: Apply the ClusterIssue manifest into Kubernetes using the command below.

kubectl apply -f clusterissuer.yaml

Step 3: Confirm application by getting the clusterissue from Kubernetes. You are able to access this clusterissue throughout all namespaces.

kubectl get clusterissuer

Your response should be similar to that shown below.

NAME               READY   AGE
letsencrypt-prod   True    7m

Create the Certificate for your Application

With the configuration of your secrets and clusterissuer in Kubernetes, we can now begin creating the certificates that will be used for your application such as our Federal Frontier API Services.

Step 1: Start by navigating into your application’s namespace.

kubens frontier

Step 2: To generate the certificate, start by creating a new manifest cert.yaml within your local machine and paste the contents below. Note: You can name the .yaml file to your preference.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: fas-eupraxialabs-com
  namespace: frontier
spec:
  secretName: fas-eupraxialabs-com
  issuerRef:
    name: letsencrypt-prod
  dnsNames:
  - fas.eupraxialabs.com

Step 3: Apply the ClusterIssue manifest into Kubernetes using the command below.

kubectl apply -f cert.yaml

Step 4: Confirm application by getting the clusterissue from Kubernetes. You are able to access this clusterissue throughout all namespaces.

kubectl get certificate

Your response should be similar to that shown below. Ensure the Ready state is set to True.

NAME                   READY   SECRET                 AGE
fas-eupraxialabs-com   True    fas-eupraxialabs-com   148m

Applying Ingress-NGINX to Kubernetes Ingress Controller

You will be able to secure your application load balanced by Ingress with specifying the secret that contains the TLS private key and certificate. Similarily mentioned in the MetalLB and NGINX tutorial Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource.

Ingress Conceptual Diagram

Ingress Conceptual Diagram

The figure above is a simple example where an Ingress sends all its traffic to one service. An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name-based virtual hosting. An Ingress controller is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic. An Ingress does not expose arbitrary ports or protocols. Exposing services other than HTTP and HTTPS to the internet typically uses a service of type Service.Type=NodePort or Service.Type=LoadBalancer.

To set up MetalLB and Ingress-NGINX into your Kubernetes cluster, please visit our MetalLB and NGINX tutorial for more knowledge and installation guidelines.

Step 1: Start by creating a new Ingress manifest ingress-app-config.yaml for your application and paste the contents below. Note: You can name the .yaml file to your preference.

apiVersion: v1
items:
- apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"kubernetes.io/ingress.class":"nginx"},"creationTimestamp":"2022-08-05T21:08:12Z","generation":9,"name":"federal-frontier-api-service","namespace":"frontier","resourceVersion":"37730212","uid":"2a599a8c-f831-4298-9267-914d8cf42814"},"spec":{"rules":[{"host":"fas.eupraxialabs.com","http":{"paths":[{"backend":{"service":{"name":"frontier-api","port":{"number":8080}}},"path":"/","pathType":"ImplementationSpecific"}]}}],"tls":[{"hosts":["fas.eupraxialabs.com"],"secretName":"fas-eupraxialabs-com"}]},"status":{"loadBalancer":{"ingress":[{"ip":"192.168.1.254"}]}}}
      kubernetes.io/ingress.class: nginx
    creationTimestamp: "2022-08-16T18:56:28Z"
    generation: 1
    name: federal-frontier-api-service
    namespace: frontier
    resourceVersion: "40109266"
    uid: f142aed1-1c7e-4692-89c7-a0043f358b8b
  spec:
    rules:
    - host: fas.eupraxialabs.com
      http:
        paths:
        - backend:
            service:
              name: frontier-api
              port:
                number: 8080
          path: /
          pathType: ImplementationSpecific
    tls:
    - hosts:
      - fas.eupraxialabs.com
      secretName: fas-eupraxialabs-com
  status:
    loadBalancer:
      ingress:
      - ip: 192.168.1.254
kind: List
metadata:
  resourceVersion: ""

Inside your manifest, items.spec.tls is where you will insert your specified secret for your application. If your manifest failed to be applied within Kubernetes, you may have to delete the original Ingress inside of your application’s Kubernetes namespace for a successful Ingress creation.

Step 3: Confirm changes of the Ingress within your Kubernetes application namespace by utilizing the command below.

kubectl get ingress

Your response should be similar to that shown below. Ensure PORTS contains both 80, 443.

NAME                           CLASS    HOSTS                  ADDRESS         PORTS     AGE
federal-frontier-api-service   <none>   fas.eupraxialabs.com   192.168.1.254   80, 443   13m

If all Let’s Encrypt configurations are done correctly, you should be able to now access a curl to your website services with a valid Certificate Authority (CA).