Versions (relevant - OpenSearch/Dashboard/Server OS/Browser):
Version 2.10
Ubuntu 22.04
Describe the issue:
Is it feasible to utilize distinct root CA certificates for transport-layer and REST-layer communications? Specifically, I’d like to implement a self-signed root CA certificate for transport-layer (node-to-node) communication, while employing a trusted Certificate Authority for the REST-layer (client-to-node) traffic.
Can this configuration be achieved? Additionally, is it possible to utilize the securityadmin.sh script to update the security settings accordingly?
@hm21 That is possible. The HTTP and Transport layer certificates can be different.
You need to use the correct root-ca.pem for each layer.
securityadmin.sh uses HTTP endpoint (9200) to communicate with the cluster.
As long as the admin certificate, defined in plugins.security.authcz.admin_dn, is signed with the root-ca.pem specified in the plugins.security.ssl.http.pemtrustedcas_filepath should work.
Wonderful!
Does something speak against adding the dashboards certificate (which is created by the trusted CA) to plugins.security.authcz.admin_dn and not having a distinct admin certificate?
Well, I would say a lot. If anyone compromises your dashboards’ certificate, will have full access to the security config. If you’re planning to use the dashboards’ certificate to authenticate with OpenSearch then files must be placed in the filesystem of the OpenSearch Dashboards so it can be accessible during the startup.
When you define admin certificates in the plugins.security.authcz.admin_dn you don’t have to keep those certificates in the OpenSearch filesystem. These certs must be accessible to the securityadmin.sh script.
That means if I have OpenSearch & OpenSearch Dashboards deployed in containers then I should be able to execute the securityadmin.sh script outside of the opensearch container. How to do that?