Don't want to use https and user:password

Elastic Orchestration Elastic Cloud on Kubernetes (ECK)
1

Hi
I am deploying ECK on GKE in a private Kubernetes cluster. That cluster has the only service which will talk to Elasticsearch. So I don't need to have any https or user:password authentication. All I want is a simple clusterIP service which can be directly accessed by the service within the kubernetes cluster.
Please let me know how to do that.

1 Like
2

Hello,

TLS can be disabled as explained here: https://www.elastic.co/guide/en/cloud-on-k8s/0.9/k8s-accessing-elastic-services.html#k8s-disable-tls.

spec:
  http:
    tls:
      selfSignedCertificate:
        disabled: true

Basic authentication can be bypassed by enabling anonymous access: https://www.elastic.co/guide/en/elastic-stack-overview/7.4/anonymous-access.html.

spec:
  nodes:
  - nodeCount: 1
    config:
      xpack.security.authc:
          anonymous:
            username: anonymous
            roles: superuser
            authz_exception: false

Even in a private cluster, we don't recommend to turn off these security layers.
Obviously, it is up to you to make the decision :slight_smile:

3 Likes
3

How does this apply to Kibana? I've tried applying the settings above to my elasticsearch deployment, as well as the following on my Kibana deployment:

config:
  xpack.security.enabled: false

This causes the Kibana pods to get stuck on startup "Optimizing and caching bundled". Re-enabling xpack security causes them to be able to start up again.

4

Tried disabling TLS. It says:

Error from server (TLS cannot be disabled for Elasticsearch currently): error when creating "elasticsearch.yaml": admission webhook "validation.elasticsearch.elastic.co" denied the request: TLS cannot be disabled for Elasticsearch currently
5

Disabling xpack on Kibana forces replaying the optimization process responsible for generating JS bundles for all of the installed plugins.

This optimization process is very CPU/memory intensive and can take up to several minutes to complete depending on the underlying hardware.

I tested on my side and with the default Kibana resources, the Kibana pod is OOMKilled.

You can give more memory to your Kibana instance(s) to speed up this process. This is documented here: Manage compute resources | Elastic Cloud on Kubernetes [master] | Elastic.

By increasing the memory limit to 4Gi, it took 83s for me.

apiVersion: kibana.k8s.elastic.co/v1beta1
kind: Kibana
metadata:
  name: quickstart
spec:
  version: 7.4.0
  count: 1
  elasticsearchRef:
    name: quickstart
  config:
    xpack.security.enabled: false    
  podTemplate:
    spec:
      containers:
      - name: kibana
        resources:
          limits:
            memory: 4Gi
1 Like
6

Provided solution does not work.
Kibana pod does not get past thru readiness probes:

Events:
  Type     Reason     Age                   From                                   Message
  ----     ------     ----                  ----                                   -------
  Normal   Scheduled  4m37s                 default-scheduler                      Successfully assigned monitoring/quickstart-kb-56b8d49d6f-76jjf to ip-10-51-189-46.ec2.internal
  Normal   Pulled     4m36s                 kubelet, ip-10-51-189-46.ec2.internal  Container image "docker.elastic.co/kibana/kibana:7.5.1" already present on machine
  Normal   Created    4m36s                 kubelet, ip-10-51-189-46.ec2.internal  Created container kibana
  Normal   Started    4m36s                 kubelet, ip-10-51-189-46.ec2.internal  Started container kibana
  Warning  Unhealthy  62s (x4 over 92s)     kubelet, ip-10-51-189-46.ec2.internal  Readiness probe failed: Get https://10.51.176.85:5601/login: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
  Warning  Unhealthy  55s (x17 over 4m14s)  kubelet, ip-10-51-189-46.ec2.internal  Readiness probe failed: HTTP probe failed with statuscode: 503
  Warning  Unhealthy  47s                   kubelet, ip-10-51-189-46.ec2.internal  Readiness probe failed: HTTP probe failed with statuscode: 404
7

Overwrite readiness,

apiVersion: kibana.k8s.elastic.co/v1
kind: Kibana
metadata:
  name: cluster
spec:
  version: 7.6.0
  http:
    tls:
      selfSignedCertificate:
        disabled: true
  config:
    xpack.security.enabled: false
  podTemplate:
    spec:
      containers:
        - name: kibana
          resources:
            limits:
              memory: 4Gi
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /
              port: 5601
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 5
  count: 1
  elasticsearchRef:
    name: cluster
8

Hi,

can somebody confirm that this should stil work with the latest operator?
I have the following, which results in the readiness probe still returning a 401

---
apiVersion: kibana.k8s.elastic.co/v1
kind: Kibana
metadata:
  name: test
spec:
  version: 7.9.0
  count: 1
  elasticsearchRef:
    name: ci

  config:
    xpack.security.enabled: false
  http:
    tls:
      selfSignedCertificate:
        disabled: true
  podTemplate:
    metadata:
      labels:
        team: "sys"
      annotations:
        app.gitlab.com/env: ci
        app.gitlab.com/app: sys-logging-elk
    spec:
      containers:
        - name: kibana
          resources:
            limits:
              memory: 4Gi
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /
              port: 5601
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 5

regards,
strowi

9

Accessing / results in a request to Elasticsearch to locate the default space and requires authentication to succeed. This is why the default readiness probe uses /login. You can try using the /api/features path but the amount of data it returns could exceed the maximum payload size of the Kubernetes readiness probe and that could result in random failures down the line. You could try switching to a TCP probe but that wouldn't necessarily give you full confidence that Kibana is actually handling requests correctly.

10

Thx for the reply, but even disabling the readiness-probe, the pod starts, but i get a login-prompt from kibana returning:

 {"statusCode":401,"error":"Unauthorized","message":"[security_exception] missing authentication credentials for REST request [/.kibana/_search?size=1000&from=0&rest_total_hits_as_int=true], with { header={ WWW-Authenticate={ 0=\"Bearer realm=\\\"security\\\"\" & 1=\"ApiKey\" & 2=\"Basic realm=\\\"security\\\" charset=\\\"UTF-8\\\"\" } } }"}
11

Any news on this? I've got the same problem.

1 Like
13

After turn off X-Pack Security my Kibana stucks

2021-01-13T15:27:39.309011487Z {"type":"response","@timestamp":"2021-01-13T15:27:39Z","tags":[],"pid":7,"method":"get","statusCode":404,"req":{"url":"/login","method":"get","headers":{"host":"localhost:5601","user-agent":"kube-probe/1.18+","accept-encoding":"gzip","connection":"close"},"remoteAddress":"127.0.0.1","userAgent":"127.0.0.1"},"res":{"statusCode":404,"responseTime":34,"contentLength":9},"message":"GET /login 404 34ms - 9.0B"}
14

It is not possible to disable security, you can consider using anonymous access if don't need authentication.

15

I'm closing this topic, to sum up:

Feel free to open a new topic if you have any trouble with these settings.