-
Notifications
You must be signed in to change notification settings - Fork 24.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove HTTPS check for API Keys & Service Accounts #76801
Conversation
This commit removes the checks that prevented the use of API Keys and Service Account (Service Tokens) on nodes without HTTPS (xpack.security.http.ssl.enabled) As a consequence of removing this check, the API Key service is not automatically enabled, but can be explicitly disabled with xpack.security.authc.api_key.enabled: false
@elastic/es-security I've marked this as a draft while we discuss exactly what behaviour we want here. Questions:
|
I'm in favor of doing that. Users that have to stay on 7.x will be able to fully leverage Kibana Alerting and other similar features even if their environment requires HTTPS off, for example service mesh setups.
In 8.x I'm in favor of turning on by default, since security is also on by default. |
I agree we should and I think that previous team discussions also came to the same conclusion
I think that for 8.x, since we are deciding to decouple API Key Service from HTTPS configuration, it wouldn't make sense to turn off API Key service if HTTPS is disabled. In 7.x though, this has the potential of being a "breaking change" for some of our users. If an administrator willingly wants API Key service to be disabled and now depends on it being disabled because TLS for HTTP is not enabled, will have API Key service enabled (unknowingly) on upgrade to 7.16. I can't think of a use case where this becomes breaking in itself, but consider the case where we ( or an application that uses elasticsearch ) has a bug where API keys can be created and leaked and can be used for data exfiltration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also need to update
docs/reference/settings/security-settings.asciidoc#L174
x-pack/docs/en/security/authentication/service-accounts.asciidoc#L61
x-pack/plugin/core/src/main/java/org/elasticsearch/xpack/core/XPackSettings.java
Show resolved
Hide resolved
I second on @jkakavas's comment. Also a few more docs to update:
|
My counter point would be that if we follow this line of reasoning, then the first time something like API Key Service is introduced it should be disabled by default because we didn't get administrators to opt-in to it. I appreciate the analogy to file realm though, so I'm happy to not change the default in 7.16, but I'm cautious about setting too much of a precedent here - we shouldn't be afraid to add features in a minor. |
True, I see your point. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I appreciate the analogy to file realm though, so I'm happy to not change the default in 7.16
Do you plan to change the default when backporting? If so, all relevant docs/javadocs need to be changed as well. Do we also want to give users heads up in 7.16 docs about the default will be changed again in 8.0?
Just a thought crossed my mind: Should API keys be always enabled in 8.0? That is, they cannot be disabled similar to service accounts? It's often used as an alternative to avoid directly serialising user credentials. It is also long lived. So it is potentially useful to any long running tasks. I am not suggesting to make the change for this PR. But I think it is worth discussing before finalising 8.0. |
Yes, the backport will require a few tweaks. Does anyone specifically want to review that PR before it merges?
I'm not sure - writing docs that talk about the future is risky. Probably we can get away with "A future release will ... "
I think we probably want to work towards them always being enabled. I don't know whether we want to do that in 8.0, or just deprecating the setting and remove it in a future release. We should discuss. |
@elasticmachine update branch |
I did some telemetry analysis and the number of clusters with API keys "explicitly" disabled (HTTPS on, API keys off) is irrelevant. However, since removing the configuration setting is a breaking change, I suggest to deprecate it in 8.0 and remove later. |
This commit removes the checks that prevented the use of API Keys and Service Account (Service Tokens) on nodes without HTTPS (xpack.security.http.ssl.enabled) The API Key service is only enabled by default if HTTPS is also enabled however it can be explicitly enabled (regardless of HTTPS) with xpack.security.authc.api_key.enabled: false Backport of: elastic#76801
Since elastic#76801, the API Key feature is enabled by default and no longer ties to HTTPS setting. This PR fixes the test to reflect the new default. Resolves: elastic#78162
This commit removes the checks that prevented the use of API Keys and Service Account (Service Tokens) on nodes without HTTPS (xpack.security.http.ssl.enabled) The API Key service is only enabled by default if HTTPS is also enabled however it can be explicitly enabled (regardless of HTTPS) with xpack.security.authc.api_key.enabled: false Backport of: #76801
This doc was missed in elastic#76801 (ea0dc45)
Is this applicable for |
It does not apply to The Elasticsearch token service tries (where possible) to conform to OAuth2 specs, which require https. |
This commit removes the checks that prevented the use of API Keys and
Service Account (Service Tokens) on nodes without HTTPS
(xpack.security.http.ssl.enabled)
As a consequence of removing this check, the API Key service is now
automatically enabled, but can be explicitly disabled with