Ability to expose and edit connector secrets

[mikecote]

With the current UX around connectors not returning encrypted values (ex: #74870), it feels the UX would be better if a limited set of users can see what encrypted values exist for each connector.

With the introduction of RBAC #43994, it is now possible to limit who can edit these connectors and the same could follow for viewing the encrypted values. The security team has also added such capabilities in the APIs #56013.

There are a few other scenarios that this enhancement could improve:

• Editing slack: the user currently can't see what webhook URL the connector refers to and has to find it again on each edit
• Editing webhook headers: when we add support for encrypting these, the user will have no clue how many secret headers previously existed and would have to enter them all again on edit
• Edit form not displaying encrypted values
• Future import connector experience
• more..

Some related issues:

• https://discuss.elastic.co/t/testing-kibana-alerting-slack-connector/249521

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[mikecote]

Side note: this may also questions the usage of Encrypted Saved Object AAD? Since we would return all the data, does AAD bring any benefit to connectors?

[pmuellr]

AAD is still useful - I think - for the case where a customer "hacks" a connector's config directly via SO or ES APIs partial update; eg, the url of a webhook. A partial update of that will succeed, but a subsequent attempt to decrypt the secrets will fail.

[mikecote]

@pmuellr

AAD is still useful - I think - for the case where a customer "hacks" a connector's config directly via SO or ES APIs partial update; eg, the url of a webhook. A partial update of that will succeed, but a subsequent attempt to decrypt the secrets will fail.

I'm sure there's a reason for why my thought won't work but; I wonder if everything should be encrypted instead? We could merge config and secrets into a fully encrypted object. It would facilitate some framework aspects I'm sure.

[mikecote]

Pinging @elastic/kibana-security on the issue as I think it'll be worth getting some early feedback / warnings as we explore the possibility of exposing connector secrets to users.

[mikecote]

@mdefazio mentioned the following from a UX perspective (please correct me if I'm wrong).

Users who can't edit connectors shouldn't be able to see anything other than the connector name. Otherwise, we would end up in the same issue where half the fields are returned for readonly users that can only read (partial) / execute the connector.

[mdefazio]

And to clarify a bit more on that note..

Users who can't edit connectors shouldn't be able to see anything other than the connector name.

refers to only seeing the connector name in the table and not opening the flyout to just see the name. If we are able to provide a bit more info to the user (barring security concerns) then perhaps we can show some read-only values in the flyout.

[pmuellr]

I wonder if everything should be encrypted instead?

From an API point of view, I think this could work, we just need to be careful not to send down the secrets when we shouldn't be. We get that "for free" today, since you have to specifically decrypt the SO to get the secrets, and normal SO access just doesn't give them to you.

OTOH, this would make informal problem diagnosis harder, in terms of folks peeking through SOs, since nothing will be visible.

Did we ever discuss either using the existing keystore, or maybe having a separate SO keystore? The idea would be that you store your secrets with some kind of useful id in a new SO; eg, id: webhook url for slack tests secret: <webhook url here>. Then when you need to provide a secret when creating a param, you provide the id to that secret, eg webhook url for slack tests. Then we won't have any secrets, except in the "keystore".

[legrego]

With the current UX around connectors not returning encrypted values (ex: #74870), it feels the UX would be better if a limited set of users can see what encrypted values exist for each connector.

In general, we don't have the ability to restrict decryption to a specific set of users. If a SO attribute is marked as dangerouslyExposeValue: true, then anyone with read access to the saved object will be able to see the decrypted value.

I say "in general" because Alerts/Actions are a bit different in that you've implemented your own authorization model on top of these specific saved object types. So our lack of support won't prevent you from adding your own support, at least for now. I'm happy to help brainstorm ideas for how this might work, so that we have a consistent experience if/when add support for the "normal" SO types.

[mikecote]

@legrego

I'm happy to help brainstorm ideas for how this might work, so that we have a consistent experience if/when add support for the "normal" SO types.

👌 awesome, thanks! We'll be in touch when we get closer to working on this.

[mikecote]

Moving from 7.x - Candidates to 8.x - Candidates (Backlog) after the latest 7.x planning session.

[mikecote]

Closing due to lack of interest and activity.