Skip to content

Conversation

edmocosta
Copy link
Contributor

@edmocosta edmocosta commented Feb 28, 2023

What this PR does?

Added the following SSL settings:
ssl_truststore_type: The format of the truststore file
ssl_keystore_type: The format of the keystore file
ssl_certificate: OpenSSL-style X.509 certificate file to authenticate the client
ssl_key: OpenSSL-style RSA private key that corresponds to the ssl_certificate
ssl_cipher_suites: The list of cipher suites

Reviewed and deprecated the following SSL settings to comply with Logstash's naming convention:
ssl in favor of ssl_enabled
cacert in favor of ssl_certificate_authorities
keystore in favor of ssl_keystore_path
keystore_password in favor of ssl_keystore_password
truststore in favor of ssl_truststore_path
truststore_password in favor of ssl_truststore_password
ssl_certificate_verification in favor of ssl_verification_mode

The behavior standardization across plugins, such as the accepted certificate formats, default values, etc will be tackled in future PRs.


Closes elastic/logstash#14924
Closes #404
Closes #672
Closes #676

@edmocosta edmocosta force-pushed the standardize_ssl_settings branch from 96eb956 to 03e6d71 Compare March 2, 2023 12:52
@edmocosta edmocosta changed the title [WIP] Standardize SSL settings Standardize SSL settings Mar 2, 2023
@edmocosta edmocosta changed the title Standardize SSL settings Standardize and add SSL settings Mar 2, 2023
@edmocosta edmocosta marked this pull request as ready for review March 2, 2023 14:14
@roaksoax roaksoax requested a review from andsel March 9, 2023 02:51
Copy link
Contributor

@andsel andsel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First review run.
Left some comments to evaluate.

[id="plugins-{type}s-{plugin}-keystore"]
===== `keystore`
deprecated[8.8.0, Replaced by <<plugins-{type}s-{plugin}-ssl_keystore_path>>]

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think should refer to the plugin's version (11.14.10). Given such big change, I would think to bump at 12.0.0.
This comment is valid for all the following deprecated[8.8.0, changes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I initially thought about it as well but given it is backward compatible I ended up increasing only the minor 11.14.0. Do you think we should bump at 12.0.0? Even if it does not break/change any existing behavior?

Copy link
Contributor

@yaauie yaauie Mar 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Backwards compatible changes do not require a major bump. This is additive, and all configurations that work under 11.13.x will continue to work without modification in 11.14.0.

ssl_options[:client_key] = ssl_key
elsif !!ssl_certificate || !!ssl_key
raise(LogStash::ConfigurationError, 'You must set both "ssl_certificate" and "ssl_key" for client authentication')
end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Message is a bit unclear (you don't actually have to set either, because you can use a keystore), and catches two distinct cases:

  • using ssl_certificate requires ssl_key AND
  • using ssl_key requires ssl_certificate

I prefer declaring it in a way that centers the single config that "activates" the feature, in this case ssl_certificate:

  • using ssl_certificate requires an ssl_key
  • an ssl_certificate is required when using an ssl_key

| <<plugins-{type}s-{plugin}-sniffing_path>> |<<string,string>>|No
| <<plugins-{type}s-{plugin}-ssl>> |<<boolean,boolean>>|No
| <<plugins-{type}s-{plugin}-ssl_certificate_verification>> |<<boolean,boolean>>|No
| <<plugins-{type}s-{plugin}-ssl>> |<<boolean,boolean>>|__Deprecated__
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer not to leave the deprecated settings in this table, and perhaps to have a separate section with them and their detailed blocks, so that we can reduce the noise new users of the plugin encounter while still ensuring that the deprecated options are still discoverable to those who are looking for documentation for options currently in their pipeline configs.

Copy link
Contributor

@andsel andsel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@edmocosta edmocosta merged commit cfe44f3 into logstash-plugins:main Mar 10, 2023
@edmocosta edmocosta deleted the standardize_ssl_settings branch March 10, 2023 16:51
@@ -1,3 +1,19 @@
## 11.14.0
- Added SSL settings for: [#1115](https://github.com/logstash-plugins/logstash-output-elasticsearch/pull/1115)
- `ssl_truststore_type`: The format of the truststore file
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this PR in the changelog correct? Shouldn't it be a link to this PR (#1118)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you're right, it should be #1118. I'll submit a fix! Thanks for the heads up!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @edmo. Remember that the link will be wrong for any release notes that include 11.14.0, and will require a manual fix. :-)

Elasticsearch documentation.

[id="plugins-{type}s-{plugin}-deprecated-options"]
==== Elasticsearch Output Deprecated Configuration Options
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deviation from the way we typically handle deprecations in plugins. (See https://www.elastic.co/guide/en/logstash/current/plugins-inputs-beats.html#plugins-inputs-beats-options.)

Standards can change over time, but the change needs to be deliberate and communicated clearly.

Copy link
Contributor

@karenzone karenzone Mar 21, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nevermind. I see where this came from: #1118 (comment).

This is definitely better for new users, but isn't very nice to our existing users who are scanning an alphabetical list or descriptions for a specific setting in their config.

@whyyouwannaknow
Copy link

Hello,

I might not post in the correct issue but we saw a deprecation on the setting ssl_certificate_verification which we replaced by ssl_verification_mode.
The thing is that this new setting ssl_verification_mode only supports the value full or none but not the value certificate.

This value certificate should be implemented in the output ElasticSearch of a Logstash pipeline as it is more secured then putting none instead.

Could this be implemented in a future update? Shoud we open a separated issue for this?

Thank you.

Regards,

@edmocosta
Copy link
Contributor Author

Hi @whyyouwannaknow!

Thank you for reaching out! Unfortunately, the underline HTTP library this plugin uses does not fully support the certificate mode, that's why it only accepts the full & none options. Please note that the previous configuration also didn't support it, being true => full and false => none.

We're working on standardising the SSL/TLS configs and features across plugins (elastic/logstash#14905), and that project's second phase also includes adding support to the certificate mode.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
6 participants