[Cloud Security] Secrets are showing [object Object] once displayed on the screen

[romulets]

Kibana version:
8.12-SNAPSHOT

Elasticsearch version:
8.12-SNAPSHOT

Describe the bug:
During the development of https://github.com/elastic/security-team/issues/7380 some variables are no longer simple values (string, numbers, booleans) but secret objects.

Secrets should be update-only, so secrets can't be leaked in services (bugs, logs) or humans.

Once a secret is stored, kibana retrieves the following:

But when the stored secret is shown in a password field (and I assume in other text representation) it shows [object Object] because it tries to render the secret object

Steps to reproduce:
While https://github.com/elastic/security-team/issues/7380 is not done

1. Add a secret: true to any field in cloud security posture findings manifest.yml. I recomend adding to stream cloudbeat/cis_aws field name secret_access_key

• Bump the version to another preview in the changelog and manifest
• Build the cloud security posture integration up

# from integrations root
cd packages/cloud_security_posture
elastic-package build
cd ../../
elastic-package stack up -v --version 8.12.0-SNAPSHOT --services package-registry

• Start the package registry with latest build

2. Bring the rest of elastic stack up

# from integrations root
elastic-package stack up -v --version 8.12.0-SNAPSHOT --services package-registry

3. Add a security posture management integration filling the field labeled as secret
4. Edit the integration and visualize the secret.

If the secrets adoption in cloud security posture is finished:

1. Bring elastic stack latest up
2. Add a security posture management integration with secrets
3. Edit the integration and visualize the secret.

Expected behavior:
It's not clear to me what should be shown, but not [object Object]. The secrets project should have that answer.

[elasticmachine]

Pinging @elastic/kibana-cloud-security-posture (Team:Cloud Security)

[romulets]

@maxcold commented on the issue where I found this bug https://github.com/elastic/security-team/issues/7380#issuecomment-1829832615

The rendering issue most likely is related to the fact that we implement our own forms, leveraging the fleet feature of redefining the configure step inside the integration. We will need to investigate, if fleet provides the primitives to work with secrets in the UI, the worst case we will need to duplicate the implementation on our side (which wouldn't be ideal as we would need to keep our implement in sync with the fleet one)

[maxcold]

Fleet has a document where they track the UX changes regarding secrets https://docs.google.com/document/d/1bDVPe90eXxUOcbKK_0Uo9J74io7_lVvYzQ2kk8mJHR0/edit#heading=h.ic4r6ausqrli

Ideally we find a way to reuse as much as possible from what Fleet already has, otherwise we will have hard time catching up with their UX changes

[orouz]

i think the best way forward here is to use the original input component from fleet (PackagePolicyInputVarField). a while ago i did some experimenting and it seemed to work fine. also removes the need for our own custom input implementations.

[Omolola-Akinleye]

The 8.13.0-SNAPSHOT build hasn't started yet so @romulets can't merged his PR right now.

[Omolola-Akinleye]

Resumed working on ticket

[Omolola-Akinleye]

I found a bug in Fleet where when I try to save the Cloud Security Posture Integration and we get undefined id error. I pinged Fleet Channel

TypeError: Cannot read properties of undefined (reading 'id')
    at reduce (secrets.ts:790:66)
    at Array.reduce (<anonymous>)
    at forEach (secrets.ts:782:21)
    at Array.forEach (<anonymous>)
    at getPolicyWithSecretReferences (secrets.ts:781:15)
    at extractAndWriteSecrets (secrets.ts:244:32)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at PackagePolicyClientWithAuthz.create (package_policy.ts:253:28)
    at createPackagePolicyHandler (handlers.ts:270:27)
    at core_versioned_route.ts:179:22
    at Router.handle (router.ts:228:30)
    at handler (router.ts:162:13)
    at exports.Manager.execute (/Users/omololaakinleye/elastic/kibana/node_modules/@hapi/hapi/lib/toolkit.js:60:28)
    at Object.internals.handler (/Users/omololaakinleye/elastic/kibana/node_modules/@hapi/hapi/lib/handler.js:46:20)
    at exports.execute (/Users/omololaakinleye/elastic/kibana/node_modules/@hapi/hapi/lib/handler.js:31:20)
    at Request._lifecycle (/Users/omololaakinleye/elastic/kibana/node_modules/@hapi/hapi/lib/request.js:371:32)
    at Request._execute (/Users/omololaakinleye/elastic/kibana/node_modules/@hapi/hapi/lib/request.js:281:9)

[Omolola-Akinleye]

Currently, this task is blocked by bug issue ticket when saving integration with secrets. Moving the ticket to Todo until the bug is fixed.

[tehilashn]

Delaying to 8.14

[kfirpeled]

#173718 merged, moved back to Todo

[kfirpeled]

To verify include also:

• verify agent policy is passing the secrets

Make sure that for type: password on the manifest we don't expose the previous secret.
Make sure that for type: text on the manifest we allow seeing the previous secret.

[maxcold]

It seems like we don't handle the textarea case, for the GCP JSON blob type. The issue can be reproduced with 8.14 BC1 and 1.9.0-preview4 intergration

[moukoublen]

Verified ✅

Before install

After install

Edit integration