[Synthetics] Remove Ability to View Synthetics Global Parameters from Kibana Synthetics App

[renzedj]

Use Case

As an Elastic Cloud admin, I want my users who create Synthetics tests to be able to securely use parameters for any secrets in their tests, however at this point they cannot, because any user with ALL access to the Synthetics app in Kibana can retrieve them from the Global Parameters vault.

Details

Currently, any user with ALL access to the Synthetics app in Kibana can go into Synthetics->Settings->Global Parameters, click on the "show value" option in the line containing a parameter, and retrieve the parameter from Kibana. This creates a security risk, as these are secrets such as passwords, keys, or other items which should not be generally available. To prevent this, I need to remove ALL access, which also removes the ability for users to set their own alerts.

Recommendation

As noted in this post, the decision to allow users with write access to view parameter values in the UI was a conscious one. However, this creates a security risk, and in most cases this there is no requirement to be able to retrieve a parameter from within Kibana. Even as an Elastic Admin, I cannot see a requirement to be able to retrieve a secret from Kibana, as according to best practice any secrets should also be vaulted.

The easiest way to resolve this would be to do the following:

1. Remove the "show value" option from the line items in Synthetics->Settings->Global Parameters.
2. Mask the value in both the "Create Parameter" and "Edit Parameter" screens.
3. Update documentation to indicate that parameters are one-way and cannot be retrieved from within the Kibana UI.

This would effectively make the parameters "one-way" (i.e., a user can create/update a parameter, but not view it after from within Kibana).

[elasticmachine]

Pinging @elastic/uptime (Team:uptime)

[paulb-elastic]

@renzedj notwithstanding your point about being able to show it in the Kibana UI (with the correct permissions), it's also worth highlighting it will never truly be "one way", as described in the docs, it would still be possible for a script to be written to make use of those parameters (e.g. even just typing them into the Google search bar and getting a screenshot of the value).

[renzedj]

@paulb-elastic -

@renzedj notwithstanding your point about being able to show it in the Kibana UI (with the correct permissions), it's also worth highlighting it will never truly be "one way", as described in the docs, it would still be possible for a script to be written to make use of those parameters (e.g. even just typing them into the Google search bar and getting a screenshot of the value).

You are absolutely correct. There is absolutely nothing magical about this to prevent a bad actor from retrieving this anyway. Ultimately, it's my responsibility as the admin to have the proper controls in place to prevent this.

To use an analogy, Elastic gives me as the admin the tools I need to restrict access to our Elastic Cloud instance, including the ability to secure the installation using various methods of user authentication. However, there's nothing that would prevent me from creating a universal username/password combination of guest/guest and handing that out. It's my responsibility as the admin to use sensible security, such as tying it in to my company's SSO. Even then, my company needs to have additional controls in place to ensure that fake users aren't slipped into our SSO and that users who have exited the company have their access removed in a timely fashion.

In this situation, this is providing a tool to help admins like me to protect sensitive data (e.g., secrets). We do still need to have other controls in place, such as not allowing tests to be created from within the UI and requiring that they be written offline using the @elastic/synthetics node.js tools so that they can be in version control, reviewed by an admin, tested, and deployed via a CI/CD pipeline, just like any other application in the environment.

[shahzad31]

@renzedj do you think restricting access to the show button would be probably better?

I guess it can be something like only show with an admin user.

Another is we also allow editing of the param, so wouldn't that be same as showing? I mean if user has access to edit. They can also View it?

I am also thinking it can be maybe perhaps bit more refined access control we recently implemented a flag in uptime/synthetics privileges where now if you want you can disable access to elastic managed locations for a user.
Perhaps we can refine privileges access more for creating alerts, creating locations and Parana.

[renzedj]

@shahzad31 -

@renzedj do you think restricting access to the show button would be probably better?

I guess it can be something like only show with an admin user.

Yes, that would be fine, as long as it is also masked on the create/edit screens. However, I'm not certain why there's a need to retrieve it through the Kibana UI. As an admin, if I can give a user the capability to create the parameter without my involvement so that even I don't know what the value is, then that would be a best-possible outcome. But then again, I'm not your only customer.

Another is we also allow editing of the param, so wouldn't that be same as showing? I mean if user has access to edit. They can also View it?

No. Not if the parameter value is masked when it's created/edited, as described in my original post.

I am also thinking it can be maybe perhaps bit more refined access control we recently implemented a flag in uptime/synthetics privileges where now if you want you can disable access to elastic managed locations for a user.
Perhaps we can refine privileges access more for creating alerts, creating locations and Parana.

This makes me very happy to hear, as I also have another feature request #167789 open, which requests exactly this for alerting. Has this feature already been released, and can you point me to the documentation? I was looking through the permissions settings a few days ago on 8.10.2 and didn't see this permission available.

[shahzad31]

It's a recent PR

#164863

It will ship with 8.11.0

[renzedj]

Thx. Frankly, giving my users read + alert access to Synthetics and reserving the privileges to view parameters to all access (as per current practice) would likely accomplish the same thing I'm trying to accomplish with this request.

[renzedj]

bump

[shahzad31]

@renzedj we have picked this up and is being fixed as part of #195866

[elasticmachine]

Pinging @elastic/obs-ux-management-team (Team:obs-ux-management)