Kibana can't sign in

Kibana is not accepting the default elasticsearch-master-credentials

The following ELK stack configuration is all version 8.5.1 running in a single node cluster:

pod/elasticsearch-master-0       1/1     Running   0          28m
pod/logstash-0                   1/1     Running   0          28m
pod/elk-filebeat-j78fx           1/1     Running   0          28m
pod/elk-kibana-8596dcf6c-rdpzt   1/1     Running   0          25m

NAME                                    TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGE
service/logstash-headless               ClusterIP   None           <none>        9600/TCP            28m
service/elasticsearch-master-headless   ClusterIP   None           <none>        9200/TCP,9300/TCP   28m
service/logstash                        ClusterIP   10.43.12.129   <none>        5044/TCP,8080/TCP   28m
service/elasticsearch-master            ClusterIP   10.43.206.4    <none>        9200/TCP,9300/TCP   28m
service/elk-kibana                      ClusterIP   10.43.185.0    <none>        5601/TCP            25m

NAME                          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/elk-filebeat   1         1         1       1            1           <none>          28m

NAME                         READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/elk-kibana   1/1     1            1           25m

NAME                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/elk-kibana-8596dcf6c   1         1         1       25m

NAME                                    READY   AGE
statefulset.apps/elasticsearch-master   1/1     28m
statefulset.apps/logstash               1/1     28m

I port forward the kibana service and receive the Welcome to Elastic log on screen when connecting to http://www.localhost:5602/login

To log in I utilize the default elasticsearch-master-credentials username and password via

echo $(kubectl get secrets -n analytics elasticsearch-master-credentials -ojsonpath='{.data.username}' | base64 -d)
elastic
echo $(kubectl get secrets -n analytics elasticsearch-master-credentials -ojsonpath='{.data.password}' | base64 -d)
XSVoEFBANicJNZ3q

When attempting to log in, I receive the Username or password is incorrect. Please try again. error message and see the below in the elasticsearch POD log.

{"@timestamp":"2023-07-24T19:15:20.922Z", "log.level": "INFO", "message":"Authentication of [elastic] was terminated by realm [reserved] - failed to authenticate user [elastic]", "ecs.version": "1.2.0","service.name":"ES_ECS","event.dataset":"elasticsearch.server","process.thread.name":"elasticsearch[elasticsearch-master-0][system_critical_read][T#1]","log.logger":"org.elasticsearch.xpack.security.authc.RealmsAuthenticator","trace.id":"87d4f012851ecf678aa090d8cd662881","elasticsearch.cluster.uuid":"qti4HuKWS7ewy2HWIlu9KQ","elasticsearch.node.id":"16fM8XeXQ0KiY0uCtnetKg","elasticsearch.node.name":"elasticsearch-master-0","elasticsearch.cluster.name":"elasticsearch"}

Kibana:

[2023-07-24T19:15:20.844+00:00][INFO ][plugins.security.routes] Logging in with provider "basic" (basic)

Additional tests.

Check the decoded data of the elasticsearch-master-certs which contained:

ca.crt
tls.crt
tls.key

Matched the credentials at /usr/share/elasticsearch/config/certs within the elasticsearch container located. Both credential sets match.

Setup a port-forward for to access port 9200 of the elasticsearch container locally:

kubectl port-forward service/elasticsearch-master 9200:9200 -n analytics
Forwarding from 127.0.0.1:9200 -> 9200
Forwarding from [::1]:9200 -> 9200
Handling connection for 9200

Yet curl fails to get the cluster health so my issue appears to be with Elasticsearch? I can paste the full Elasticsearch logs here if they are of any benefit.

$curl -X GET "https://localhost:9200/_cluster/health" --key esearch_tls.crt -k -u elastic:XSVoEFBANicJNZ3q --verbose
vagrant@dd-ubuntu2204-sscld120npwd-a4f08c:~$ curl -X GET "https://localhost:9200/_cluster/health" --key esearch_tls.crt -k -u elastic:XSVoEFBANicJNZ3q --verbose
Note: Unnecessary use of -X or --request, GET is already inferred.
* Uses proxy env variable no_proxy == 'localhost,127.0.0.1'
*   Trying 127.0.0.1:9200...
* Connected to localhost (127.0.0.1) port 9200 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=elasticsearch-master
*  start date: Jul 24 19:09:51 2023 GMT
*  expire date: Jul 23 19:09:51 2024 GMT
*  issuer: CN=elasticsearch-ca
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Server auth using Basic with user 'elastic'
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET /_cluster/health HTTP/1.1
> Host: localhost:9200
> Authorization: Basic ZWxhc3RpYzpYU1ZvRUZCQU5pY0pOWjNx
> User-Agent: curl/7.81.0
> Accept: */*
> 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 Unauthorized
* Authentication problem. Ignoring this.
< WWW-Authenticate: Basic realm="security" charset="UTF-8"
< WWW-Authenticate: Bearer realm="security"
< WWW-Authenticate: ApiKey
< content-type: application/json;charset=utf-8
< content-length: 495
< 
* Connection #0 to host localhost left intact
{"error":{"root_cause":[{"type":"security_exception","reason":"unable to authenticate user [elastic] for REST request [/_cluster/health]","header":{"WWW-Authenticate":["Basic realm=\"security\" charset=\"UTF-8\"","Bearer realm=\"security\"","ApiKey"]}}],"type":"security_exception","reason":"unable to authenticate user [elastic] for REST request [/_cluster/health]","header":{"WWW-Authenticate":["Basic realm=\"security\" charset=\"UTF-8\"","Bearer realm=\"security\"","ApiKey"]}},"status":401}

Turns out the issue was on my end with the secret generation being overwritten. All works now.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.