Move the plugin configuration to stateless #6201
Comments
Desvelao
changed the title
AnalysisSave the configuration in a saved objectPros:
Cons:
Use the configuration of the platform (opensearch_dashboards.yml)Pros:
Cons:
Comparison
|
|
We had a meeting today and we decided to research the possibility of creating a similar initiation process for the security of the Wazuh indexer to set the plugins settings. This approach could resolve some of the problems of the analyzed solutions. A script that initiates the status from the configuration from a file ( |
Research the initiation of security in Wazuh indexerThe The script executes Java code:
Regarding the intention to save sensitive data, if we retrieve the data for an internal user doesn't display the hashed password: The According to this documentation, the I got the document that contains the data related to the internal users and this seems to be encoded: {
"_index": ".opendistro_security",
"_id": "internalusers",
"_score": 1.0,
"_source": {
"internalusers": "eyJfbWV0YSI6eyJ0eXBlIjoiaW50ZXJuYWx1c2VycyIsImNvbmZpZ192ZXJzaW9uIjoyfSwiYWRtaW4iOnsiaGFzaCI6IiQyYSQxMiRWY0NEZ2gyTkRrMDdKR04wcmpHYk0uQWQ0MXFWUi9ZRkpjZ0hwMFVHbnM1SkR5bXYuLlRPRyIsInJlc2VydmVkIjp0cnVlLCJiYWNrZW5kX3JvbGVzIjpbImFkbWluIl0sImRlc2NyaXB0aW9uIjoiRGVtbyBhZG1pbiB1c2VyIn0sImtpYmFuYXNlcnZlciI6eyJoYXNoIjoiJDJhJDEyJDRBY2dBdDN4d09XYWRBNXM1YmxMNmV2MzlPWEROaG1PZXNFb28zM2VadHJxMk4wWXJVM0guIiwicmVzZXJ2ZWQiOnRydWUsImRlc2NyaXB0aW9uIjoiRGVtbyBraWJhbmFzZXJ2ZXIgdXNlciJ9LCJraWJhbmFybyI6eyJoYXNoIjoiJDJhJDEyJEpKU1hOZlRvd3o3VXU1dHRYZmVZcGVZRTBhckFDdmN3bFBCU3RCMUYuTUk3ZjBVOVo0REdDIiwicmVzZXJ2ZWQiOmZhbHNlLCJiYWNrZW5kX3JvbGVzIjpbImtpYmFuYXVzZXIiLCJyZWFkYWxsIl0sImF0dHJpYnV0ZXMiOnsiYXR0cmlidXRlMSI6InZhbHVlMSIsImF0dHJpYnV0ZTIiOiJ2YWx1ZTIiLCJhdHRyaWJ1dGUzIjoidmFsdWUzIn0sImRlc2NyaXB0aW9uIjoiRGVtbyBraWJhbmFybyB1c2VyIn0sImxvZ3N0YXNoIjp7Imhhc2giOiIkMmEkMTIkdTFTaFI0bDR1QlMzVXY1OVBhMnk1LjF1UXVaQnJadG1OZnFCM2lNLy5qTDBYb1Y5c2doUzIiLCJyZXNlcnZlZCI6ZmFsc2UsImJhY2tlbmRfcm9sZXMiOlsibG9nc3Rhc2giXSwiZGVzY3JpcHRpb24iOiJEZW1vIGxvZ3N0YXNoIHVzZXIifSwicmVhZGFsbCI6eyJoYXNoIjoiJDJhJDEyJGFlNHljd3p3dkx0Wnh3WjgyUm1pRXVuQmJJUGlBbUdaZHVCQWpLTjBUWGR3UUZ0Q3dBUnoyIiwicmVzZXJ2ZWQiOmZhbHNlLCJiYWNrZW5kX3JvbGVzIjpbInJlYWRhbGwiXSwiZGVzY3JpcHRpb24iOiJEZW1vIHJlYWRhbGwgdXNlciJ9LCJzbmFwc2hvdHJlc3RvcmUiOnsiaGFzaCI6IiQyeSQxMiREcHdtZXRIS3dnWW5vcmJnZHZPUkNlbnY0TkFLOGNQVWc4QUk2cHhMQ3VXZi9BTGMwLnY3VyIsInJlc2VydmVkIjpmYWxzZSwiYmFja2VuZF9yb2xlcyI6WyJzbmFwc2hvdHJlc3RvcmUiXSwiZGVzY3JpcHRpb24iOiJEZW1vIHNuYXBzaG90cmVzdG9yZSB1c2VyIn19"
}
}The value seems to be encoded using JWT. If we decode it, we can see the hashed password of the internal users: The user password of the internal user is hashed. The creation of these hashes, using a script that runs under the hoods this code: https://github.com/opensearch-project/security/blob/2.11.0.0/src/main/java/org/opensearch/security/tools/Hasher.java#L84-L92 I could not find it where the data is JWT encoded or how the |
Store the configurationThe intention is to store the plugin configuration in a saved object instead of the current configuration file ( DesignWe will create an interface to communicate with the configuration in the server and frontend side that will use the current plugin setting schema (extending as necessary). Backend:
Frontend:
These new services will be created in the core plugin and exposed to the rest of the plugins that could register their own settings. Each plugin should register the settings on the backend and frontend side. Interfaces:
Backend sideEach plugin should register the setting on the The configuration will be stored on a saved object:
The ID of the instance can be defined through:
The sensitive data as the This supports deploying multiple instances of the Wazuh dashboard that share or use independent configuration. If using the shared configuration, take into account that if the jobs of monitoring or statistics are enabled in multiple machines with the same API hosts entries, the daya could be duplicated on the Wazuh indexer. The cache system is based on time to live ( Frontend sideThe configuration will be saved in memory. Migrate the wazuh.yml configuration fileThe previous versions of the Wazuh dashboard could use the mechanism to initialize the Wazuh dashboard plugins settings with its customizations. Manage the API hostA new mechanism has to be created to manage the API host entries ( create, delete, update ) from the UI. ImplementationThe API host entries can be managed through the Server APIs application. New endpoints:
The addition, update, or deletion of API host entries must be done through these endpoints. |
Manage the API host entriesI was exploring the idea to manage the API host entries from the App Settings configuration, but, it seems overcomplicated due to the layout and manage the password values. I reverted this to move to the Server APIs application where the server API are listed and added the ability to create, update or remove the API host entries. As the ability to manage the API host from the UI is new, we need to specify the requirements for a user can execute these actions. This affects the UI buttons and the backend side that manages the API host entries. |
Encrypt the sensitive data of configuration in the saved objectDescriptionThe API host data is saved in the saved object of the plugin's configuration. This saved object can be retrieved from any user with permission about the index where this is located. As the API host data will save some sensitive data, we could need to implement a mechanism to encrypt/decrypt the data in the saved object. In the previous configuration system in the I recently added the ability to the ConfigurationStore service on the backend side to map/unmap the password values for the API host entries. We need to decide on the encryption method, but one of the possibilities could be the user can configure the method or options to this data is encrypted. We need to decide how these options are defined taking into account we want to the plugins be stateless (no required files to work). Moreover, we need to take into account the process when the options to encrypt the data change, a migration process (automatic or manual by the user) should be done to keep the previous data. The options to encrypt the data could be done through the definition in the Wazuh dashboard configuration file. ImplementationCreate a The secret can be defined in a new plugin setting defined in the platform configuration file (
Example: wazuh_core.configuration.encryption_key: customEncryptionKey⚠ Changing the key will cause the data not to be decrypted in environments that are configured previously. The encryption only applies to the API host data stored in the saved object. |
Manage the API host entriesThe API host entries can be managed through the The
Moreover, a button to add or remove an API host entry was added to the API hosts table.
The
|
Administrator userThe plugin's configuration management is restricted to privileged users. The administrator users of the plugins is based in the access to the rest API of OpenSearch, this can be configured through the Example: # opensearch.yml
plugins.security.restapi.roles_enabled: ["all_access", "wazuh_admin"]A new endpoint was created that returns if the current user is a privileged user or not. Responses:
{
"administrator": true
}
{
"administrator": false,
"administrator_message": "<Permission denied reason>"
} |
Setup or migrate the configurationI am researching how to migrate or pre-setup the configuration using the previous configuration through the Migration task on Wazuh dashboard initiationI added a mechanism to setup the configuration using the configuration file located at When the Wazuh dashboard starts, check if the configuration file is located in the expected directory ( This process is indicated to migrate the configuration of previous versions. APIUse the curl -k -u <username>:<password> --form file='@<config_file>' -XPOST <address>/utils/configuration/importwhere:
ℹ️ This process can be done by a privileged user. |
Desvelao
changed the title
Sync meetingShow
Discussion
Action items
|
Research - Administrator: Cluster permissionsOne of the action items of the last meeting was:
Currently, the security data of the user is getting through The role information can be used with the security plugin API to get the cluster permissions using the endpoint: whose response https://github.com/opensearch-project/security-dashboards-plugin/blob/v1.13.0.0/server/routes/index.ts#L273-L290 The In summary, to check if an user could have the desired cluster permission we could need to do multiple API requests:
Update 2024/02/20 I am working to get the role info using the internal user but this has no permissions to get this data. If we think to use this user, then we need to provide of the required permissions. If we use the current user, then the current user needs this permissions. I was testing to use the OpenSearch client that is comming in the security plugin: const response =
await context.security_plugin.esClient.callAsInternalUser(
'opensearch_security.listResource',
{
resourceName: 'roles',
},
);Based on https://github.com/opensearch-project/security-dashboards-plugin/blob/2.11.0.0/server/routes/index.ts#L248-L253 that uses the current user instead. |
Changes
|
Administrator user considerationsAccording to the research to use the cluster permissions instead of roles, this could need the current or internal user has permissions to retrieve data of roles or cluster permissions. Another option could be to use the same approach that is using the I opened a discussion with the cloud team to consider the implementation taking into account that can be compatible with its management. |
Meetingteam: documenation I asked to the documentation team a meeting to define the changes to apply in the documentation and take into account some considerations to organize the content. Topics
I was in a recent meeting with the documentation team discussing the topics: Actions items
|
Administrator user that can manage the configurationWe could use to consider the administrator user the same approach that is used to display the Security plugin that is only visible for users with permissions to access to the API. The Security plugin of OpenSearch Dashboards does a request to check the permissions and register the application depending on the value of Endpoint: Following this approach, we could create a function with the similar check and use it to consider the administrator user. async function isAdministratorUser(
context: RequestHandlerContext,
request: OpenSearchDashboardsRequest,
) {
const response = await context.security_plugin.esClient
.asScoped(request)
.callAsCurrentUser('opensearch_security.restapiinfo');
if (!response.has_api_access) {
throw new Error(`User has no permission.`);
}
}This approach removes the requirements to implement our own system based on roles or cluster permissions. Analysis of has_api_access valueThe The According to the analysis of the This means we can control the users that are considered as administrator for the Wazuh plugins using the roles assinged to the user and the Related to: #6201 (comment) |
Changes
|
Changes
|
Changes
|
Changes
|
Changes
|
Changes
|
Description
As part of the issue that pretends to remove the stateful of the Wazuh dashboard plugins, we need to adapt the way the plugin's configuration is defined through the current wazuh.yml file.
The configuration will be saved in a saved object. This should support deploys with multiple instances of the Wazuh dashboard with shared or independent configuration. More info: #6201 (comment)
wazuh-dashboard-plugins-configThe sensitive data related to API host entries must be protected through encryption. The data encryption must use a secret. More info: #6201 (comment)
The configuration management (edit settings, add API hosts) must be only allowed for the privileged users regarding the platform login data. More info: #6201 (comment)
The API host entries must be managed through the UI.
Tasks:
manageHostsserverAPIClientcacheAPIUserAllowRunAsserverAPIHostEntriesupdateConfigurationFilewazuh.ymlfilegetConfigurationserviceApp SettingsOther related issues:
The text was updated successfully, but these errors were encountered: