Add kibana-system service account #76449

jkakavas · 2021-08-12T18:09:58Z

This change introduces a Service Account for Kibana to use when
authenticating to Elasticsearch. The Service Account with
kibana-system service name under the elastic namespace,
uses the same RoleDescriptor as the existing kibana_system
built-in user and is its functional equivalent when it comes to
AuthZ.

deprecates: #73738

This change introduces a Service Account for Kibana to use when authenticating to Elasticsearch. The Service Account with kibana-system service name under the elastic namespace, uses the same RoleDescriptor as the existing kibana_system built-in user and is its functional equivalent when it comes to AuthZ.

elasticmachine · 2021-08-12T18:10:02Z

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

ywangd

LGTM

There is also a JavaRest test class for service accounts in case you haven't looked at it. Because most of its tests are more for testing the service account infrastructure, you may find it not necessary to touch it anyway. One thing that could have some minor value is asserting the role descriptor return from the get-service-account call (testGetServiceAccount) because it is not tested in yaml tests. We can choose to not add a literal string of the role descriptor, but instead rely on RoleDescriptor.toXContent to reduce maintanence cost.

ywangd · 2021-08-13T00:41:53Z

...core/src/main/java/org/elasticsearch/xpack/core/security/authz/store/ReservedRolesStore.java

+            },
+            null,
+            new ConfigurableClusterPrivilege[] { new ManageApplicationPrivileges(Collections.singleton("kibana-*")) },
+            null, MetadataUtils.DEFAULT_RESERVED_METADATA, null);


Reserved metadata is not really needed for service account role descriptor. But it should not cause any issue either.

ywangd · 2021-08-13T01:03:22Z

...core/src/main/java/org/elasticsearch/xpack/core/security/authz/store/ReservedRolesStore.java

@@ -434,6 +363,81 @@ private static RoleDescriptor kibanaAdminUser(String name, Map<String, Object> m
            null, null, metadata, null);
    }

+    public static RoleDescriptor kibanaSystemUserRole(String name) {


nit:

Suggested change

public static RoleDescriptor kibanaSystemUserRole(String name) {

public static RoleDescriptor kibanaSystemRoleDescriptor(String name) {

ywangd · 2021-08-13T01:30:13Z

...rc/test/java/org/elasticsearch/xpack/security/authc/service/ElasticServiceAccountsTests.java

@@ -46,6 +145,280 @@

 public class ElasticServiceAccountsTests extends ESTestCase {

+    public void testKibanaSystemPrivileges() {


This works, but might not be necessary and also add to ongoing maintanence since the same is tested in ReservedRoleStoreTests. I'd prefer to just assert the service account role descriptor is equivalent to the one used for the reserved role. Something like:

var serviceRoleDescriptor = ElasticServiceAccounts.ACCOUNTS.get("elastic/kibana-system").roleDescriptor(); var reservedRoleDescriptor = ReservedRoleStore.roleDescriptor(KibanaSystemUser.ROLE_NAME); assertThat(serviceRoleDescriptor.getClusterPrivileges(), equalTo(reservedRoleDescriptor.getClusterPrivileges())); ...

One caveat of the above is that the method ReservedRoleStore.roleDescriptor(...) is currently not static. But I think it should be OK to change it to static or alternatively we can use new ReservedRolesStore().roleDescriptor(...) similar to how it is done in ReservedRoleStoreTests.

Agreed, I was also not particularly fond of this, your idea makes sense, thanks!

bytebilly · 2021-08-13T08:35:22Z

...ity/src/main/java/org/elasticsearch/xpack/security/authc/service/ElasticServiceAccounts.java

@@ -43,8 +44,10 @@
            null,
            null
        ));
+    private static final ServiceAccount KIBANA_SYSTEM_ACCOUNT =
+        new ElasticServiceAccount("kibana-system", ReservedRolesStore.kibanaSystemUserRole(NAMESPACE + "/kibana-system"));


Sorry if it was already discussed elsewhere, but I'm wondering if the name of the service account should be kibana instead of kibana-system. Given this is a service account, I don't think there may be confusion with a kibana user, and the name sounds clearer to me and more consistent with fleet-server.

What do you think?

I don't have an opinion tbh, happy bothways. I'll leave this up to you and Kibana folks to decide

I was initially wondering why not kibana_system (with the underscore) to be consistent with the existing built-in user (I guess Fleet doesn't have any "system" built-in users yet, so it's not a problem for them). At the same time, I see the name format for service accounts is <namespace>/<service> where service already implies it's not a user, and elastic namespace would imply that this service is a reserved/"system" one. With this, elastic/kibana sounds good to me.

@jportner @kobelb any concerns regarding elastic/kibana service account name?

The elastic/fleet-server account was initially named elastic/fleet. It got renamed because the Fleet team wanted to differentiate between the Fleet Server and other fleet services, e.g. there could be another elastic/fleet service account that is used to setup Fleet in Kibana. Do we foresee other service accounts needed for Kibana? If not, elastic/kibana might be a better choice.

@jportner @kobelb any concerns regarding elastic/kibana service account name?

Fine by me

Do we foresee other service accounts needed for Kibana? If not, elastic/kibana might be a better choice.

Looking through the open issues, I don't think there is a desire to make additional service accounts for Kibana. But Perhaps @kobelb knows something I don't, so let's see what he says.

@jportner @kobelb any concerns regarding elastic/kibana service account name?

Fine by me.

The elastic/fleet-server account was initially named elastic/fleet. It got renamed because the Fleet team wanted to differentiate between the Fleet Server and other fleet services, e.g. there could be another elastic/fleet service account that is used to setup Fleet in Kibana

This makes sense to me because Fleet as a product is partially implemented in Kibana and Fleet Server. However, at the moment, we don't have the same complexity with Kibana, Kibana is just Kibana at the moment.

Looking through the open issues, I don't think there is a desire to make additional service accounts for Kibana. But Perhaps @kobelb knows something I don't, so let's see what he says.

TL;DR: I'm not aware of any concrete plans to introduce additional service accounts.

There have been some super preliminary discussions about how we could in the future allow Kibana to run certain setup steps with different privileges than during normal runtime. For example, when Kibana is first starting up, it needs privileges to provision and migrate data in its own system indices; however, these privileges are no longer required after Kibana has started up. If Kibana could drop privileges after performing setup, it could allow Kibana to run normal operations with fewer privileges, mitigating some attack vectors. However, we'd almost certainly want to find a way for end-users to only have to configure a single reserved user or service account in the kibana.yml, or else we'd make configuring Kibana harder.

azasypkin

Tested locally with Kibana, worked as expected, thanks! Just want to get an additional input for the service account name before we merge: https://github.com/elastic/elasticsearch/pull/76449/files#r688364607

jkakavas · 2021-08-13T11:11:20Z

It seems like there is agreement to call the account elastic/kibana so I went ahead and made the change already. I will refrain from merging until @jportner @kobelb have time to comment

elasticsearchmachine · 2021-08-13T14:02:03Z

💔 Backport failed

Status	Branch	Result
❌	7.x	Commit could not be cherrypicked due to conflicts

To backport manually run backport --upstream elastic/elasticsearch --pr 76449

This change introduces a Service Account for Kibana to use when authenticating to Elasticsearch. The Service Account with kibana service name under the elastic namespace, uses the same RoleDescriptor as the existing kibana_system built-in user and is its functional equivalent when it comes to AuthZ. # Conflicts: # rest-api-spec/build.gradle # x-pack/plugin/build.gradle # x-pack/plugin/security/src/test/java/org/elasticsearch/xpack/security/authc/service/ElasticServiceAccountsTests.java # x-pack/plugin/security/src/test/java/org/elasticsearch/xpack/security/authc/service/ServiceAccountServiceTests.java

This change introduces a Service Account for Kibana to use when authenticating to Elasticsearch. The Service Account with kibana service name under the elastic namespace, uses the same RoleDescriptor as the existing kibana_system built-in user and is its functional equivalent when it comes to AuthZ.

jkakavas added >enhancement :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) v8.0.0 v7.15.0 labels Aug 12, 2021

jkakavas requested review from azasypkin and ywangd August 12, 2021 18:09

elasticmachine added the Team:Security Meta label for security team label Aug 12, 2021

jkakavas mentioned this pull request Aug 12, 2021

Enroll Kibana API uses Service Accounts #76370

Merged

ywangd approved these changes Aug 13, 2021

View reviewed changes

bytebilly reviewed Aug 13, 2021

View reviewed changes

azasypkin approved these changes Aug 13, 2021

View reviewed changes

jkakavas added 2 commits August 13, 2021 13:20

Address feedback

7859a4b

Temporarily disable restCompatTest until backport

5c7bc7b

jkakavas added 2 commits August 13, 2021 14:38

properly mute test for rest compat

d0da801

Bring test class from existing PR

7865177

kobelb approved these changes Aug 13, 2021

View reviewed changes

jkakavas added the auto-backport Automatically create backport pull requests when merged label Aug 13, 2021

jkakavas merged commit 59d75f2 into elastic:master Aug 13, 2021

jkakavas mentioned this pull request Aug 13, 2021

[7.x] Add kibana-system service account (#76449) #76502

Merged

graphaelli mentioned this pull request Aug 26, 2021

Kibana 8.0.0 not starting elastic/apm-integration-testing#1232

Closed

jakelandis added v8.0.0-alpha2 and removed v8.0.0 labels Sep 15, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add kibana-system service account #76449

Add kibana-system service account #76449

jkakavas commented Aug 12, 2021 •

edited

Loading

elasticmachine commented Aug 12, 2021

ywangd left a comment

ywangd Aug 13, 2021

ywangd Aug 13, 2021

ywangd Aug 13, 2021

jkakavas Aug 13, 2021

bytebilly Aug 13, 2021

jkakavas Aug 13, 2021

azasypkin Aug 13, 2021 •

edited

Loading

ywangd Aug 13, 2021

jportner Aug 13, 2021

kobelb Aug 13, 2021

azasypkin left a comment

jkakavas commented Aug 13, 2021

elasticsearchmachine commented Aug 13, 2021

	public static RoleDescriptor kibanaSystemUserRole(String name) {
	public static RoleDescriptor kibanaSystemRoleDescriptor(String name) {

		@@ -46,6 +145,280 @@

		public class ElasticServiceAccountsTests extends ESTestCase {

		public void testKibanaSystemPrivileges() {

Add kibana-system service account #76449

Add kibana-system service account #76449

Conversation

jkakavas commented Aug 12, 2021 • edited Loading

elasticmachine commented Aug 12, 2021

ywangd left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

azasypkin Aug 13, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

azasypkin left a comment

Choose a reason for hiding this comment

jkakavas commented Aug 13, 2021

elasticsearchmachine commented Aug 13, 2021

💔 Backport failed

jkakavas commented Aug 12, 2021 •

edited

Loading

azasypkin Aug 13, 2021 •

edited

Loading