Feature: ability to specify multiple certificate authorities

[adongy]

Describe the feature:

I'd like to be able to specify multiple certificate authorities for the security settings of my cluster.

Currently, the playbook only supports a single file:

ansible-elasticsearch/tasks/elasticsearch-ssl.yml

Lines 59 to 69 in 37fc61b

	- name: Upload SSL Certificate Authority
	become: yes
	copy:
	src: "{{ es_ssl_certificate_authority }}"
	dest: "{{ es_ssl_certificate_path }}/{{ es_ssl_certificate_authority | basename }}"
	owner: "{{ es_user }}"
	group: "{{ es_group }}"
	mode: "640"
	#Restart if this changes
	notify: restart elasticsearch
	when: (es_ssl_certificate_authority is defined) and (es_ssl_certificate_authority|length > 0)

ansible-elasticsearch/templates/elasticsearch.yml.j2

Lines 46 to 48 in cab03ec

	{% if es_ssl_certificate_authority %}
	xpack.security.transport.ssl.certificate_authorities: "{{ es_ssl_certificate_path }}/{{ es_ssl_certificate_authority | basename }}"
	{% endif %}

ansible-elasticsearch/templates/elasticsearch.yml.j2

Lines 60 to 62 in cab03ec

	{% if es_ssl_certificate_authority %}
	xpack.security.http.ssl.certificate_authorities: "{{ es_ssl_certificate_path }}/{{ es_ssl_certificate_authority | basename }}"
	{% endif %}

The official documentation describes the parameters as a "List of paths to PEM encoded certificate files that should be trusted." https://www.elastic.co/guide/en/elasticsearch/reference/current/security-settings.html#_pem_encoded_files_2

My usecase is rolling updates of certificate authorities without cluster downtime.

Currently, Elasticsearch dynamically reloads certificates when they are updated.
When the verification_mode is set to certificate or full, if the new certificate is signed by the CA, the update is transparent: other cluster nodes will still validate the certificate and continue communication.

Best practices for CAs recommend rotating the authority regularly. If there is only one file declared in the configuration, as soon as a node reloads the new authority, it will not accept communication with other cluster nodes that have not updated their certificate to be signed by the new authority.

A solution to this is having multiple certificate authorities declared, replace one of them with the new authority while keeping the old one, update each node's certificates to be signed by the new authority, and remove the old authority at the end.

---

In our case, the playbook could be updated in a retrocompatible way by checking the variable type: variable is string is true when it's a string and false when it's a list (unfortunately, strings will pass both of the string and sequence test). It should work for both the jinja template and the tasks.

Thanks!

[adongy]

In addition to this, I'd like to add that since elasticsearch dynamically reloads certificates without the need for a restart, I currently need to set es_restart_on_change to false.

One another solution would be to template the tls part in the elasticsearch.yml configuration file, and mange certificate rotation in a different part of my playbook, but I would need to be able to specify a custom template for elasticsearch.yml.j2, as I am unaware of a feature in Ansible that would allow me to override templates in a role.

[botelastic]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[adongy]

I'm still looking for this improvement.

[jmlrt]

Hi @adongy,
Thanks for opening this issue.
Unfortunately we currently don't have time to work on it so please be patient.

[iorfix]

Another issue is that it should be better to have a CA for transport layer, and another for "public/beat" connection, i.e. different configs for xpack.security.transport.ssl and xpack.security.http.ssl I have an internal CA that manages cluster nodes, while another one is used to validate inblound connections from clients.

[botelastic]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jmlrt]

still valid

[jmlrt]

still valid

[botelastic]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jmlrt]

still valid

[botelastic]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jmlrt]

still valid

[botelastic]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[sahibthg]

still valid

[botelastic]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.