Skip to content
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

Deprecate the kibana reserved user; introduce kibana_system user #54967

Merged
merged 16 commits into from
Apr 27, 2020

Conversation

legrego
Copy link
Member

@legrego legrego commented Apr 8, 2020

Deprecates the reserved kibana user in favor of a new kibana_system user with an identical set of privileges.

This uses the same _deprecated and _deprecated_reason metadata attributes that we use to denote deprecated roles. Similarly, this logs a deprecation warning when a deprecated user successfully authenticates to Elasticsearch.

Partially addresses elastic/kibana#25879

Companion PRs:
elastic/stack-docs#991
elastic/kibana#63186

@legrego legrego force-pushed the security/deprecate-kibana-user branch from b974c0c to 601b05c Compare April 8, 2020 18:15
@gwbrown gwbrown added the :Security/Security Security issues without another label label Apr 8, 2020
@elasticmachine
Copy link
Collaborator

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

@legrego legrego force-pushed the security/deprecate-kibana-user branch from 601b05c to 6813965 Compare April 8, 2020 20:36
@legrego legrego force-pushed the security/deprecate-kibana-user branch 2 times, most recently from 6e9c434 to ef8452a Compare April 9, 2020 14:17
@legrego legrego force-pushed the security/deprecate-kibana-user branch from ef8452a to 7bc702d Compare April 9, 2020 17:34
@legrego
Copy link
Member Author

legrego commented Apr 10, 2020

@elasticmachine merge upstream

@jkakavas jkakavas requested a review from a team April 10, 2020 13:55
@legrego
Copy link
Member Author

legrego commented Apr 10, 2020

I can't figure out why the SetupPasswordToolTests are failing. If anyone has an idea, I'd love to hear it. I can reproduce the failure locally, and removing my change from the SetupPasswordTool causes the tests to pass again, but I don't know what the actual problem is

@@ -125,10 +126,22 @@ public void testAuthenticationDisabledUserWithStoredPassword() throws Throwable
verifySuccessfulAuthentication(false);
}

