[Feature Request] Create a mechanism to track if the current execution is within a block where the ThreadContext has been stashed

[cwperks]

Is your feature request related to a problem? Please describe

Related RFC in the security plugin: opensearch-project/security#4439

I would like to have a mechanism to track which plugin most recently stashed the ThreadContext. Stashing the threadContext is done in the plugin ecosystem in order to allow a plugin to interact with its system indices when the security plugin is installed.

Stashing the threadContext is analogous to running a command as sudo. A plugin that stashes its threadContext is effectively switching contexts, that is instead of running in an authenticated user context its running in an elevated context.

By being able to keep track of where the ThreadContext was most recently stashed, it would be possible to provide richer authorization mechanisms within the block where the threadContext was stashed.

Better authorization includes:

1. Enforcing plugins only interact with their own system indices
2. Allowing a cluster administrator to explicitly define what actions a plugin can do in a block where the plugin has switched out of the authenticated user context

Describe the solution you'd like

Have some sort of lookup to query if the current execution is within a block where the threadContext is stashed and identify the plugin that stashed the context.

Related component

Plugins

Describe alternatives you've considered

Keep the existing implementation

Additional context

Related RFC in the security plugin: opensearch-project/security#4439

[reta]

Thanks for the feature @cwperks

I would like to have a mechanism to track which plugin most recently stashed the ThreadContext. Stashing the threadContext is done in the plugin ecosystem in order to allow a plugin to interact with its system indices when the security plugin is installed.

I believe thread context stashing is used in many, many different places and is not really related to plugin, but probably more generic to "caller", it is used heavily by SecurityManager APIs and relies on jdk.internal.reflect.Reflection:

Class <?> caller = Reflection.getCallerClass();

But to the point, I believe the thread context is not the place where any authorization decisions could be made, but the SecurityManager is (sadly, we have to find the replacement for it).

-. enforcing plugins only interact with their own system indices

It could be done using the AccessController + Permission model (we know system indices <-> plugin mapping)

2. allowing a cluster administrator to explicitly define what actions a plugin can do in a block where the plugin has switched out of the authenticated user context

This statement is unclear to me, the "authenticated user" concept is (at least for now) strictly specific to security plugin and should not leak into core anyhow. Could you please elaborate what exactly you mean by "define what actions a plugin can do in a block where the plugin has switched out of the authenticated"? Where this block come from? What is cluster administrator? How it is supposed to explicitly define actions ?

[cwperks]

This statement is unclear to me, the "authenticated user" concept is (at least for now) strictly specific to security plugin and should not leak into core anyhow. Could you please elaborate what exactly you mean by "define what actions a plugin can do in a block where the plugin has switched out of the authenticated"? Where this block come from? What is cluster administrator? How it is supposed to explicitly define actions ?

The best analogy is that stashing the threadContext is equivalent to running a command as sudo from the existing security plugin perspective.

Effectively, a plugin has switched contexts and is allowed to perform any action on the cluster as sudo.

define what actions a plugin can do in a block where the plugin has switched out of the authenticated user context

This is forward looking outside of the stronger system index authz that I have been working on. Essentially, instead of running as sudo within the stashed context block it would be su -u <plugin>, but what permissions does it have? At first it would only be interaction with a system index, but we could create a mechanism for a cluster admin to define what the plugin can perform similar to a role definition. I believe that a cluster administrator should be empowered to declare what actions a plugin can perform and not by default give all plugins sudo privileges.

---

For these 2 PRs:

• Add runAs to Subject interface and introduce IdentityAwarePlugin extension point #14630
• Strengthen system index protection in the plugin ecosystem security#4570

It will provide an off-ramp for plugins to remove usages of stashContext in favor of switchContext which is essentially identical, but it populates the threadcontext with plugin info so the security plugin can authz transport actions accordingly.

[reta]

The best analogy is that stashing the threadContext is equivalent to running a command as sudo from the existing security plugin perspective.

I think the sudo analogy is not right (for ThreadContext) and it is not serving the same purpose: it is specifically manages thread local context and only that (the fact security plugin may store the user / principal in thread context as well is implementation detail). The sudo analogy would be Subject::doAs where the identity is managed explicitly.

I believe that a cluster administrator should be empowered to declare what actions a plugin can perform and not by default give all plugins sudo privileges.

I still don't understand this, sorry, what kind of actions? We do have plugin security policy in place, plus permissions that security plugin manages. I think you have larger picture in mind but for some reasons reference to low level thread context hides it (it is just a means but not the solution).

[cwperks]

I still don't understand this, sorry, what kind of actions?

Transport actions.

[reta]

Transport actions.

This is where we have permissions, right?

[cwperks]

This is where we have permissions, right?

For users yes, but not when plugins stash the threadcontext.

When a plugin stashes the threadcontext, any action initiated in the block is implicitly trusted. In the security plugin, there is a bypass for this scenario so that a plugin can perform elevated actions such as writing to a system index.

[cwperks]

Consider this pseudo code for creating an anomaly detector. Creating an anomaly detector indexes a document into the .opendistro-anomaly-detector-jobs index.

1. User makes REST call to create detector PUT /_plugins/ad/detector
2. Security plugin authenticates the request
3. After authentication, AD plugin's corresponding RestHandler's handleRequest is called
4. RestAction typically uses the node client to switch to transport layer (client.execute(Action.NAME, request, actionListener))

The steps below occur in the transport action to create a detector

5. AD stashes the threadcontext <- This is done to perform escalated (sudo) actions
    5.1. Index a document into .opendistro-anomaly-detector-jobs index with job metadata <- This is indented to indicate this is in a block where the threadcontext is stashed.

6. Respond to client success/fail

[reta]

For users yes, but not when plugins stash the threadcontext.

So it seems like the plugin have to be explicitly allowed to do that, if allowed at all, right? With that, it fits perfectly into the security policy model we have at the moment. Reject context stashing by default, allow when explicitly granted.

[cwperks]

There could certainly be a permission entry in the plugin-security.policy file that governs whether a plugin can stash the threadcontext but why should stashing the threadcontext give a plugin the ability to perform any transport action?

[reta]

There could certainly be a permission entry in the plugin-security.policy file that governs whether a plugin can stash the threadcontext but why should stashing the threadcontext give a plugin the ability to perform any transport action?

I think transport actions and thread context are quite unrelated. To me, the proper implementation of the latter model would be to introduce identity to plugins and extensions, so we could apply the same permission model (that security plugin implements) uniformly.