Skip to content

k8s-https-settings.md

Latest commit

 

History

History
268 lines (214 loc) · 9.75 KB

k8s-https-settings.md

File metadata and controls

268 lines (214 loc) · 9.75 KB
Raw
mapped_pages
applies_to
deployment
eck
products
id
cloud-kubernetes

Manage HTTP certificates on ECK

ECK offers several options for securing the HTTP endpoints of {{es}} and {{kib}}. By default, the operator generates a dedicated HTTP CA per resource and uses it to issue the required certificates. Alternatively, you can supply your own certificates or integrate with external solutions like cert-manager.

:::{note} This section only covers TLS certificates for the HTTP layer. TLS certificates for the transport layer that are used for internal communications between {{es}} nodes are managed by ECK and cannot be changed. You can however set your own certificate authority for the transport layer. :::

{{es}} certificates [k8s-tls-certificates]

By default, the operator generates a dedicated HTTP CA for each {{es}} cluster and uses it to issue a certificate for HTTP access. The CA, the certificate, and the private keys are each stored in separate Kubernetes secrets.

> kubectl get secret | grep es-http
quickstart-es-http-ca-internal         Opaque  2   28m <1>
quickstart-es-http-certs-internal      Opaque  2   28m <2>
quickstart-es-http-certs-public        Opaque  1   28m <3>
  1. Contains the CA certificate and private key (for internal use only)
  2. Contains the HTTP certificate and private key (for internal use only)
  3. Contains the CA and HTTP certificates (no private keys)

The CA and the HTTP certificate used by the instances are stored in a secret named <name>-[es|kb|apm|ent|agent]-http-certs-public.

  • You can obtain the CA from the ca.crt key of that secret with the following command:

    kubectl get secret quickstart-es-http-certs-public -o go-template='{{index .data "ca.crt" | base64decode }}'

    ::::{note} The HTTP CA certificate is required to establish trusted connections from clients, for example using curl with --cacerts option. ::::

  • To retrieve the HTTP certificate used by the instances, grab the tls.crt key of the same secret.

    kubectl get secret quickstart-es-http-certs-public -o go-template='{{index .data "tls.crt" | base64decode }}'

Custom HTTP certificate [k8s-custom-http-certificate]

You can provide your own CA and certificates instead of using the default generated certificates to connect to {{stack}} applications through HTTPS using a Kubernetes secret.

Check Setup your own certificate to learn how to do that with elasticsearch-certutil tool.

Custom self-signed certificate using OpenSSL [k8s_custom_self_signed_certificate_using_openssl]

This example illustrates how to create your own self-signed certificate for the quickstart {{es}} cluster using the OpenSSL command line utility. Note the subject alternative name (SAN) entry for quickstart-es-http.default.svc.

$ openssl req -x509 -sha256 -nodes -newkey rsa:4096 -days 365 -subj "/CN=quickstart-es-http" -addext "subjectAltName=DNS:quickstart-es-http.default.svc" -keyout tls.key -out tls.crt
$ kubectl create secret generic quickstart-es-cert --from-file=ca.crt=tls.crt --from-file=tls.crt=tls.crt --from-file=tls.key=tls.key

Custom self-signed certificate using cert-manager [k8s_custom_self_signed_certificate_using_cert_manager]

This example illustrates how to issue a self-signed certificate for the quickstart {{es}} cluster using a cert-manager self-signed issuer.

---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-issuer
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: quickstart-es-cert
spec:
  isCA: false
  dnsNames:
    - quickstart-es-http
    - quickstart-es-http.default.svc
    - quickstart-es-http.default.svc.cluster.local
  issuerRef:
    kind: Issuer
    name: selfsigned-issuer
  secretName: quickstart-es-cert
  subject:
    organizations:
      - quickstart

Custom private CA and certificate using cert-manager [k8s_custom_http_ca_using_cert_manager]

