Kibana openid integration not working on IPv6

Version info -
Elasticsearch version: - 7.0.1
Server OS version: - Centos 7.7
Kibana version (if relevant): - 7.0.1

Describe the issue:
Is the kibana-openid integration (Kibana OIDC Quick Start | Security for Elasticsearch | Search Guard) supported on IPv6 env?

I am running ELK (with searchguard) and keycloak in IPv6 environment. So my keycloak server’s well-known url is accessed as https://[ <{ipv6-addr}>]:/auth/realms//.well-known/openid-configuration.

With searchguard basic auth, kibana works fine.
But when I enable openid-authentication, I see such errors in kibana logs -

{“type”:“log”,“@timestamp”:“2020-05-06T12:54:56Z”,“tags”:[“error”,“searchguard”],“pid”:30774,“message”:“An error occurred while enabling session management: Error: Failed when trying to obtain the endpoints from your IdP”}
{“type”:“log”,“@timestamp”:“2020-05-06T12:54:56Z”,“tags”:[“status”,“plugin:searchguard@7.0.1-35.1.0”,“error”],“pid”:30774,“state”:“red”,“message”:“Status changed from yellow to red - An error occurred during initialisation, please check the logs.”,“prevState”:“yellow”,“prevMsg”:“‘searchguard.cookie.secure’ is set to false, cookies are transmitted over unsecure HTTP connection. Consider using HTTPS and set this key to ‘true’”}

After browsing through the code, I noticed in file /usr/share/kibana/plugins/searchguard/lib/auth/types/openid/OpenId.js ,in the method setupRoutes, Wreck.get was not responding with the response and so it is failing with above error.

const {response, payload} = await Wreck.get(this.config.get(‘searchguard.openid.connect_url’));

I added a line in the catch section to display the caught error. I saw this errror -

May 06 12:40:01 vm-10-75-47-82 kibana[13287]: { Error: getaddrinfo ENOTFOUND [2a00:8a00:6000:d094::15] [2a00:8a00:6000:d094::15]:31073
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:57:26)
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: errno: 'ENOTFOUND',
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: code: 'ENOTFOUND',
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: syscall: 'getaddrinfo',
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: hostname: '[2a00:8a00:6000:d094::15]',
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: host: '[2a00:8a00:6000:d094::15]',
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: port: 31073,
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: trace:
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: [ { method: 'GET',
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: url:
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: 'https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/.well-known/openid-configuration' } ],
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: isBoom: true,
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: isServer: true,
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: data: null,
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: output:
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: { statusCode: 502,
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: payload:
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: { message:
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: 'Client request error: getaddrinfo ENOTFOUND [2a00:8a00:6000:d094::15] [2a00:8a00:6000:d094::15]:31073',
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: statusCode: 502,
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: error: 'Bad Gateway' },
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: headers: {} },
May 06 12:40:01 vm-10-75-47-82 kibana[13287]: reformat: [Function] }

It seems this library is unable to reach the address. Can you pls help with what configurations would be needed for IPv6?

Expected behavior: Kibana to seamlessly work with openid (keycloak) integration. It works fine for me on IPv4 env.

Provide configuration:
kibana/config/kibana.yml:

server.host: “2a00:8a00:6000:d094:0:0:0:15”
elasticsearch.hosts: “https://[2a00:8a00:6000:d094:0:0:0:15]:30932”
elasticsearch.username: “admin”
elasticsearch.password: “admin”
searchguard.auth.type: “openid”
searchguard.openid.connect_url: “https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/.well-known/openid-configuration”
searchguard.openid.client_id: “elk-kibana”
searchguard.openid.client_secret: “fcf9f6b2-42d2-485d-ab78-551bee693a79”
searchguard.openid.header: “Authorization”
searchguard.openid.base_redirect_url: “https://[2a00:8a00:6000:d094:0.0.0:15]:5601”
searchguard.openid.root_ca: “/etc/kibana/keycloak-root-ca.pem”

