OpenID Connect stand-alone Elastic with Keycloak

I would like to have a single node ES (no Kibana involved) authenticate against Keycloak for all requests.

I've followed the OpenID Connect without Kibana documentation to the best of my knowledge. However, this and the openID documentation on ES revolves around a redirect uri and external web app. I'm stuck on this because the intention here is to have, among other things, back-end code authenticate against Keycloak as a requirement for hitting ES (with no web apps involved).

My docker-compose file:

version: "2.2"

      - certs:/usr/share/elasticsearch/config/certs
    user: "0"
    command: >
      bash -c '
        if [ x${ELASTIC_PASSWORD} == x ]; then
          echo "Set the ELASTIC_PASSWORD environment variable in the .env file";
          exit 1;
        elif [ x${KIBANA_PASSWORD} == x ]; then
          echo "Set the KIBANA_PASSWORD environment variable in the .env file";
          exit 1;
        if [ ! -f config/certs/ ]; then
          echo "Creating CA";
          bin/elasticsearch-certutil ca --silent --pem -out config/certs/;
          unzip config/certs/ -d config/certs;
        if [ ! -f config/certs/ ]; then
          echo "Creating certs";
          echo -ne \
          "  - name: es01\n"\
          "    dns:\n"\
          "      - es01\n"\
          "      - localhost\n"\
          "    ip:\n"\
          "      -\n"\
          > config/certs/instances.yml;
          bin/elasticsearch-certutil cert --silent --pem -out config/certs/ --in config/certs/instances.yml --ca-cert config/certs/ca/ca.crt --ca-key config/certs/ca/ca.key;
          unzip config/certs/ -d config/certs;
        echo "Setting file permissions"
        chown -R root:root config/certs;
        find . -type d -exec chmod 750 \{\} \;;
        find . -type f -exec chmod 640 \{\} \;;
        echo "Waiting for Elasticsearch availability";
        until curl -s --cacert config/certs/ca/ca.crt https://es01:9200 | grep -q "missing authentication credentials"; do sleep 30; done;
        echo "Setting kibana_system password";
        until curl -s -X POST --cacert config/certs/ca/ca.crt -u "elastic:${ELASTIC_PASSWORD}" -H "Content-Type: application/json" https://es01:9200/_security/user/kibana_system/_password -d "{\"password\":\"${KIBANA_PASSWORD}\"}" | grep -q "^{}"; do sleep 10; done;
        echo "All done!";
      test: ["CMD-SHELL", "[ -f config/certs/es01/es01.crt ]"]
      interval: 1s
      timeout: 5s
      retries: 120

        condition: service_healthy
      - certs:/usr/share/elasticsearch/config/certs
      - esdata01:/usr/share/elasticsearch/data
      - type: bind
        source: ./elasticsearch.yml
        target: /usr/share/elasticsearch/config/elasticsearch.yml
        read_only: true
      - type: bind
        source: ./certs.json
        target: /usr/share/elasticsearch/config/certs.json
        read_only: true
      - ${ES_PORT}:9200
      - cluster.initial_master_nodes=es01
      # - cluster.initial_master_nodes=es01,es02,es03
      # - discovery.seed_hosts=es02,es03
      - bootstrap.memory_lock=true
      - xpack.license.self_generated.type=${LICENSE}
    mem_limit: ${MEM_LIMIT}
        soft: -1
        hard: -1
          "curl -s --cacert config/certs/ca/ca.crt https://localhost:9200 | grep -q 'missing authentication credentials'",
      interval: 10s
      timeout: 10s
      retries: 120

    driver: local
    driver: local


# Password for the 'elastic' user (at least 6 characters)

# Password for the 'kibana_system' user (at least 6 characters)

# Version of Elastic products

# Set the cluster name

# Set to 'basic' or 'trial' to automatically start the 30-day trial
# LICENSE=basic

# Port to expose Elasticsearch HTTP API to the host

# Port to expose Kibana to the host

# Increase or decrease based on the available host memory (in bytes)

# Project namespace (defaults to the current folder name if not set)

Elasticsearch.yml "docker-cluster"

# true
#   order: 2
#   rp.client_id: "elasticsearch"
#   rp.response_type: code
#   rp.redirect_uri: ""
#   op.issuer: "http://localhost:8080/auth/realms/Elastic"
#   op.authorization_endpoint: "http://localhost:8080/auth/realms/Elastic/protocol/openid-connect/auth"
#   op.token_endpoint: "http://localhost:8080/auth/realms/Elastic/protocol/openid-connect/token"
#   op.jwkset_path: "certs.json"
#   op.userinfo_endpoint: "http://localhost:8080/auth/realms/Elastic/protocol/openid-connect/userinfo"
#   op.endsession_endpoint: "http://localhost:8080/auth/realms/Elastic/protocol/openid-connect/logout"
#   rp.post_logout_redirect_uri: ""
#   claims.principal: preferred_username

My keycloak instance is running at http://localhost:8080
with a realm "Elastic" and client "elasticsearch"

So far my process is:

  • run docker-compose up -d

  • Inside the elasticsearch container:

    • Run ./bin/elasticsearch-keystore add and add the client secret under the Keycloak Realm's Client's Credentials section.

    • Uncomment all the lines in elasticsearch.yml

  • Restart ES container

Then, following the OpenID Connect without Kibana steps, I:

	"redirect": "http://localhost:8080/auth/realms/Elastic/protocol/openid-connect/auth?response_type=code&redirect_uri=https%3A%2F%2F127.0.0.1%3A9200&state=Hw-RDYrwwFFUYw_9fGFYWsXyWEReCjlkdIMfKz2uBYY&nonce=jerbpKm5n2i48OGS-z5H47oTXcEL33bSOKSrfRlPQGY&client_id=elasticsearch&scope=openid",
	"state": "Hw-RDYrwwFFUYw_9fGFYWsXyWEReCjlkdIMfKz2uBYY",
	"nonce": "jerbpKm5n2i48OGS-z5H47oTXcEL33bSOKSrfRlPQGY",
	"realm": "oidc1"

This is where I am unsure on how to proceed with the Authentication flow. In my elasticsearch.yml I don't know what to put as rp.redirect_uri and rp.post_logout_redirect_uri (my ES endpoint is just a filler/guess) given that there is no other web app involved. I'm sure it makes the redirect url returned invalid right now because keycloak gives a 400 error to it.

That is not something that OpenID Connect can do. It is explicitly a protocol for logging into a client that can handle flows, it isn't just a backend for username/password (and can't be used that way).

From the official OpenID Connect page:

It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

If you don't have an OIDC aware client (e.g. a webapp, or a native client), you can't use OIDC. There is nothing in OIDC that allows an API server like Elasticsearch to authenticate REST requests via OIDC.

(OK, technically I lied, it is possible to hack something together via the OIDC implicit flow, but it's an abuse of OIDC, and Elasticsearch doesn't currently support it, nor do we have plans to do so)

1 Like

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