Basic authentication on ES helm chart

Elastic Stack Elasticsearch
,
1

i want setup basic authentication on helm cluster. helm ES chart using :https://github.com/elastic/helm-charts/tree/master/elasticsearch

i am confuse about using setting parameters in elasticsearch.yaml

right now i have added

elasticsearch.yml: |
    xpack.security.enabled: true
    xpack.security.transport.ssl.enabled: true
    xpack.security.transport.ssl.verification_mode: certificate
    xpack.security.transport.ssl.keystore.path: /usr/share/elasticsearch/config/certs/elastic-certificates.p12
    xpack.security.transport.ssl.truststore.path: /usr/share/elasticsearch/config/certs/elastic-certificates.p12
    xpack.security.http.ssl.enabled: true
    xpack.security.http.ssl.truststore.path: /usr/share/elasticsearch/config/certs/elastic-certificates.p12
    xpack.security.http.ssl.keystore.path: /usr/share/elasticsearch/config/certs/elastic-certificates.p12
    xpack.security.authc.realms.native.local.order: 0

but try connecting over curl it's not working since SSL is self sign

if try with curl insecure mode it's working fine

i just want to setup basic auth username password even do not want protocol HTTPS. will work if it's http. i do not want to add any type certificate webserver side and manage it when making connection to ES cluster.

some one suggested me to use :

elasticsearch.yml: |

xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: /usr/share/elasticsearch/config/certs/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: /usr/share/elasticsearch/config/certs/elastic-certificates.p12
xpack.security.authc.realms.native.local.order: 0

remove all http.ssl.* is it okay ? Please help

2

did you tried ?
curl --cacert $path_to_certificate https://host_ip:9200

1 Like
3

thanks for writing back answer. but shoud i have to send certificates when requesting from application ?

in application we are passing basic auth in header something similar :

curl -H "Authorization: Basic ZpYzdsfsdfsdfo1KXQw==" localhost:9200

4

Those are bootstrap checks forced by elasticsearch cluster
When you enable security and you force nodes to bootstrap on external IP, SSL is a must
and yes of course your app need the certificate to communicate with elasticsearch cluster

1 Like
5

Thanks a lot. Please confirm or correct if i am wrong.

if i have to run cluster on https i have to send certificate from application side also.

for basic auth setup also adding certificate is necesarry ?

if i want just run basic auth without HTTPS just http ? you see any issue in it ? application and ES both in private network.

if i remove

xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.truststore.path: /usr/share/elasticsearch/config/certs/elastic-certificates.p12
xpack.security.http.ssl.keystore.path: /usr/share/elasticsearch/config/certs/elastic-certificates.p12

it's working as expected over HTTP protocol.

6

If your cluster is a single node, all you need is :

discovery.type: single-node
xpack.security.enabled: true

This will work fine as you are sure everything is only for internal uses ....
enabling SSL between nodes, clients and elasticsearch cluster, kibana ... etc is a must to secure exchanges on the network even if basic authentification is enabled

Now if you enable SSL, Yes of course you need to send the cert to the app, here is an example with nodeJS

    const { Client } = require('@elastic/elasticsearch');
// Include fs module
const fs = require('fs');
    const client = new Client({
      node: 'http://localhost:9200',
      maxRetries: 1,
      requestTimeout: 30000,
      sniffOnStart: false,
      keepAlive: false,
      log: 'trace',
      auth: {
        username: 'elastic',
        password: 'changeme',
      },
      ssl: {
        ca: fs.readFileSync('/es/labs/kibana/config/ca.crt'),
        rejectUnauthorized: false,
      },
    });

Same if you are using Kibana

# If your Elasticsearch is protected with basic authentication, these settings provide
# the username and password that the Kibana server uses to perform maintenance on the Kibana
# index at startup. Your Kibana users still need to authenticate with Elasticsearch, which
# is proxied through the Kibana server.
elasticsearch.username: "kbn_user"
elasticsearch.password: "changeme"

# Enables SSL and paths to the PEM-format SSL certificate and SSL key files, respectively.
# These settings enable SSL for outgoing requests from the Kibana server to the browser.
server.ssl.enabled: true
server.ssl.certificate: /es/labs/kibana/config/meetup.crt
server.ssl.key: /es/labs/kibana/config/meetup.key

# Optional settings that provide the paths to the PEM-format SSL certificate and key files.
# These files are used to verify the identity of Kibana to Elasticsearch and are required when
# xpack.security.http.ssl.client_authentication in Elasticsearch is set to required.
elasticsearch.ssl.certificate: /es/labs/kibana/config/meetup.crt
elasticsearch.ssl.key: /es/labs/kibana/config/meetup.key

# Optional setting that enables you to specify a path to the PEM file for the certificate
# authority for your Elasticsearch instance.
elasticsearch.ssl.certificateAuthorities: [ "/es/labs/kibana/config/ca.crt" ]
1 Like
7

Isn't it possible we can use HTTPS protocol with username and password by passing header.

When generating DNS for private cluster what should be DNS name ? Kubernetes svc name?

8

As per this tutorial they are not passing certificate in curl request or we can say not with application. https://pimwiddershoven.nl/entry/deploy-a-secure-instance-of-elasticsearch-on-kubernetes

9

You can do that, however it will prevent a some features (e.g. API Keys) from being enabled.

No, if you run a cluster on https, then the client needs to decide whether to trust the certificate that is provided by the server. There are 3 main ways that could happen:

  1. Your server uses a certificate that is issued by one of the default issuing authorities (CAs) that your client already trusts.
  2. Your client is configured to trust a specific certificate or CA for this specific connection (e.g. using the --cacert option to curl)
  3. Your client just trusts everything (e.g. the --insecure option to curl).

Any of those will be more secure than turning off ssl.

1 Like
10

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