You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This document describes the features and functionalities being built to support extensions securely through the security plugin. Links to GitHub issues where either meta issues or decisions docs will be included throughout.
Background
OpenSearch is building extensions to support existing plugin functionality with a goal to eventually replace them. The first iteration of extensions are built to run out of process, creating a trust boundary that did not exist before. This boundary provides a golden opportunity to require and enforce security in all extensions. The security team will focus on building up existing security features, providing parity for missing features, and establishing baseline security requirements.
Previously, OpenSearch had an Identity project that was built from the ground up to provide a set of features for identity and security systems. However, the team decided to pivot to reduce the amount of customer migrations and provide features that customers can use more quickly.
Our approach to securely supporting extensions and OpenSearch is to keep extension-related information in the extensions manager. Then, there will be a series of connections to the security plugin where the security plugin will contain implementations and enforcement of existing patterns. Extension will received opaque tokens for authentication with the OpenSearch cluster, Extensions are responsible to handle cases where the requests are successful or unsuccessful.
OpenSearch Core
Management of extensions will include the current information, as well as features to ensure trusted connections between the OpenSearch cluster and the extensions endpoint. Extensions registration and configuration will include application scopes that limit the kinds of access to OpenSearch in a broad fashion.
OpenSearch does not have a current identity by exposing context through an identity plugin, OpenSearch will be able to provide structured authentication information.
OpenSearch has a plugin called Job Scheduler. This plugin would store a list of tasks to be executed on intervals or in the future time. These tasks did not contain information on who was executing them. Job Scheduler needs to be enhanced to store this information securely.
When requests are forwarded through the OpenSearch cluster to the extension, several security features will be added to support current scenarios and to enable new functionality.
Authorization was previously provided through inspection of transport layer actions. These actions are not available to extensions. The security plugin will extend how authorization is performed so that extensions' actions exposed as REST API are permissioned in the same way as like plugins are treated today.
Impersonation - In the current plugin model, the plugin operates as the identity of the user making that request, controlled by the thread context. Outside of the OpenSearch process, when extensions need to execute requests on behalf of the user, a just-in-time token will be provided that an extension can use to interact with the OpenSearch cluster.
Extensions need a mechanism to issue requests outside of the context of an incoming user request. Service accounts will be used to allow extensions to make requests into the OpenSearch cluster.
Plugins have access to thread context information that is used to determine additional security features for their resources. A backward compatibility mechanism will be created to pass this data to extensions.
Plugins have the ability to access OpenSearch system indices to store their state information while being sure that plugin index data could not be altered. Extensions will need new permissions to allow access to these system indices.
Security Plugin for Extensions Project
This document describes the features and functionalities being built to support extensions securely through the security plugin. Links to GitHub issues where either meta issues or decisions docs will be included throughout.
Background
OpenSearch is building extensions to support existing plugin functionality with a goal to eventually replace them. The first iteration of extensions are built to run out of process, creating a trust boundary that did not exist before. This boundary provides a golden opportunity to require and enforce security in all extensions. The security team will focus on building up existing security features, providing parity for missing features, and establishing baseline security requirements.
Previously, OpenSearch had an Identity project that was built from the ground up to provide a set of features for identity and security systems. However, the team decided to pivot to reduce the amount of customer migrations and provide features that customers can use more quickly.
Approach
Our approach to securely supporting extensions and OpenSearch is to keep extension-related information in the extensions manager. Then, there will be a series of connections to the security plugin where the security plugin will contain implementations and enforcement of existing patterns. Extension will received opaque tokens for authentication with the OpenSearch cluster, Extensions are responsible to handle cases where the requests are successful or unsuccessful.
OpenSearch Core
Management of extensions will include the current information, as well as features to ensure trusted connections between the OpenSearch cluster and the extensions endpoint. Extensions registration and configuration will include application scopes that limit the kinds of access to OpenSearch in a broad fashion.
Note: this area is still ‘gelling’ this document should only have a single meta issue with the specific breakdown.
OpenSearch does not have a current identity by exposing context through an identity plugin, OpenSearch will be able to provide structured authentication information.
OpenSearch has a plugin called Job Scheduler. This plugin would store a list of tasks to be executed on intervals or in the future time. These tasks did not contain information on who was executing them. Job Scheduler needs to be enhanced to store this information securely.
Security Plugin
When requests are forwarded through the OpenSearch cluster to the extension, several security features will be added to support current scenarios and to enable new functionality.
Authorization was previously provided through inspection of transport layer actions. These actions are not available to extensions. The security plugin will extend how authorization is performed so that extensions' actions exposed as REST API are permissioned in the same way as like plugins are treated today.
Impersonation - In the current plugin model, the plugin operates as the identity of the user making that request, controlled by the thread context. Outside of the OpenSearch process, when extensions need to execute requests on behalf of the user, a just-in-time token will be provided that an extension can use to interact with the OpenSearch cluster.
Extensions Security Features
Extensions need a mechanism to issue requests outside of the context of an incoming user request. Service accounts will be used to allow extensions to make requests into the OpenSearch cluster.
Plugins have access to thread context information that is used to determine additional security features for their resources. A backward compatibility mechanism will be created to pass this data to extensions.
Plugins have the ability to access OpenSearch system indices to store their state information while being sure that plugin index data could not be altered. Extensions will need new permissions to allow access to these system indices.
Questions
Space for questions related to this high level topic
Diagrams
Central space for all design diagrams introduced as part of this initiative.
The text was updated successfully, but these errors were encountered: