How to delivery security for Extensions

[peternied]

This document aims to propose several approaches for delivering the security requirements for the extension's release, along with their respective trade-offs.

Background

• We are building the next iteration of plugins (Technical roadmap: OpenSearch extensibility, see blog) and they need to provide at least the same security as plugins
• In plugins, security is optional, but with extensions we would like to remove the optionality

In the plugin model, security is also a plugin. This means security can be optional, which makes it difficult for plugins to build features such as field- and document-level security (FLS/DLS), which perform data access securely. Each plugin must implement data access checks independently and correctly, which has proven to be difficult (see #1895 for some examples). A simpler and more secure implementation would make all operations inside OpenSearch permissible, no matter the source, syncing access checks to the lower levels. The SDKs move extensibility concerns out of the monoliths. They will have brand-new APIs, presenting the most opportune time to require a security context in all OpenSearch API calls. It should, of course, still be possible to disable security as needed.

Goals

• Satisfy the Requirements from Extensions BRD
• Secure Extensions the same way (or better) than Plugins today

Option 0: Do nothing

This is not an option, extensions must have a way to check access and securely interact with the cluster.

Option 1: Use the security plugin [Recommended]

This approach aims to unblock development of Extensions and provide a path to delivery with minimal amount of changes.

We will 1) implement the Identity interface from core (OpenSearch’s repository) in security plugin, 2) pass a token to an extension that can be used to interact with the OpenSearch cluster, 3) build authorization for extensions, and 4) provide a secure context for background jobs.

Pros:

• Fastest path to delivery
• No migration required for existing customers
• Reuse of shipped features and testing frameworks
• Reuse of existing features such as audit logging

Cons:

• Cannot support in-process extensions [2], at which point will become throw-away work
• Adds technical debt on the path of always enabling security (moving security to core)
• Increases the amount of future user permission migrations required

Option 2: Build security features in core

This approach will provide the fastest path towards the desired end state security model, while limiting the number of migrations required.

We will 1) build a security module in core with authentication, 2) build a new authorization module, 3) build a new permissions model, 4) reimplement audit logging, 5) implement a new internal identity provider, 6) pass a token to an extension that can be used to interact with the OpenSearch cluster, 7) build authorization on the REST layer based on roles declared by an extension, and 8) provide a secure context for background jobs, 9) migrate plugins to the new security mode, 10) ensure backwards compatibility with existing security plugin features.

Pros:

• Fewer user permission migrations
• Consistent security model
• Prevent plugins from elevating their own permissions
• Accelerate deprecation of the security plugin
• Security team engineers become maintainers of OpenSearch core

Cons:

• Increased timeline and unknowns
• Increased risk in a large codebase and a new team
• Fewer incremental features

Option 3: GA In-Proc Extensions Only

~~This approach focuses on minimal changes to convert an existing plugin to an extension, removing the remote connection trivialize many changes. This isn't bold enough, it iterates with existing architectural problems unsolvable. Extensions team is building out of proc first and then will move towards in-process extensions. ~~

Appendix

Known problems with the current security plugin

1. Plugins can modify the thread context, impacting security (risk of privilege escalation and permission modification)
2. There is no way to specify subsets of things that plugins can do as an application (read, write, talk to other plugins...)
3. Secure inter-plugin communication patterns are not supported
4. Security plugin lacks (has limited) support for application security rules. Mostly focused around data access security
5. Removing plugins from the thread (running them out of process) requires new ways of establishing trust with them (Extensions)

FAQ

1. What about supporting security for in-process extensions?
Extensions in-process still have access to shared resources such as memory/jvm/disk allowing circumvention of these boundaries. Sandboxing extensions to create an isolation boundary is needed. The existing solution Java Security Manager (JSM) is end-of-life and will be removed in future versions of java making it non-viable.

The Security Plugin is not viable for in-process extensions as during node startup all plugin including the Security Plugin are started at the same time - preventing identity context to be provided for system / plugin thread identity.

2. What about the contributions to the features/identity branch of OpenSearch?
While there has been a large number of features developed in that branch, those features has been built as an all up prototype. Many aspects of the software development process have been set aside to focus on collaboration and deep experimentation. While by one measure there is a near implementation of an IdentityPlugin following additional design rigor, consistency in implementation, and alignment with product requirements would still need to take place.

3. What level of security are we providing?
With extensions we have an opportunity to enforce security protections such as when background tasks are dispatched they run under an identity. These will need to be looked into on a feature by feature basis with product weighting in on the different aspects and tradeoffs.

4. Will extensions work without security?
Extensions will not function without a security implementation. Many features such as authentication via tokens will fundamentally inoperable without supporting implementation.

[peternied]

FYI @opensearch-project/security - I know this was selected a little while ago in private channels, wanted to bubble it out in case folks are curious about the pivot

We are moving forward with Option 1: Use the security plugin [Recommended], which is captured in this project board

• https://github.com/orgs/opensearch-project/projects/102