Hi there, is there any way to configure additional authentication methods for Bimbeats to use in the NEST client data sources? It looks like it’s all using basic authentication with the Bimbeats service account used for deployment. On the Logstash side of things, we’re able to edit the Beats config files to add additional layers of security like client/service certificate validation, something we’re hoping to do with the entire Bimbeats deployment.
This might include two modifications to the HttpConnection in the ElasticClient:
Using a client certificate that either could be used as the authentication method (using PKI authentication in Elastic) or for client validation if there’s a proxy between the Elastic cluster and the client
Enabling default credentials for Kerberos-enabled clusters
Here’s what each of those could look like in code, obviously most logic would be required when enabling these based on install configuration options, but wanted to save some research time for you if you want to look into this.
Client Certificate
public class ClientCertificateHttpConnection : HttpConnection
{
protected override HttpMessageHandler CreateHttpClientHandler(RequestData requestData)
{
X509Certificate2 certificate = new X509Certificate2(<CertificateFile>, <SecureString pw>);
var handler = (HttpClientHandler)base.CreateHttpClientHandler(requestData);
handler.ClientCertificateOptions = ClientCertificateOption.Manual;
handler.ClientCertificates.Add(certificate);
return handler;
}
}
Enabling default credentials for Kerberos-enabled clusters
public class NetworkCredentialsHttpConnection : HttpConnection
{
protected override HttpMessageHandler CreateHttpClientHandler(RequestData requestData)
{
var handler = (HttpClientHandler)base.CreateHttpClientHandler(requestData);
handler.UseDefaultCredentials = true;
handler.PreAuthenticate = true;
return handler;
}
}
Thanks and let me know if you have any questions about this at all.
@dan.siroky you are the first poster on the forum. Congrats!
OK, now on the actual question. Yes, we are currently using NEST’s basic authentication (username, password). Looking into NEST’s documentation on the available options we could be using an API Key or Base64 Encoded API Key.
It looks like they also have options for adding Client Certificates that then would be used for all HTTP requests. I don’t mind looking into all of the above. I am certain an API Key authentication routine wouldn’t be too hard to setup on our end instead of using the username/password.
Do you have a preference for the actual authentication routine, or you just want to add certificates to the existing setup? If you want to add a certificate to the setup, the thing that currently bothers me is that we would need to ship that CA file to every end user. The best way to do that would be by embedding it into our installer. That’s doable, as we have some clients that we built a custom installer for that that specific purpose. It’s an OK method for custom, on off situations, but as a general deployment strategy it’s a little less feasible, as it would require that we build a custom MSI for every client that wanted to have certificates embedded/extra layer of protection.
On the flipside, I don’t see an issue with allowing API Keys to be used instead of username/password. That shouldn’t be too hard.
Thanks for the response and sorry for the delay. We have been testing out a few methods that would allow for both internal and external traffic to authenticate using client certificates + other methods.
For the client certificate piece, I was thinking you could pass paths to a certificate and a key for the client to use in the ConnectionSettings. This is what we do with Metric/Audit/Filebeat on top of the typical deployment:
As for validating the server CA, I think that will be handled by Windows and having the CA installed on client machines, so no extra work needed there IMO.
For the authentication piece, we’re thinking that we could generate a user-specific API key on the user’s machine at some interval, then store the API key information in the registry. Then Bimbeats could refer to this registry key, and if we update it outside of BimBeats, it will use the new key on the next time a BimBeats client is run. This way we can avoid non-expiring keys, update them when they’re off network, but not ask you to implement any of that
@dan.siroky this was resolved and implemented in the latest version (v36). It will be ready to go out sometime in January. Thank you for reporting this and working with us on implementing these changes. Much appreciated!
