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

Security: Remove SecurityLifecycleService #30526

Merged
merged 1 commit into from
May 15, 2018

Conversation

rjernst
Copy link
Member

@rjernst rjernst commented May 11, 2018

This commit removes the SecurityLifecycleService, relegating its former
functions of listening for cluster state updates to SecurityIndexManager
and IndexAuditTrail.

This commit removes the SecurityLifecycleService, relegating its former
functions of listening for cluster state updates to SecurityIndexManager
and IndexAuditTrail.
@rjernst rjernst added v7.0.0 >refactoring :Security/Security Security issues without another label v6.4.0 labels May 11, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security


}

public State state() {
return state.get();
}

@Override
public void clusterChanged(ClusterChangedEvent event) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Earlier in the SecurityLifeCycleService the cluster changed event was handled in order - first, to handle the event in SecurityIndexManager later it would start the index audit trail. Is there any order defined which does not change the behavior of handling cluster event? Not sure if this would be of any concern.

Copy link
Member Author

Choose a reason for hiding this comment

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

The order should not matter. The services have no interdependencies.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks @rjernst

@Override
public void clusterChanged(ClusterChangedEvent event) {
try {
if (state() == IndexAuditTrail.State.INITIALIZED && canStart(event)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

We have removed the condition Security.indexAuditLoggingEnabled(settings), is the check performed somewhere else or not required anymore?

Copy link
Member Author

Choose a reason for hiding this comment

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

The IndexAuditTrail object is only created if that method returns true, so it is not necessary to check within the instance.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks, @rjernst.

@bizybot
Copy link
Contributor

bizybot commented May 14, 2018

Hi @rjernst, Could you please add some background info that would help understand the problem that this PR solves? I could not locate any issue/defect to understand more on the problem statement. Thank you.

@rjernst
Copy link
Member Author

rjernst commented May 14, 2018

Could you please add some background info that would help understand the problem that this PR solves?

This PR is moving towards being able to wait during node startup on additional plugin provided services to be "ready". This will enable, for example, removing the waitCondition xpack tests have in gradle, because we will know when the ports file written by node startup is written that xpack is ready to service requests (eg security index is ready). These wait conditions will happen in a followup PR; this PR is only a precursor in separating out the existing services so that each one can have code to say "wait on this being ready".

@jaymode jaymode self-requested a review May 14, 2018 17:59
Copy link
Member

@jaymode jaymode left a comment

Choose a reason for hiding this comment

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

I left a couple minor comments, otherwise LGTM

@@ -261,6 +263,8 @@
private final SetOnce<ThreadContext> threadContext = new SetOnce<>();
private final SetOnce<TokenService> tokenService = new SetOnce<>();
private final SetOnce<SecurityActionFilter> securityActionFilter = new SetOnce<>();
private final SetOnce<SecurityIndexManager> securityIndex = new SetOnce<>();
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 a nit and was there before this change, but maybe we should call this securityIndexManager everywhere instead of securityIndex

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 actually like securityIndex, since the methods all reflect the state of the index, not the manager itself.

@@ -261,6 +263,8 @@
private final SetOnce<ThreadContext> threadContext = new SetOnce<>();
private final SetOnce<TokenService> tokenService = new SetOnce<>();
private final SetOnce<SecurityActionFilter> securityActionFilter = new SetOnce<>();
private final SetOnce<SecurityIndexManager> securityIndex = new SetOnce<>();
private final SetOnce<IndexAuditTrail> indexAuditTrail = new SetOnce<>();
Copy link
Member

Choose a reason for hiding this comment

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

also why are we using a setonce for these? It looks like we only use them in the createComponents method currently?

Copy link
Member Author

Choose a reason for hiding this comment

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

These will be used in a followup, to wait on their readiness in onNodeStarted()

Copy link
Contributor

@bizybot bizybot left a comment

Choose a reason for hiding this comment

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

LGTM

@rjernst rjernst merged commit 21b9170 into elastic:master May 15, 2018
@rjernst rjernst deleted the node_started3 branch May 15, 2018 19:13
@rjernst
Copy link
Member Author

rjernst commented May 15, 2018

Thanks @bizybot and @jaymode

rjernst added a commit that referenced this pull request May 16, 2018
This commit removes the SecurityLifecycleService, relegating its former
functions of listening for cluster state updates to SecurityIndexManager
and IndexAuditTrail.
martijnvg added a commit that referenced this pull request May 17, 2018
* es/6.x: (44 commits)
  SQL: Remove dependency for server's version from JDBC driver (#30631)
  Make xpack modules instead of a meta plugin (#30589)
  Security: Remove SecurityLifecycleService (#30526)
  Build: Add task interdependencies for ssl configuration (#30633)
  Mute ShrinkIndexIT
  [ML] DeleteExpiredDataAction should use client with origin (#30646)
  Reindex: Fixed typo in assertion failure message (#30619)
  [DOCS] Fixes list of unconverted snippets in build.gradle
  Use readFully() to read bytes from CipherInputStream (#30640)
  Add Create Repository High Level REST API (#30501)
  [DOCS] Reorganizes RBAC documentation
  Test: increase search logging for LicensingTests
  Delay _uid field data deprecation warning (#30651)
  Deprecate Empty Templates (#30194)
  Remove unused DirectoryUtils class. (#30582)
  Mitigate date histogram slowdowns with non-fixed timezones. (#30534)
  [TEST] Remove AwaitsFix in IndicesOptionsTests#testSerialization
  S3 repo plugin populates SettingsFilter (#30652)
  Rest High Level client: Add List Tasks (#29546)
  Fixes IndiceOptionsTests to serialise correctly (#30644)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants