This is Part 5 of the "Building a Production-Ready n8n Workflow Automation Platform on Azure Kubernetes Service" series. View the complete series here.

Configuring External Access and SSL/TLS

With our n8n application successfully deployed, we need to make it securely accessible from the internet. This involves:

1. Setting up an Ingress resource to route traffic to n8n
2. Implementing SSL/TLS encryption for secure communication
3. Configuring DNS for external access

Let's implement these components to complete our production deployment.

Implementing Cert-Manager for SSL/TLS

Why SSL/TLS is Critical

For a production workflow automation system, SSL/TLS encryption is essential because:

• It protects sensitive data transmitted between clients and n8n
• It prevents man-in-the-middle attacks
• It builds trust with users and external services
• It's required for many modern browser features
• It's a prerequisite for compliance with security standards

Installing Cert-Manager

We used cert-manager to automate the issuance and renewal of SSL/TLS certificates from Let's Encrypt:

# Add the Jetstack Helm repository
helm repo add jetstack https://charts.jetstack.io
helm repo update

# Install cert-manager with CRDs
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --set installCRDs=true

After installation, we verified cert-manager was running correctly:

kubectl get pods -n cert-manager

Expected output:

NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-xxxxxxxxx-xxxxx               1/1     Running   0          2m
cert-manager-cainjector-xxxxxxxxx-xxxxx    1/1     Running   0          2m
cert-manager-webhook-xxxxxxxxx-xxxxx       1/1     Running   0          2m

Configuring a ClusterIssuer for Let's Encrypt

With cert-manager installed, we created a ClusterIssuer resource to integrate with Let's Encrypt:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    # The ACME server URL for Let's Encrypt production
    server: https://acme-v02.api.letsencrypt.org/directory
    # Email address for Important account notifications
    email: your-email@example.com
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    # Enable the HTTP-01 challenge provider
    solvers:
    - http01:
        ingress:
          class: nginx

This configuration:

• Uses Let's Encrypt's production ACME server
• Specifies your email for notifications about certificate expiry
• Uses the HTTP-01 challenge method for domain validation
• Associates with our nginx ingress controller

We applied this configuration:

kubectl apply -f cluster-issuer.yaml

Ingress Configuration with SSL/TLS

Setting Up DNS

Before configuring the Ingress, we created a DNS A record pointing to the external IP of our NGINX Ingress Controller:

Note: Use your actual domain and the external IP from your NGINX Ingress Controller.

Creating the Ingress Resource

Now we can create an Ingress resource to route external traffic to our n8n service and configure SSL/TLS:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: n8n-ingress
  namespace: n8n
  annotations:
    kubernetes.io/ingress.class: "nginx"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: "50m"
spec:
  tls:
  - hosts:
    - n8n.behooked.co
    secretName: n8n-tls-secret
  rules:
  - host: n8n.behooked.co
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: n8n
            port:
              number: 5678

Key aspects of this configuration:

• References our ClusterIssuer to automatically obtain a certificate
• Enables SSL redirection to force HTTPS
• Increases the allowed body size for uploading files to n8n
• Routes all traffic for our domain to the n8n service
• Specifies the TLS secret where the certificate will be stored

We applied this configuration:

kubectl apply -f n8n-ingress.yaml

Verifying Certificate Issuance

After applying the Ingress resource, cert-manager automatically requests a certificate from Let's Encrypt. We checked the status with:

kubectl get certificate -n n8n

Expected output when successful:

NAME             READY   SECRET           AGE
n8n-tls-secret   True    n8n-tls-secret   3m

If the READY status is "False", we can check for issues:

kubectl describe certificate n8n-tls-secret -n n8n

External Access Flow

The following diagram illustrates how external requests flow through our system:

sequenceDiagram
    participant User as User
    participant DNS as DNS (n8n.behooked.co)
    participant Ingress as NGINX Ingress
    participant CM as Cert-Manager
    participant LE as Let's Encrypt
    participant n8n as n8n Service

    User->>DNS: Request n8n.behooked.co
    DNS-->>User: Resolve to Ingress IP

    User->>Ingress: HTTPS Request

    alt First Request / Certificate Issuance
        Ingress->>CM: Check for certificate
        CM->>LE: Request certificate
        LE->>CM: Challenge for domain validation
        CM->>Ingress: Configure validation endpoint
        LE->>Ingress: Validate domain ownership
        LE-->>CM: Issue certificate
        CM-->>Ingress: Store certificate
    end

    Ingress->>Ingress: TLS Termination
    Ingress->>n8n: Forward request
    n8n-->>Ingress: Response
    Ingress-->>User: Encrypted response

This process provides:

• Automatic certificate issuance and renewal
• End-to-end encryption for all external traffic
• Simplified certificate management

External Access Architecture

The complete external access architecture can be visualized as:

flowchart LR
    users[("Internet Users")]
    domain["Domain:\nn8n.behooked.co"]

    subgraph "Azure AKS"
        ingress["NGINX Ingress\nController"]
        cert["Cert-Manager"]

        subgraph "n8n Namespace"
            n8nSvc["n8n Service"]
            n8nPod["n8n Pod"]
        end

        ingress -->|"HTTPS\nPort 443"| n8nSvc
        n8nSvc --> n8nPod
        cert -.->|"Manages\nCertificates"| ingress
    end

    users -->|"HTTPS\nPort 443"| domain
    domain -->|"A Record\n74.179.239.172"| ingress

    style ingress fill:#f96,stroke:#333
    style cert fill:#ff9,stroke:#333
    style n8nSvc fill:#9cf,stroke:#333
    style n8nPod fill:#9fc,stroke:#333

Security Considerations

Our external access implementation includes several security enhancements:

1. Force HTTPS: All HTTP requests are automatically redirected to HTTPS
2. Modern TLS: Let's Encrypt provides modern TLS certificates with strong encryption
3. Automatic Renewal: Certificates are renewed automatically before they expire
4. Rate Limiting: Can be configured on the Ingress to prevent abuse

Validation

To validate our external access configuration, we performed several checks:

1. Ingress Status

kubectl get ingress -n n8n

Expected output:

NAME          CLASS    HOSTS              ADDRESS          PORTS     AGE
n8n-ingress   <none>   n8n.behooked.co    74.179.239.172   80, 443   5m

2. Certificate Status

kubectl get certificate -n n8n

Expected output:

NAME             READY   SECRET           AGE
n8n-tls-secret   True    n8n-tls-secret   5m

3. Browser Access

We accessed https://n8n.behooked.co in a browser to verify:

• The site loads correctly
• The connection is secure (padlock icon)
• The certificate is valid and issued by Let's Encrypt

4. Certificate Details

We also examined the certificate details in the browser to confirm:

• The correct domain name
• Valid issue and expiry dates
• Let's Encrypt as the Certificate Authority

Conclusion

Our n8n deployment is now securely accessible from the internet with HTTPS encryption, thanks to our Ingress configuration and Let's Encrypt integration. Users can safely access the n8n interface and external systems can securely connect to webhooks.

In the next article, we'll implement monitoring, maintenance procedures, and optimization techniques to ensure our deployment remains healthy and efficient. [Continue to Part 6: Monitoring and Optimization]

---

What challenges have you faced when implementing SSL/TLS for your Kubernetes applications? Have you used Let's Encrypt or other certificate providers? Share your insights in the comments!