public void testLogDeprecatedUser() throws Exception {
Copy link
Member Author

Choose a reason for hiding this comment

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

I don't love this test because it's fixed on the single deprecated kibana user, and won't work once we actually remove this user. I'm open to suggestions on how to rewrite this more generically, because it wasn't immediately obvious to me.

I could make the logDeprercatedUser method public so that it's testable on its own, but that didn't seem like the right solution either.

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 this is fine, but I would go with:

--- a/x-pack/plugin/security/src/test/java/org/elasticsearch/xpack/security/authc/esnative/ReservedRealmTests.java
+++ b/x-pack/plugin/security/src/test/java/org/elasticsearch/xpack/security/authc/esnative/ReservedRealmTests.java
@@ -126,16 +126,13 @@ public class ReservedRealmTests extends ESTestCase {
         verifySuccessfulAuthentication(false);
     }

-    public void testLogDeprecatedUser() throws Exception {
-        final User expected = new KibanaUser(true);
-        this.verifySuccessfulAuthenticationForUser(expected, true);
-        assertWarnings("The user [kibana] is deprecated and will be removed in a future version of Elasticsearch. " +
-            "Please use the [kibana_system] user instead.");
-    }
-
     private void verifySuccessfulAuthentication(boolean enabled) throws Exception {
         final User expectedUser = randomReservedUser(enabled);
         this.verifySuccessfulAuthenticationForUser(expectedUser, enabled);
+        if (new KibanaUser(enabled).equals(expectedUser)) {
+            assertWarnings("The user [kibana] is deprecated and will be removed in a future version of Elasticsearch. " +
+                    "Please use the [kibana_system] user instead.");
+        }
     }

     private void verifySuccessfulAuthenticationForUser(User expectedUser, boolean enabled) throws Exception {

@legrego legrego marked this pull request as ready for review April 10, 2020 20:21
Copy link
Contributor

@albertzaharovits albertzaharovits left a comment

Choose a reason for hiding this comment

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

Overall this looks OK.
But the setup password tool needs more thought. I suggest we prompt only once and set the input password for both users.

Also, docs need to be updated. Here's the list of files that refer to the kibana built-in user, and should instead refer to kibana_system:

  • x-pack/docs/en/security/authentication/built-in-users.asciidoc
  • x-pack/docs/en/security/auditing/output-logfile.asciidoc
  • x-pack/docs/en/security/get-started-kibana-users.asciidoc
  • x-pack/docs/en/security/get-started-builtin-users.asciidoc
  • x-pack/docs/en/security/auditing/output-logfile.asciidoc
  • x-pack/docs/en/security/securing-communications/tutorial-tls-internode.asciidoc

Assuming we plan to remove the kibana user in 8, we should drop a line about it in docs/reference/migration/migrate_8_0/security.asciidoc

public static final List<String> USERS = asList(ElasticUser.NAME, APMSystemUser.NAME, KibanaUser.NAME, LogstashSystemUser.NAME,
BeatsSystemUser.NAME, RemoteMonitoringUser.NAME);
public static final List<String> USERS = asList(ElasticUser.NAME, APMSystemUser.NAME, KibanaUser.NAME, KibanaSystemUser.NAME,
LogstashSystemUser.NAME, BeatsSystemUser.NAME, RemoteMonitoringUser.NAME);

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 it's cumbersome on the user to have password prompts for both kibana and kibana_system.

I suggest we display the prompt for the new kibana_system user and also set the same password for the kibana user.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point, I agree this is cumbersome. I'll take a stab at updating the SetupPasswordTool to support this

@@ -125,10 +126,22 @@ public void testAuthenticationDisabledUserWithStoredPassword() throws Throwable
verifySuccessfulAuthentication(false);
}

public void testLogDeprecatedUser() throws Exception {
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 this is fine, but I would go with:

--- a/x-pack/plugin/security/src/test/java/org/elasticsearch/xpack/security/authc/esnative/ReservedRealmTests.java
+++ b/x-pack/plugin/security/src/test/java/org/elasticsearch/xpack/security/authc/esnative/ReservedRealmTests.java
@@ -126,16 +126,13 @@ public class ReservedRealmTests extends ESTestCase {
         verifySuccessfulAuthentication(false);
     }

-    public void testLogDeprecatedUser() throws Exception {
-        final User expected = new KibanaUser(true);
-        this.verifySuccessfulAuthenticationForUser(expected, true);
-        assertWarnings("The user [kibana] is deprecated and will be removed in a future version of Elasticsearch. " +
-            "Please use the [kibana_system] user instead.");
-    }
-
     private void verifySuccessfulAuthentication(boolean enabled) throws Exception {
         final User expectedUser = randomReservedUser(enabled);
         this.verifySuccessfulAuthenticationForUser(expectedUser, enabled);
+        if (new KibanaUser(enabled).equals(expectedUser)) {
+            assertWarnings("The user [kibana] is deprecated and will be removed in a future version of Elasticsearch. " +
+                    "Please use the [kibana_system] user instead.");
+        }
     }

     private void verifySuccessfulAuthenticationForUser(User expectedUser, boolean enabled) throws Exception {

@albertzaharovits albertzaharovits added :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) >deprecation and removed :Security/Security Security issues without another label labels Apr 15, 2020
@legrego
Copy link
Member Author

legrego commented Apr 23, 2020

@elasticmachine merge upstream

@legrego
Copy link
Member Author

legrego commented Apr 23, 2020

@albertzaharovits thanks for the review. I took a shot at your suggestion to automatically set the kibana user password based on what's generated for the kibana_system user. I'm running into an integration test failure because of the new deprecation warning I'm logging. I'm not sure of the best way to update the test. Do you have any suggestions?

https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+pull-request-2/22719/testReport/junit/org.elasticsearch.xpack.security.authc.esnative.tool/SetupPasswordToolIT/testSetupPasswordToolAutoSetup/

@albertzaharovits
Copy link
Contributor

@elasticmachine update branch

@albertzaharovits
Copy link
Contributor

@legrego

I'm running into an integration test failure because of the new deprecation warning I'm logging. I'm not sure of the best way to update the test. Do you have any suggestions?

This should do it.

diff --git a/x-pack/plugin/security/src/test/java/org/elasticsearch/integration/ClearRealmsCacheTests.java b/x-pack/plugin/security/src/test/java/org/elasticsearch/integration/ClearRealmsCacheTests.java
index 557fd5813bf..99df031c6df 100644
--- a/x-pack/plugin/security/src/test/java/org/elasticsearch/integration/ClearRealmsCacheTests.java
+++ b/x-pack/plugin/security/src/test/java/org/elasticsearch/integration/ClearRealmsCacheTests.java
@@ -11,6 +11,7 @@ import org.elasticsearch.action.support.PlainActionFuture;
 import org.elasticsearch.client.Request;
 import org.elasticsearch.client.RequestOptions;
 import org.elasticsearch.client.Response;
+import org.elasticsearch.client.WarningsHandler;
 import org.elasticsearch.common.Strings;
 import org.elasticsearch.common.settings.SecureString;
 import org.elasticsearch.test.SecurityIntegTestCase;
diff --git a/x-pack/qa/security-setup-password-tests/src/test/java/org/elasticsearch/xpack/security/authc/esnative/tool/SetupPasswordToolIT.java b/x-pack/qa/security-setup-password-tests/src/test/java/org/elasticsearch/xpack/security/authc/esnative/tool/SetupPasswordToolIT.java
index 48070300f0a..a5c1a9391cc 100644
--- a/x-pack/qa/security-setup-password-tests/src/test/java/org/elasticsearch/xpack/security/authc/esnative/tool/SetupPasswordToolIT.java
+++ b/x-pack/qa/security-setup-password-tests/src/test/java/org/elasticsearch/xpack/security/authc/esnative/tool/SetupPasswordToolIT.java
@@ -9,6 +9,7 @@ import org.elasticsearch.cli.MockTerminal;
 import org.elasticsearch.client.Request;
 import org.elasticsearch.client.RequestOptions;
 import org.elasticsearch.client.Response;
+import org.elasticsearch.client.WarningsHandler;
 import org.elasticsearch.common.Strings;
 import org.elasticsearch.common.SuppressForbidden;
 import org.elasticsearch.common.io.PathUtils;
@@ -106,6 +107,10 @@ public class SetupPasswordToolIT extends ESRestTestCase {
                 Request request = new Request("GET", "/_security/_authenticate");
                 RequestOptions.Builder options = request.getOptions().toBuilder();
                 options.addHeader("Authorization", basicHeader);
+                if ("kibana".equals(entry.getKey())) {
+                    // the kibana user is deprecated so a warning header is expected
+                    options.setWarningsHandler(WarningsHandler.PERMISSIVE);
+                }
                 request.setOptions(options);
                 Map<String, Object> userInfoMap = entityAsMap(client().performRequest(request));
                 assertEquals(entry.getKey(), userInfoMap.get("username"));

The warning you get is an an _authenticate call used for verification that the tested tool did its job, i.e. the warning is not visible on a normal run of the command, it's present just in the test.


Users who were previously assigned the `kibana_user` role should instead be assigned
the `kibana_admin` role. This role grants the same set of privileges as `kibana_user`, but has been
renamed to better reflect its intended use.
Copy link
Contributor

Choose a reason for hiding this comment

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

This notice looks dope 👍

@legrego
Copy link
Member Author

legrego commented Apr 27, 2020

@albertzaharovits Thanks for the suggested edit for the integration test. I was initially considering something like that, but it felt a bit fragile, so I wasn't sure if there was a pattern used elsewhere that I wasn't aware of. I'll fix this test shortly and get a new version up here for re-review 👍

Copy link
Contributor

@albertzaharovits albertzaharovits left a comment

Choose a reason for hiding this comment

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

LGTM Thank you Larry!

We'll have to backport this to 7.x where the migration notice is in a different file, then follow-up with a master only PR that completely removes the kibana user.
You can fling this drudgery my way if you wish.

@legrego
Copy link
Member Author

legrego commented Apr 27, 2020

We'll have to backport this to 7.x where the migration notice is in a different file, then follow-up with a master only PR that completely removes the kibana user.

I don't mind taking this on, I'll bug you if I run into any issues :)
I won't merge the master-only PR until we have all the Kibana changes in place, that way we can continue to use updated snapshots as they become available

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>deprecation :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) v7.8.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants