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

Stop relying on index template for session index #134900

Merged
merged 15 commits into from
Jun 30, 2022

Conversation

legrego
Copy link
Member

@legrego legrego commented Jun 22, 2022

Summary

Resolves #134897

This moves the index settings and mappings into the session index directly, rather than defining them on an index template. This also removes the index template if it already exists.

@legrego legrego added Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! release_note:skip Skip the PR/issue when compiling release notes backport:skip This commit does not require backporting Feature:Security/Session Management Platform Security - Session Management labels Jun 22, 2022
@legrego legrego marked this pull request as ready for review June 22, 2022 17:28
@legrego legrego requested a review from a team as a code owner June 22, 2022 17:28
@elasticmachine
Copy link
Contributor

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

@legrego legrego added the v8.4.0 label Jun 22, 2022
Copy link
Member Author

@legrego legrego left a comment

Choose a reason for hiding this comment

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

Author's notes for reviewers

/**
* Creates the session index if it doesn't already exist.
*/
private async ensureSessionIndexExists() {
Copy link
Member Author

Choose a reason for hiding this comment

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

note This was extracted from the initialize function above so that it can be reused in the create function.

@@ -213,17 +209,30 @@ export class SessionIndex {
'Attempted to create a new session while session index is initializing.'
);
await this.indexInitialization;
} else {
await this.ensureSessionIndexExists();
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 the extra round-trip that this incurs, but I don't see a way around it given the design of ES's APIs.

Copy link
Contributor

@kc13greiner kc13greiner left a comment

Choose a reason for hiding this comment

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

LGTM!

@legrego
Copy link
Member Author

legrego commented Jun 27, 2022

@azasypkin this is ready for the next round of reviews

Copy link
Member

@azasypkin azasypkin left a comment

Choose a reason for hiding this comment

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

Looks and works great! Thanks for adding tests to verify all aspects of a new functionality.

No need to change anything is this PR, just wondering if it'd make sense to (eventually) use index alias for the rest of the session operations as well (get, update, invalidate)?

'Attempted to create a new session, but session index or alias was missing.'
);
await this.ensureSessionIndexExists();
({ body, statusCode } = await this.writeNewSessionDocument(sessionValue, {
Copy link
Member

Choose a reason for hiding this comment

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

nit: statusCode isn't used here

Suggested change
({ body, statusCode } = await this.writeNewSessionDocument(sessionValue, {
({ body } = await this.writeNewSessionDocument(sessionValue, {

Copy link
Member

Choose a reason for hiding this comment

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

Looks like you unintentionally returned unused statusCode back 🙂

Copy link
Member Author

Choose a reason for hiding this comment

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

Looks like you unintentionally returned unused statusCode back 🙂

This is actually required to avoid an eslint error, because both body and statusCode are part of the same let block above. If I remove statusCode here, it complains that statusCode isn't a const above. I could either fix this by reintroducing the unused statusCode reference here, or break up the destructured assignment above into multiple lines. Reintroducing statusCode here felt less bad to me, but I don't feel strongly about this if you would prefer that I change it around.

Copy link
Member

Choose a reason for hiding this comment

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

This is actually required to avoid an eslint error, because both body and statusCode are part of the same let block above. If I remove statusCode here, it complains that statusCode isn't a const above.

Ahh, I see now, thanks for clarifying! Please, keep it as is then.

Comment on lines +521 to +524
// Prior to https://github.com/elastic/kibana/pull/134900, sessions would be written directly against the session index.
// Now, we write sessions against a new session index alias. This call ensures that the alias exists, and is attached to the index.
// This operation is safe to repeat, even if the alias already exists. This seems safer than retrieving the index details, and inspecting
// it to see if the alias already exists.
Copy link
Member

Choose a reason for hiding this comment

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

note: thank you for adding comment! I agree using putAlias feels safer.

@legrego
Copy link
Member Author

legrego commented Jun 28, 2022

@azasypkin,

No need to change anything is this PR, just wondering if it'd make sense to (eventually) use index alias for the rest of the session operations as well (get, update, invalidate)?

I was wondering the same thing. If we were writing this from scratch today, would we opt to do this? If so, then I'm happy to attempt these changes as part of this PR. If it turns out to be a lot of work, then I can open a followup issue for one of us to tackle in the future.

I can't think of a good reason not to do this, other than "unknown unknowns".

@azasypkin
Copy link
Member

If we were writing this from scratch today, would we opt to do this?

I'd say yes.

If so, then I'm happy to attempt these changes as part of this PR. If it turns out to be a lot of work, then I can open a followup issue for one of us to tackle in the future.

Sounds good to me, thank you!

@legrego legrego requested a review from azasypkin June 28, 2022 14:05
ignore404: true,
});

if (statusCode === 404) {
Copy link
Member

Choose a reason for hiding this comment

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

question: do we handle 404 for updates just to account for a case when the alias is missing, but the index exists? I mean if index doesn't exist then the session we're trying to update doesn't exist either...

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes my intention here was to handle the case where we have an index without an alias

Copy link
Member

Choose a reason for hiding this comment

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

Got it, thanks. We usually retrieve session (via alias now) before we update it, but there is still a possibility for the race condition and handling 404 in update wouldn't hurt anyway 👍

Copy link
Member

@azasypkin azasypkin 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! Would it make sense to also use alias in the cleanUp and getSessionValuesInBatches methods?

'Attempted to create a new session, but session index or alias was missing.'
);
await this.ensureSessionIndexExists();
({ body, statusCode } = await this.writeNewSessionDocument(sessionValue, {
Copy link
Member

Choose a reason for hiding this comment

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

Looks like you unintentionally returned unused statusCode back 🙂

ignore404: true,
});

if (statusCode === 404) {
Copy link
Member

Choose a reason for hiding this comment

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

Got it, thanks. We usually retrieve session (via alias now) before we update it, but there is still a possibility for the race condition and handling 404 in update wouldn't hurt anyway 👍

@legrego
Copy link
Member Author

legrego commented Jun 29, 2022

Looks great! Would it make sense to also use alias in the cleanUp and getSessionValuesInBatches methods?

AHHH How did I miss those? 😢

@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

✅ unchanged

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

Copy link
Member

@azasypkin azasypkin left a comment

Choose a reason for hiding this comment

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

:shipit:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting Feature:Security/Session Management Platform Security - Session Management release_note:skip Skip the PR/issue when compiling release notes Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! v8.4.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Do not rely on index template for Kibana's user session index
5 participants