How to Configure SSL/TLS Certificates for ECK-Managed Elasticsearch to Connect External Elastic Agent and Logstash

Elastic Search
1

I have an Elasticsearch cluster deployed using Elastic Cloud on Kubernetes (ECK). Currently, I have an Elastic Agent on an external virtual machine (192.168.1.4) that sends data to Logstash (192.168.1.4:5044), and Logstash then forwards this data to the internally deployed ECK Elasticsearch cluster.

From what I understand, the Elasticsearch instance deployed by ECK does not include a CA private key by default. To configure SSL/TLS for the Logstash output, how can I generate additional certificates within ECK Elasticsearch so that the external Elastic Agent and Logstash can securely communicate with the ECK Elasticsearch cluster?

2

For external connections to my ECK hosted Elasticsearch cluster, I use an Ingress with a TLS certificate (I use Let's Encrypt + cert-manager to automate creation and renewal).

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "360"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "360"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "360"
    nginx.ingress.kubernetes.io/proxy-ssl-verify: "off"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  rules:
  - host: SUB.DOMAIN.TLD
    http:
      paths:
      - backend:
          service:
            name: MY_SVC_NAME
            port:
              number: 9200
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - SUB.DOMAIN.TLD
    secretName: MY_SECRET_NAME

Where:

  • SUB.DOMAIN.TLD = the host name to be secured (which your Logstash will point to as part of the URL)
  • MY_SVC_NAME = whatever your Elasticsearch service short name is. It should be ${metadata.name}-es-http
  • MY_SECRET_NAME = arbitrary, if using cert-manager, otherwise it needs to be the name of an existing TLS certificate valid for SUB.DOMAIN.TLD.