To set up a private CA and issue {{es}} certificates, you can use cert-manager. Additional certificates can be issued from the same CA, allowing multiple clusters or services to share a common trust root. This is useful, for example, for Remote clusters, which need to trust each other’s CAs. Using a shared CA avoids having to configure and mount N different CAs when a cluster is connected to N other clusters.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-issuer
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: selfsigned-ca
spec:
  isCA: true
  commonName: selfsigned-ca
  secretName: root-ca-secret
  privateKey:
    algorithm: ECDSA
    size: 256
  issuerRef:
    kind: ClusterIssuer
    name: selfsigned-issuer
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: ca-issuer
spec:
  ca:
    secretName: root-ca-secret
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: quickstart-es-cert
spec:
  isCA: false
  dnsNames:
    - quickstart-es-http
    - quickstart-es-http.default.svc
    - quickstart-es-http.default.svc.cluster.local
  subject:
    organizations:
      - quickstart
  privateKey:
    algorithm: RSA
    encoding: PKCS1
    size: 2048
  issuerRef:
    kind: Issuer
    name: ca-issuer
  secretName: quickstart-es-cert

Reserve static IP and custom domain [k8s-static-ip-custom-domain]

By default, ECK-generated HTTP certificates include DNS names for the {{k8s}} services of the corresponding cluster as Subject Alternative Names (SANs), such as <name>-es-http.<namespace>.svc.

If you need additional DNS names or IP addresses (for example, a custom domain or a static load balancer IP), add them through selfSignedCertificate.subjectAltNames:

spec:
  http:
    service:
      spec:
        type: LoadBalancer
    tls:
      selfSignedCertificate:
        subjectAltNames:
        - ip: 160.46.176.15
        - dns: quickstart.<your-domain>

Provide your own certificate or CA [k8s-setting-up-your-own-certificate]

You can bring your own certificate to configure TLS to ensure that communication between HTTP clients and the {{stack}} application is encrypted.

Create a Kubernetes secret with:

  • ca.crt: CA certificate (optional if tls.crt was issued by a well-known CA).
  • tls.crt: The certificate.
  • tls.key: The private key to the first certificate in the certificate chain.

::::{warning} If your tls.crt is signed by an intermediate CA you may need both the Root CA and the intermediate CA combined within the ca.crt file depending on whether the Root CA is globally trusted. ::::

kubectl create secret generic my-cert --from-file=ca.crt --from-file=tls.crt --from-file=tls.key

Alternatively you can also bring your own CA certificate including a private key and let ECK issue certificates with it. Any certificate SANs you have configured as described in Reserve static IP and custom domain will also be respected when issuing certificates with this CA certificate.

Create a Kubernetes secret with:

  • ca.crt: CA certificate.
  • ca.key: The private key to the CA certificate.
kubectl create secret generic my-cert --from-file=ca.crt --from-file=ca.key

In both cases, you have to reference the secret name in the http.tls.certificate section of the resource manifest.

spec:
  http:
    tls:
      certificate:
        secretName: my-cert

{{kib}} HTTP configuration in ECK [k8s-kibana-http-configuration]

By default, ECK creates a ClusterIP Service and associates it with the {{kib}} deployment.

If you need to expose {{kib}} externally or customize the service settings, ECK provides flexible options, including support for load balancers, custom DNS/IP SANs, and user-provided certificates.

Load balancer settings and TLS SANs [k8s-kibana-http-publish]

If you want to expose {{kib}} externally with a load balancer, it is recommended to include a custom DNS name or IP in the self-generated certificate.

apiVersion: kibana.k8s.elastic.co/v1
kind: Kibana
metadata:
  name: kibana-sample
spec:
  version: 8.16.1
  count: 1
  elasticsearchRef:
    name: "elasticsearch-sample"
  http:
    service:
      spec:
        type: LoadBalancer # default is ClusterIP
    tls:
      selfSignedCertificate:
        subjectAltNames:
        - ip: 1.2.3.4
        - dns: kibana.<your-domain>

Provide your own certificate [k8s-kibana-http-custom-tls]

If you want to use your own certificate, the required configuration is identical to {{es}}. Refer to setup your own {{es}} certificate for more information.

Disable TLS [k8s-disable-tls]

You can explicitly disable the generation of the default certificates and hence disable TLS for {{kib}}, APM Server, and the HTTP layer of {{es}}.

::::{important} Disabling TLS is not recommended outside of test or development environments. ::::

To disable TLS, add the following setting to the appropriate resource:

spec:
  http:
    tls:
      selfSignedCertificate:
        disabled: true