Skip to content

Conversation

slobodanadamovic
Copy link
Contributor

@slobodanadamovic slobodanadamovic commented Jan 24, 2025

Today, Elasticsearch supports two models to establish secure connections
and trust between two Elasticsearch clusters:

This PR deprecates the Certificate based security model in favour of API key based security model.
The API key based security model is preferred way to configure remote clusters,
as it allows to follow security best practices when setting up remote cluster connections
and defining fine-grained access control.

Users are encouraged to migrate remote clusters from certificate to API key authentication.


Deprecation details:

The deprecation warning message is logged only at runtime, when a remote connection is first opened. This is in order to avoid overloading the deprecation logs. The logs are deduplicated by passing a key per remote cluster alias (remote_cluster_certificate_access-<remote-cluster-alias>). Worth noting is that with this approach, the warning headers will not be returned to clients that execute a cross cluster search requests (e.g. POST /my_remote_cluster:*/_search). I think this is justifiable, given that end-clients are not the ones interested in such deprecations, but rather administrators of the cluster.

The deprecation message will only be logged on local cluster. This is because there is no way to detect if an inbound connection on a remote cluster is originating from a cluster using certificate based auth. As a consequence, this means that there may be some old local clusters connecting to a new remote clusters using deprecated model, and there would be no deprecations logged at all.

There are no particular settings to be deprecated, because the certificate based model shares the same transport protocol/settings as the intra-cluster node-to-node communication. Hence, we might log a deprecation message for remote connections that are simply missing credentials (cluster.remote.ALIAS.credentials). Edit: This is addressed by checking if the remote connection is using REMOTE_CLUSTER_PROFILE. The remote cluster profile is used only for the new port and transport connections that use new API key based security model.

Note: If the approach makes sense, I will add more test coverage and update the docs.

@slobodanadamovic slobodanadamovic added >deprecation :Security/Security Security issues without another label Team:Security Meta label for security team v9.0.0 labels Jan 24, 2025
@slobodanadamovic slobodanadamovic self-assigned this Jan 24, 2025
@elasticsearchmachine
Copy link
Collaborator

Hi @slobodanadamovic, I've created a changelog YAML for you. Note that since this PR is labelled >deprecation, you need to update the changelog YAML to fill out the extended information sections.

@slobodanadamovic slobodanadamovic requested review from a team and bytebilly January 24, 2025 21:04
@slobodanadamovic slobodanadamovic marked this pull request as ready for review January 27, 2025 22:02
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-security (Team:Security)

@slobodanadamovic slobodanadamovic added the test-full-bwc Trigger full BWC version matrix tests label Jan 28, 2025
Copy link
Contributor

@bytebilly bytebilly left a comment

Choose a reason for hiding this comment

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

The approach LGTM 👍
for the code changes, I'll defer to engineers :)

@n1v0lg n1v0lg self-requested a review January 28, 2025 16:10
@slobodanadamovic
Copy link
Contributor Author

Copy link
Contributor

@n1v0lg n1v0lg left a comment

Choose a reason for hiding this comment

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

Thanks for working on this! Briefly discussed on Slack: we also need to cover proxy connections and add a test for it. Few other nit comments, I'll take a quick look again once the changes are in.

The <<remote-clusters-api-key,*API key based security model*>> is preferred way to configure remote clusters,
as it allows to follow security best practices when setting up remote cluster connections
and defining fine-grained access control.
Users are encouraged to <<remote-clusters-migrate, migrate remote clusters from certificate to API key authentication>>.
Copy link
Contributor

Choose a reason for hiding this comment

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

Wonder if we want to make this a stronger statement by adding something like "since support for the certificate-based model will be removed in a future version."

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've adjusted the changelog to state that it will be removed in future. Let me know if that makes sense: 71fd150

[[remote-clusters-cert]]
=== Add remote clusters using TLS certificate authentication

deprecated::[9.0.0,"Certificate based authentication is deprecated. Configure <<remote-clusters-api-key,API key authentication>> instead or follow a guide on how to <<remote-clusters-migrate,migrate remote clusters from certificate to API key authentication>>."]
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think we should tackle it in this PR, but cross cluster replication docs make a bunch of implicit references to the certificate-based model, e.g.,:

https://www.elastic.co/guide/en/elasticsearch/reference/current/_configure_privileges_for_cross_cluster_replication_2.html

We probably want a follow up of some sorts to update the docs to focus on RCS 2.0 instead, and mention that RCS 1.0 is deprecated.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For sure. There is a plan to do that with the help of docs team.

@slobodanadamovic
Copy link
Contributor Author

slobodanadamovic commented Jan 29, 2025

Thanks for working on this! Briefly discussed on Slack: we also need to cover proxy connections and add a test for it. Few other nit comments, I'll take a quick look again once the changes are in.

Thanks for catching this! 👍 Please have another look. I've added deprecation logging when a node is connected using proxy mode. Also wrote an integration test which covers both proxy and sniff modes.

Copy link
Contributor

@n1v0lg n1v0lg left a comment

Choose a reason for hiding this comment

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

LGTM! Neat integ test 💯

/**
* Tests the deprecation of RCS1.0 (certificate-based) security model.
*/
public class RemoteClusterSecurityRCS1DeprecationIT extends AbstractRemoteClusterSecurityTestCase {
Copy link
Contributor

Choose a reason for hiding this comment

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

very neat!

@slobodanadamovic slobodanadamovic added the auto-merge-without-approval Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) label Jan 29, 2025
@slobodanadamovic slobodanadamovic removed the auto-merge-without-approval Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) label Jan 29, 2025
@slobodanadamovic slobodanadamovic merged commit c5ab17c into elastic:main Jan 29, 2025
22 checks passed
@slobodanadamovic slobodanadamovic deleted the sa-deprecate-certificate-based-rcs-model branch January 29, 2025 20:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

>deprecation :Security/Security Security issues without another label Team:Security Meta label for security team test-full-bwc Trigger full BWC version matrix tests v9.0.0

4 participants