-
Notifications
You must be signed in to change notification settings - Fork 24.3k
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
Enroll Kibana API uses Service Accounts #76370
Conversation
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.
Pinging @elastic/es-security (Team:Security) |
@@ -18,21 +18,21 @@ | |||
|
|||
public final class KibanaEnrollmentResponse { | |||
|
|||
private SecureString password; | |||
private SecureString token; |
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.
@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 )
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.
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.
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.
@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).
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.
From what I can gather we only need the service account token to authenticate so don't think we need the name at all.
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.
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.
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.
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.
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.
coo, I'll make the change to return the name too, thanks for weighing in folks
...rc/test/java/org/elasticsearch/xpack/security/authc/service/ElasticServiceAccountsTests.java
Outdated
Show resolved
Hide resolved
@jkakavas, I updated the service accounts usage section in 0180b16 to include the |
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. |
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.
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") |
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.
Is it really blocked by this issue? I think it shouldn't be unless we use truststore containing multiple CA certs
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.
True, we should have re-enabled this test as part of #73807. Will take care of it on Monday
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.
Actually, testEnrollNode
and testEnrollKibana
here are already doing what we need, I believe
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.
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") |
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.
Same as above ^^
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
...est-high-level/src/main/java/org/elasticsearch/client/security/KibanaEnrollmentResponse.java
Outdated
Show resolved
Hide resolved
...igh-level/src/test/java/org/elasticsearch/client/security/KibanaErnollmentResponseTests.java
Outdated
Show resolved
Hide resolved
...igh-level/src/test/java/org/elasticsearch/client/security/KibanaErnollmentResponseTests.java
Outdated
Show resolved
Hide resolved
...igh-level/src/test/java/org/elasticsearch/client/security/KibanaErnollmentResponseTests.java
Outdated
Show resolved
Hide resolved
...java/org/elasticsearch/xpack/security/action/enrollment/TransportKibanaEnrollmentAction.java
Outdated
Show resolved
Hide resolved
...java/org/elasticsearch/xpack/security/action/enrollment/TransportKibanaEnrollmentAction.java
Outdated
Show resolved
Hide resolved
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
@ywangd thanks for the comments 🙏 , I think I addressed all the feedback 👍 |
|
||
import static org.hamcrest.Matchers.equalTo; | ||
|
||
public class KibanaEnrollmentResponseTests extends ESTestCase { |
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.
github fails to show this clearly but this was renamed from KibanaErnollmentResponseTests
to fix the typo, hence the new file
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.
👍 with the changes in 4dce318
Adam, it’s actually the value of the token (so <2> ) that is used to
Authenticate as the service account. <1> is just the name of the token
(returned for informational purposes). Can you please add a suggestion
based on that ?
…On Monday, August 16, 2021, Adam Locke ***@***.***> wrote:
***@***.**** approved this pull request.
👍 with the changes in 4dce318
<4dce318>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#76370 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACOOCKF2ZW53IQACFXWD7UDT5F2GRANCNFSM5B642DIQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
@elasticmachine update branch |
@elasticmachine test this please |
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.
Looks great, thanks!
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.