What do you get if you execute this curl request from the Kibana server?

curl -k -6 "https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/.well-known/openid-configuration"

Using curl, the keycloak’s well-known url is reachable.

$ curl -g -k -6 “https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/.well-known/openid-configuration”
{“issuer”:“https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk”,“authorization_endpoint”:“https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/protocol/openid-connect/auth”,“token_endpoint”:“https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/protocol/openid-connect/token”,“token_introspection_endpoint”:“https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/protocol/openid-connect/token/introspect”,“userinfo_endpoint”:“https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/protocol/openid-connect/userinfo”,“end_session_endpoint”:“https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/protocol/openid-connect/logout”,“jwks_uri”:“https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/protocol/openid-connect/certs”,“check_session_iframe”:“https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/protocol/openid-connect/login-status-iframe.html”,“grant_types_supported”:[“authorization_code”,“implicit”,“refresh_token”,“password”,“client_credentials”],“response_types_supported”:[“code”,“none”,“id_token”,“token”,“id_token token”,“code id_token”,“code token”,“code id_token token”],“subject_types_supported”:[“public”,“pairwise”],“id_token_signing_alg_values_supported”:[“PS384”,“ES384”,“RS384”,“HS256”,“HS512”,“ES256”,“RS256”,“HS384”,“ES512”,“PS256”,“PS512”,“RS512”],“id_token_encryption_alg_values_supported”:[“RSA-OAEP”,“RSA1_5”],“id_token_encryption_enc_values_supported”:[“A128GCM”,“A128CBC-HS256”],“userinfo_signing_alg_values_supported”:[“PS384”,“ES384”,“RS384”,“HS256”,“HS512”,“ES256”,“RS256”,“HS384”,“ES512”,“PS256”,“PS512”,“RS512”,“none”],“request_object_signing_alg_values_supported”:[“PS384”,“ES384”,“RS384”,“ES256”,“RS256”,“ES512”,“PS256”,“PS512”,“RS512”,“none”],“response_modes_supported”:[“query”,“fragment”,“form_post”],“registration_endpoint”:“https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/clients-registrations/openid-connect”,“token_endpoint_auth_methods_supported”:[“private_key_jwt”,“client_secret_basic”,“client_secret_post”,“tls_client_auth”,“client_secret_jwt”],“token_endpoint_auth_signing_alg_values_supported”:[“PS384”,“ES384”,“RS384”,“ES256”,“RS256”,“ES512”,“PS256”,“PS512”,“RS512”],“claims_supported”:[“aud”,“sub”,“iss”,“auth_time”,“name”,“given_name”,“family_name”,“preferred_username”,“email”,“acr”],“claim_types_supported”:[“normal”],“claims_parameter_supported”:false,“scopes_supported”:[“openid”,“phone”,“offline_access”,“web-origins”,“email”,“roles”,“address”,“microprofile-jwt”,“profile”],“request_parameter_supported”:true,“request_uri_parameter_supported”:true,“code_challenge_methods_supported”:[“plain”,“S256”],“tls_client_certificate_bound_access_tokens”:true,“introspection_endpoint”:“https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/protocol/openid-connect/token/introspect”}

Let’s try to narrow down the scope of the issue.

First, try to substitute this line in the code by the following one and tell me what you get.

const {response, payload} = await Wreck.get(this.config.get(‘searchguard.openid.connect_url’), { family: 6 });

Second, execute the following JS script client.js from the Kibana server and send me the output.

$ NODE_DEBUG='net,tls,https' node client.js

client.js

const https = require('https');
const fs = require('fs');

// NODE_DEBUG='net,tls,https'
process.env["NODE_TLS_REJECT_UNAUTHORIZED"] = 0;

const options = {
	host: '[2a00:8a00:6000:d094:0:0:0:15]',
	port: 31073,
	path: '/auth/realms/elk/.well-known/openid-configuration',
	method: 'GET',
};

const req = https.request(options, function(res) {
	console.log("Client A statusCode: ", res.statusCode);
	console.log("Client A headers: ", res.headers);
	console.log("Server Host Name: "+ res.connection.getPeerCertificate().subject.CN);

	res.on('data', function(d) {
		process.stdout.write(d);
	});
});

req.end();

req.on('error', function(e) {
	console.error(e);
});

Hi,

With this line, I get the same error -

May 08 11:55:21 vm-10-75-47-82 kibana[15561]: { Error: getaddrinfo ENOTFOUND [2a00:8a00:6000:d094::15] [2a00:8a00:6000:d094::15]:31073
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:57:26)
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: errno: ‘ENOTFOUND’,
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: code: ‘ENOTFOUND’,
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: syscall: ‘getaddrinfo’,
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: hostname: ‘[2a00:8a00:6000:d094::15]’,
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: host: ‘[2a00:8a00:6000:d094::15]’,
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: port: 31073,
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: trace:
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: [ { method: ‘GET’,
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: url:
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: ‘https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/.well-known/openid-configuration’ } ],
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: isBoom: true,
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: isServer: true,
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: data: null,
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: output:
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: { statusCode: 502,
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: payload:
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: { message:
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: ‘Client request error: getaddrinfo ENOTFOUND [2a00:8a00:6000:d094::15] [2a00:8a00:6000:d094::15]:31073’,
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: statusCode: 502,
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: error: ‘Bad Gateway’ },
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: headers: {} },
May 08 11:55:21 vm-10-75-47-82 kibana[15561]: reformat: [Function] }

And next, sharing the output of the JS script -

[root@vm-10-75-47-82 searchguard]# NODE_DEBUG=‘net,tls,https’ /usr/share/kibana/node/bin/node client.js
HTTPS 26598: createConnection { servername: ‘2a00:8a00:6000:d094:0:0:0:15’,
_defaultAgent:
Agent {
_events: [Object: null prototype] { free: [Function] },
_eventsCount: 1,
_maxListeners: undefined,
defaultPort: 443,
protocol: ‘https:’,
options: { path: null },
requests: {},
sockets:
{ ‘[2a00:8a00:6000:d094:0:0:0:15]:31073:::::::::2a00:8a00:6000:d094:0:0:0:15:::::::’: },
freeSockets: {},
keepAliveMsecs: 1000,
keepAlive: false,
maxSockets: Infinity,
maxFreeSockets: 256,
maxCachedSessions: 100,
_sessionCache: { map: {}, list: } },
host: ‘[2a00:8a00:6000:d094:0:0:0:15]’,
port: 31073,
path: null,
method: ‘GET’,
_agentKey:
‘[2a00:8a00:6000:d094:0:0:0:15]:31073:::::::::2a00:8a00:6000:d094:0:0:0:15:::::::’,
encoding: null }
NET 26598: pipe false null
NET 26598: connect: find host [2a00:8a00:6000:d094:0:0:0:15]
NET 26598: connect: dns options { family: undefined, hints: 32 }
NET 26598: _read
NET 26598: _read wait for connection
NET 26598: destroy
NET 26598: close
NET 26598: close handle
{ Error: getaddrinfo ENOTFOUND [2a00:8a00:6000:d094:0:0:0:15] [2a00:8a00:6000:d094:0:0:0:15]:31073
at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:57:26)
errno: ‘ENOTFOUND’,
code: ‘ENOTFOUND’,
syscall: ‘getaddrinfo’,
hostname: ‘[2a00:8a00:6000:d094:0:0:0:15]’,
host: ‘[2a00:8a00:6000:d094:0:0:0:15]’,
port: 31073 }
NET 26598: emit close

You see the same error. And we don’t use any SearchGuard code or hapi/wreck in the client.js. The client uses the native Node.js https module. Thus the problem is at a lower level, Node.js side or lower. I think it is a configuration issue.

Open client.js and substitute host: '[2a00:8a00:6000:d094:0:0:0:15]' by host: '2a00:8a00:6000:d094:0:0:0:15'. Now execute and tell me what you see.

Demo

I did a test using the loopback IPv6 address ::1 and the HTTPS request worked.

server.js

const https = require('https');
const fs = require('fs');

const options = {
  key: fs.readFileSync('./kibana.key.pem'),
  cert: fs.readFileSync('./kibana.crtfull.pem')
};

https.createServer(options, function (req, res) {
  res.writeHead(200);
  res.end('hello world\n');
}).listen(3000, '::1');

client.js

const https = require('https');
const fs = require('fs');

process.env['NODE_TLS_REJECT_UNAUTHORIZED'] = 0;

const options = {
  host: '::1',
  port: 3000,
  path: '/home',
  method: 'GET',
};

const req = https.request(options, function(res) {
  console.log("Client A statusCode: ", res.statusCode);
  console.log("Client A headers: ", res.headers);
  console.log("Server Host Name: "+ res.connection.getPeerCertificate().subject.CN);
  
  res.on('data', function(d) {
    process.stdout.write(d);
  });
});

req.end();

req.on('error', function(e) {
  console.error(e);
});

Results

server

$ NODE_DEBUG='net,tls,https' node server.js
NET 16307: setupListenHandle ::1 3000 6 0 undefined
NET 16307: setupListenHandle: create a handle
NET 16307: bind to ::1

Send the client request you will see:

NET 16307: onconnection
NET 16307: _read
NET 16307: Socket._handle.readStart
TLS 16307: net.Server.on(connection): new TLSSocket
TLS 16307: server _init handle? true
TLS 16307: server initRead handle? true buffered? 0
NET 16307: _read
TLS 16307: server onhandshakestart
TLS 16307: server onhandshakedone
TLS 16307: server _finishInit handle? true alpn false servername ::1
TLS 16307: server emit secureConnection
NET 16307: _final: not ended, call shutdown()
NET 16307: afterShutdown destroyed=false ReadableState {
  objectMode: false,
  highWaterMark: 16384,
  buffer: BufferList { head: null, tail: null, length: 0 },
  length: 0,
  pipes: [],
  flowing: true,
  ended: false,
  endEmitted: false,
  reading: true,
  sync: false,
  needReadable: true,
  emittedReadable: false,
  readableListening: false,
  resumeScheduled: false,
  errorEmitted: false,
  emitClose: false,
  autoDestroy: false,
  destroyed: false,
  defaultEncoding: 'utf8',
  awaitDrainWriters: null,
  multiAwaitDrain: false,
  readingMore: false,
  decoder: null,
  encoding: null,
  [Symbol(kPaused)]: false
}
NET 16307: destroy
NET 16307: close
NET 16307: close handle
NET 16307: destroy
NET 16307: close
NET 16307: close handle
NET 16307: has server
NET 16307: SERVER _emitCloseIfDrained
NET 16307: SERVER handle? true   connections? 0
NET 16307: emit close
NET 16307: emit close

client

Notice the request was successful: TLS 16321: secure established, Client A statusCode: 200 and hello world.

$ NODE_DEBUG='net,tls,https' node  client.js
HTTPS 16321: createConnection { servername: '::1',
  _defaultAgent:
   Agent {
     _events: [Object: null prototype] { free: [Function] },
     _eventsCount: 1,
     _maxListeners: undefined,
     defaultPort: 443,
     protocol: 'https:',
     options: { path: null },
     requests: {},
     sockets: { '::1:3000::::::::::::::::::': [] },
     freeSockets: {},
     keepAliveMsecs: 1000,
     keepAlive: false,
     maxSockets: Infinity,
     maxFreeSockets: 256,
     maxCachedSessions: 100,
     _sessionCache: { map: {}, list: [] } },
  host: '::1',
  port: 3000,
  path: null,
  method: 'GET',
  _agentKey: '::1:3000::::::::::::::::::',
  encoding: null }
NET 16321: pipe false null
NET 16321: _read
NET 16321: _read wait for connection
NET 16321: afterConnect
TLS 16321: start
NET 16321: _read
NET 16321: Socket._read readStart
TLS 16321: secure established
NET 16321: afterWrite 0
NET 16321: afterWrite call cb
Client A statusCode:  200
Client A headers:  { date: 'Fri, 08 May 2020 12:59:50 GMT',
  connection: 'close',
  'transfer-encoding': 'chunked' }
Server Host Name: kibana
hello world
NET 16321: _read
NET 16321: _final: not ended, call shutdown()
NET 16321: afterShutdown destroyed=false ReadableState {
  objectMode: false,
  highWaterMark: 16384,
  buffer: BufferList { head: null, tail: null, length: 0 },
  length: 0,
  pipes: null,
  pipesCount: 0,
  flowing: true,
  ended: false,
  endEmitted: false,
  reading: true,
  sync: false,
  needReadable: true,
  emittedReadable: false,
  readableListening: false,
  resumeScheduled: false,
  paused: false,
  emitClose: false,
  autoDestroy: false,
  destroyed: false,
  defaultEncoding: 'utf8',
  awaitDrain: 0,
  readingMore: false,
  decoder: null,
  encoding: null }
NET 16321: destroy
NET 16321: close
NET 16321: close handle
NET 16321: emit close

Yes, this does give the response.

$ NODE_DEBUG=‘net,tls,https’ /usr/share/kibana/node/bin/node client.js
TLS 28774: start
TLS 28774: secure established
Client A statusCode: 200
Client A headers: { connection: ‘close’,
‘cache-control’: ‘no-cache, must-revalidate, no-transform, no-store’,
‘content-type’: ‘application/json’,
‘content-length’: ‘2816’,
date: ‘Fri, 08 May 2020 13:37:02 GMT’ }
Server Host Name: 2a00:8a00:6000:d094::15
{“issuer”:“https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk”,“authorization_endpoint”:“https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/protocol/openid-connect/auth”,“token_endpoint”:“https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/protocol/openid-connect/token”,“token_introspection_endpoint”:“https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/protocol/openid-connect/token/introspect”,“userinfo_endpoint”:“https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/protocol/openid-connect/userinfo”,“end_session_endpoint”:“https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/protocol/openid-connect/logout”,“jwks_uri”:“https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/protocol/openid-connect/certs”,“check_session_iframe”:“https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/protocol/openid-connect/login-status-iframe.html”,“grant_types_supported”:[“authorization_code”,“implicit”,“refresh_token”,“password”,“client_credentials”],“response_types_supported”:[“code”,“none”,“id_token”,“token”,“id_token token”,“code id_token”,“code token”,“code id_token token”],“subject_types_supported”:[“public”,“pairwise”],“id_token_signing_alg_values_supported”:[“PS384”,“ES384”,“RS384”,“HS256”,“HS512”,“ES256”,“RS256”,“HS384”,“ES512”,“PS256”,“PS512”,“RS512”],“id_token_encryption_alg_values_supported”:[“RSA-OAEP”,“RSA1_5”],“id_token_encryption_enc_values_supported”:[“A128GCM”,“A128CBC-HS256”],“userinfo_signing_alg_values_supported”:[“PS384”,“ES384”,“RS384”,“HS256”,“HS512”,“ES256”,“RS256”,“HS384”,“ES512”,“PS256”,“PS512”,“RS512”,“none”],“request_object_signing_alg_values_supported”:[“PS384”,“ES384”,“RS384”,“ES256”,“RS256”,“ES512”,“PS256”,“PS512”,“RS512”,“none”],“response_modes_supported”:[“query”,“fragment”,“form_post”],“registration_endpoint”:“https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/clients-registrations/openid-connect”,“token_endpoint_auth_methods_supported”:[“private_key_jwt”,“client_secret_basic”,“client_secret_post”,“tls_client_auth”,“client_secret_jwt”],“token_endpoint_auth_signing_alg_values_supported”:[“PS384”,“ES384”,“RS384”,“ES256”,“RS256”,“ES512”,“PS256”,“PS512”,“RS512”],“claims_supported”:[“aud”,“sub”,“iss”,“auth_time”,“name”,“given_name”,“family_name”,“preferred_username”,“email”,“acr”],“claim_types_supported”:[“normal”],“claims_parameter_supported”:false,“scopes_supported”:[“openid”,“phone”,“offline_access”,“web-origins”,“email”,“roles”,“address”,“microprofile-jwt”,“profile”],“request_parameter_supported”:true,“request_uri_parameter_supported”:true,“code_challenge_methods_supported”:[“plain”,“S256”],“tls_client_certificate_bound_access_tokens”:true,“introspection_endpoint”:“https://[2a00:8a00:6000:d094:0:0:0:15]:31073/auth/realms/elk/protocol/openid-connect/token/introspect”}

Next, I tried configuring keycloak server’s IP in kibana.yml without [ ], but it fails with invalid url error -

May 08 13:41:24 vm-10-75-47-82 kibana[4342]: { TypeError [ERR_INVALID_URL]: Invalid URL: https://2a00:8a00:6000:d094:0:0:0:15:31073/auth/realms/elk/.well-known/openid-configuration
May 08 13:41:24 vm-10-75-47-82 kibana[4342]: at onParseError (internal/url.js:241:17)
May 08 13:41:24 vm-10-75-47-82 kibana[4342]: at parse (internal/url.js:257:3)
May 08 13:41:24 vm-10-75-47-82 kibana[4342]: at new URL (internal/url.js:332:5)
May 08 13:41:24 vm-10-75-47-82 kibana[4342]: at internals.Client._request (/usr/share/kibana/plugins/searchguard/node_modules/wreck/lib/index.js:137:21)
May 08 13:41:24 vm-10-75-47-82 kibana[4342]: at internals.Client.request (/usr/share/kibana/plugins/searchguard/node_modules/wreck/lib/index.js:106:22)
May 08 13:41:24 vm-10-75-47-82 kibana[4342]: at internals.Client._shortcut (/usr/share/kibana/plugins/searchguard/node_modules/wreck/lib/index.js:621:28)
May 08 13:41:24 vm-10-75-47-82 kibana[4342]: at internals.Client.get (/usr/share/kibana/plugins/searchguard/node_modules/wreck/lib/index.js:591:17)
May 08 13:41:24 vm-10-75-47-82 kibana[4342]: at OpenId.setupRoutes (/usr/share/kibana/plugins/searchguard/lib/auth/types/openid/OpenId.js:118:53)
May 08 13:41:24 vm-10-75-47-82 kibana[4342]: at OpenId.init (/usr/share/kibana/plugins/searchguard/lib/auth/types/AuthType.js:83:20)
May 08 13:41:24 vm-10-75-47-82 kibana[4342]: at Plugin.init [as externalInit] (/usr/share/kibana/plugins/searchguard/index.js:389:45)
May 08 13:41:24 vm-10-75-47-82 kibana[4342]: input:
May 08 13:41:24 vm-10-75-47-82 kibana[4342]: ‘https://2a00:8a00:6000:d094:0:0:0:15:31073/auth/realms/elk/.well-known/openid-configuration’ }

Many thanks for the analysis :slight_smile: .Now, how do you think we can resolve the issue?

Hi. I tested some and saw Wreck is unable to send a HTTP request if a IPv6 address is used. I created the related issue on the @hapi repository. Let’s see what @hapi responds.

The wreck usage was deprecated in v7.10.x-49.0.0. I think it should for you now.

1 Like