[MD] Add data source signing support

[noCharger]

Signed-off-by: Louis Chu [email protected]

Description

Add data source signing support

Signature algorithm: ECDSA with P-384 and SHA-384. Under multiple data source case, data source indices stored on OpenSearch can be modified / replaced by attacker, as @dblock pointed out. With ECDSA signature, ciphertext decryption will fail if it’s getting pullted. No one will be able to create another signature that verifies with the public key because the private key has been dropped.

Step to change endpoint on OpenSearch

1. Create a data source with endpoint https://localhost:9200

      {
        "_index" : ".kibana",
        "_id" : "data-source:0000000",
        "_score" : 1.3862942,
        "_source" : {
          "data-source" : {
            "title" : "test-1",
            "description" : "",
            "endpoint" : "https://localhost:9200",
            "auth" : {
              "type" : "username_password",
              "credentials" : {
                "password" : "****",
                "username" : "test"
              }
            }
          },
          "type" : "data-source",
          "references" : [ ],
          "updated_at" : "2022-10-06T19:58:13.069Z"
        }

2. Update the document (either full doc or partially)

PUT /.kibana/_doc/data-source:0000000
      {
          "data-source" : {
            "title" : "test-1",
            "description" : "",
            "endpoint" : "http://hacker.com",
            "auth" : {
              "type" : "username_password",
              "credentials" : {
                "password" : "****",
                "username" : "test"
              }
            }
          },
          "type" : "data-source",
          "references" : [ ],
          "updated_at" : "2022-10-06T19:58:13.069Z"
        }

3. Read the document again
   GET /.kibana/_doc/data-source:0000000

     {
       "_index" : ".kibana",
       "_id" : "data-source:0000000",
       "_score" : 1.3862942,
       "_source" : {
         "data-source" : {
           "title" : "test-1",
           "description" : "",
           "endpoint" : "http://hacker.com",
           "auth" : {
             "type" : "username_password",
             "credentials" : {
               "password" : "****",
               "username" : "test"
             }
           }
         },
         "type" : "data-source",
         "references" : [ ],
         "updated_at" : "2022-10-06T19:58:13.069Z"
       }

Issues Resolved

#2520
#2207

Check List

• All tests pass
  • yarn test:jest src/plugins/data_source
• New functionality includes testing.
• New functionality has been documented.
• Update CHANGELOG.md
• Commits are signed per the DCO using --signoff

[ashwin-pc]

I think the auto linter here needs a fix since this will cause conflicts with all existing PR's if merged.

[ashwin-pc]

@noCharger Can we keep the diff limited to just the change? I know it can be tempting (or just an accident) to push in a bunch of other linting fixes but that makes the PR harder to read and is also usually a source for other merge conflicts unrelated to your change. We can address them in a separate PR.

[noCharger]

@noCharger Can we keep the diff limited to just the change? I know it can be tempting (or just an accident) to push in a bunch of other linting fixes but that makes the PR harder to read and is also usually a source for other merge conflicts unrelated to your change. We can address them in a separate PR.

@ashwin-pc Yes it's triggered by the prettier. Created a seperate issue for the lint on CHANGELOG #2519 and removed the lint changes on this PR.

[codecov-commenter]

Codecov Report

Merging #2510 (2ba789e) into main (7777749) will increase coverage by 0.00%.
The diff coverage is 82.35%.

@@           Coverage Diff           @@
##             main    #2510   +/-   ##
=======================================
  Coverage   66.73%   66.73%           
=======================================
  Files        3203     3204    +1     
  Lines       60978    60988   +10     
  Branches     9274     9275    +1     
=======================================
+ Hits        40692    40702   +10     
- Misses      18067    18068    +1     
+ Partials     2219     2218    -1     

Impacted Files	Coverage Δ
...plugins/data_source/server/cryptography_service.ts	72.22% <72.22%> (ø)
...gins/data_source/server/client/configure_client.ts	87.17% <88.88%> (+7.17%)	⬆️
...s/data_source/server/cryptography_service.mocks.ts	100.00% <100.00%> (ø)
...ta_source/server/legacy/configure_legacy_client.ts	70.83% <100.00%> (+6.25%)	⬆️
...ared/static/forms/hook_form_lib/hooks/use_field.ts	65.70% <0.00%> (-0.97%)	⬇️
...ic/application/models/sense_editor/sense_editor.ts	65.77% <0.00%> (+0.88%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[kristenTian]

One favor, could you mention the testing steps about how to reproduce the attack and expected error message? This way others know how to test as well.

[noCharger]

One favor, could you mention the testing steps about how to reproduce the attack and expected error message? This way others know how to test as well.

@kristenTian Reproduce the attack seems to be a risky thing because it's not a bug but a system level security leak. From system architecture, we cannot gaurantee the document is untouched on OpenSearch side. Added one simple (non-hacking way) example here

From OSD side, there are UTs on PR

https://github.com/opensearch-project/OpenSearch-Dashboards/pull/2510/files#diff-a0206b2410205bc1ae830a9621db3abcbfad402f94655f1ad99d6d44dcd8fdceR176-R189

[zhongnansu]

lgtm. found 1 typo

[ananzh]

LGTM

[zengyan-amazon]

better to log the error into 1 message

[zengyan-amazon]

since you throw it on L299, so you don't need to log it here