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

Enroll Kibana API uses Service Accounts #76370

Merged
merged 16 commits into from
Aug 17, 2021

Conversation

jkakavas
Copy link
Member

@jkakavas jkakavas commented Aug 11, 2021

This commit changes the Enroll Kibana API to create and return
a token for this service account, instead of setting and returning the
password of the kibana_system built-in user.

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.

It also changes the Enroll Kibana API to create and return a token
for this service account, instead of setting and returning the
password of the kibana_system built-in user.
@jkakavas jkakavas added >enhancement :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) v7.15.0 labels Aug 11, 2021
@elasticmachine elasticmachine added the Team:Security Meta label for security team label Aug 11, 2021
@elasticmachine
Copy link
Collaborator

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

@@ -18,21 +18,21 @@

public final class KibanaEnrollmentResponse {

private SecureString password;
private SecureString token;
Copy link
Member Author

Choose a reason for hiding this comment

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

@azasypkin would Kibana want to know the token name in addition to the value ? ( https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-create-service-token.html )

Copy link
Member

Choose a reason for hiding this comment

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

A explicit token name might be convenient for kibana, but the token value itself also has the token name embedded. The token value takes the format of \0\1\0\1elastic/kibana-system/$tokenName:$tokenSecret and is base64 encoded.

Copy link
Member

Choose a reason for hiding this comment

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

@azasypkin would Kibana want to know the token name in addition to the value ? ( https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-create-service-token.html )

Yeah, I think it'd be better to have one (to log it least).

Choose a reason for hiding this comment

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

From what I can gather we only need the service account token to authenticate so don't think we need the name at all.

Copy link
Member

Choose a reason for hiding this comment

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

Right, we don't need it in the code, but I thought it'd be beneficial to log it anyway, to know which Kibana triggered generation of which token, for troubleshooting purposes.

Choose a reason for hiding this comment

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

To be honest, for consistency, it might make sense to mirror the create service token API anyways:

{
  "token": {
    "name": "token1",
    "value": "AAEAAWVsYXN0aWM...vZmxlZXQtc2VydmVyL3Rva2VuMTo3TFdaSDZ" 
  }
}

Learn once, use anywhere, etc.

Copy link
Member Author

Choose a reason for hiding this comment

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

coo, I'll make the change to return the name too, thanks for weighing in folks

@lockewritesdocs
Copy link
Contributor

@jkakavas, I updated the service accounts usage section in 0180b16 to include the elastic/kibana-system service account.

@jkakavas
Copy link
Member Author

I split the introduction of the kibana-system service account to #76449 so that we can backport that to 7.15 and I will adjust this PR to simply add the relevant changes to the enrollment API. Sorry for the confusion, I think it will be clearer this way.

@jkakavas jkakavas requested review from ywangd and removed request for albertzaharovits and BigPandaToo August 12, 2021 18:12
@jkakavas jkakavas removed the v7.15.0 label Aug 13, 2021
@jkakavas jkakavas added this to Implementation Milestone 4 (August 13th) in Security On by Default Implementation Tracking Aug 13, 2021
Copy link
Contributor

@BigPandaToo BigPandaToo left a comment

Choose a reason for hiding this comment

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

I added a couple of comments regarding tests, otherwise looks good.

@@ -2875,7 +2875,7 @@ public void onFailure(Exception e) {
}
}

@AwaitsFix(bugUrl = "Determine behavior for keystores with multiple keys")
@AwaitsFix(bugUrl = "https://github.com/elastic/elasticsearch/issues/75097")
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it really blocked by this issue? I think it shouldn't be unless we use truststore containing multiple CA certs

Copy link
Member Author

Choose a reason for hiding this comment

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

True, we should have re-enabled this test as part of #73807. Will take care of it on Monday

Copy link
Contributor

Choose a reason for hiding this comment

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

Actually, testEnrollNode and testEnrollKibana here are already doing what we need, I believe

Copy link
Member Author

Choose a reason for hiding this comment

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

No, not really. EnrollIT means to test the HLRC behavior where the *DocumentationIT means to test that our documentation snippets are accurate and work

@@ -2918,7 +2918,7 @@ public void onFailure(Exception e) {
}
}

@AwaitsFix(bugUrl = "Determine behavior for keystores with multiple keys")
@AwaitsFix(bugUrl = "https://github.com/elastic/elasticsearch/issues/75097")
Copy link
Contributor

Choose a reason for hiding this comment

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

Same as above ^^

Copy link
Member

@ywangd ywangd left a comment

Choose a reason for hiding this comment

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

LGTM

@azasypkin
Copy link
Member

Looks good to me, @thomheymann since you have a WIP PR where we interact with the Enrollment API already can you please check if this change works well for you as well?

@thomheymann
Copy link

Looks good to me, @thomheymann since you have a WIP PR where we interact with the Enrollment API already can you please check if this change works well for you as well?

Thanks for ping. Yeh, happy to get this breaking change in before release. Shouldn't be too much work to adapt the existing PR. Very exciting!

- nits
- removed unecessary parsing from KibanaEnrollmentResponse
- added token name in the response
- update docs
@jkakavas
Copy link
Member Author

jkakavas commented Aug 16, 2021

@ywangd thanks for the comments 🙏 , I think I addressed all the feedback 👍
@thomheymann I added the token name and updated the response as suggested, thanks, please take another look !
@lockewritesdocs can you please do a quick round of the doc changes ?
@BigPandaToo do you want to have another round too ?


import static org.hamcrest.Matchers.equalTo;

public class KibanaEnrollmentResponseTests extends ESTestCase {
Copy link
Member Author

Choose a reason for hiding this comment

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

github fails to show this clearly but this was renamed from KibanaErnollmentResponseTests to fix the typo, hence the new file

Copy link
Contributor

@BigPandaToo BigPandaToo left a comment

Choose a reason for hiding this comment

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

LGTM

@lockewritesdocs
Copy link
Contributor

@lockewritesdocs can you please do a quick round of the doc changes ?

@jkakavas -- done in 4dce318 👍

Copy link
Contributor

@lockewritesdocs lockewritesdocs left a comment

Choose a reason for hiding this comment

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

👍 with the changes in 4dce318

@jkakavas
Copy link
Member Author

jkakavas commented Aug 16, 2021 via email

@jkakavas
Copy link
Member Author

@elasticmachine update branch

@jkakavas
Copy link
Member Author

@elasticmachine test this please

Copy link

@thomheymann thomheymann left a comment

Choose a reason for hiding this comment

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

Looks great, thanks!

@jkakavas jkakavas merged commit a596848 into elastic:master Aug 17, 2021
Security On by Default Implementation Tracking automation moved this from Implementation Milestone 4 (August 13th) to Completed Aug 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>enhancement :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) Team:Security Meta label for security team v8.0.0-alpha2
Development

Successfully merging this pull request may close these issues.

None yet

9 participants