How do I force Elastic Synthetics to use environment variables defined in the pod environment?
Use Case
I am in the process of migrating our synthetic monitoring framework to Elastic Synthetics. I'm currently using @elastic/synthetics==^1.1.0 and am deploying them via npm push. Due to the fact that parameters defined in the Synthetics app appear to be fully visible to anybody with access to the app, I am using environment variables to define my parameters as environment variables (e.g., process.env.VARIABLE_NAME).
The issue is that when I push the tests to Elastic Synthetics using npm push, it pushes the local values of the environment variables to Synthetics, rather than using the values defined in the pod environment. This means that if I happen to be developing with my personal credentials which have the necessary access and then push, it caches my personal credentials in synthetics and uses those, rather than using the credentials defined in my pod deployment (e.g., screenshots will show my personal username/password being used).
By the same token, if I do NOT have any environment variables defined in my local account when I push, then it fails because the string undefined appears to be substituted for my credentials instead of the environment variable in the pod.
Additionally, when using locally-defined environment variables, it appears that a change in the environment variable locally does NOT trigger a change in the script to force it to push again on the next update. As a result, in order to update a set of credentials, it then becomes necessary to delete the test and redeploy it, rather than updating the pod secret and restart the synthetics pod.
Is there any way around this? Can I force it to use the environment variables defined in the pod, rather than loading my local variables?
Certainly, as I may not have expressed myself clearly.
Anybody who can view synthetic tests within Kibana appears to also have the ability to not only see the names of the defined parameters, but their values as well (at least, this was the case in 8.7.x; I haven't confirmed with 8.8.x). I referenced this in passing in another post, but it was a throwaway remark and wasn't germane to the overall question, so I dropped it.
Since this is insecure, I made the decision to use environment variables instead, thinking that the journey would inherit the pod variables, not my local variables.
If this is the expected functionality and not just something about how I happen to have my permissions configured, then the way I would expect it to work would be that any user with access to Synthetics can view the parameter names, but only admins or those with specific permissions can view the values.
So the permission model that we decided for global params is that the user with write permissions will be able to view the params. Do you think it should be more restrictive?
Regarding using different env vars for different prod, staging setup. I imagine the thought process was that user will use those env to push the monitor. Not the local env to push the prod env.
That may well be my issue. I granted users feature_uptime.all so that they can set alerts (otherwise I have to manage all alerts). I totally forgot about this until you asked that last question - so thank you.
I assume that's what also gives them the ability to see parameter values? If so, this answers that question.
What seems to make more sense would be for ALL permissions be more granular (not just for synthetics). What I would like to be able to do is grant users the ability to set and respond to alerts without also granting them the all permissions, which I've had to do across the board. So to answer your question, yes: that permission should be more restrictive.
Also - with the change in name from uptime to synthetics, is that permission changing at all?
Barring the ability to set more granular permissions, which I assume would take time even if it were to be prioritized, we come back to my original question: Is there a way to force Elastic Synthetics to use the environment variables set in the pod rather than uploading my local environment variables?
It's a great question @DougR and a tricky one to answer. I think everyone in the industry would like to deliver exactly the feature you mention. However, one of the issues with giving people permission to use a variable but not see it is that it's easy to circumvent given the nature of a synthetics product.
For instance, you can just take the secret and put it in a text area on a website if you want to exfiltrate it (or submit it on a form that's emailed to you), or even just look at the screenshot in the app. For an HTTP lightweight monitor you could have it post to some API you control etc.
So, it's something that could be built, but the tricky part is that there's no way to enforce that, and we certainly wouldn't be able to message any security guarantees around it.
WRT your question around perms, Uptime and Synthetics share the same perms. You'll notice in the Kibana stack management UI they're labeled "Synthetics and Uptime"
I think reading what you wrote again I see you're asking for something different than what I thought. You want users to be able to create alerts and view data, but not necessarily be able to edit monitors, is that right?
I think I see what you're getting at here @DougR , it's a good point. I can see why it'd make sense to do exactly what you're saying. I'll take it back to discuss internally with product.
And I wouldn't expect any guarantees around it from your side. It's on the client to have internal controls in place to enforce security; this is just a tool to support those controls. This is ultimately no different than the fact that Elastic gives me the tools to secure my Elastic Cloud instance, but it's my responsibility to lock it down with commonsense policies and controls.
In this case, the easiest control is to require that all tests be developed offline in a common repository and that a pull request be reviewed and approved by a member of the admin team prior to being deployed. With that in place, read access + the ability to set an alert would be all that a standard user would require.
WRT your question around perms, Uptime and Synthetics share the same perms. You'll notice in the Kibana stack management UI they're labeled "Synthetics and Uptime"
Thanks. I missed that when I was looking at this.
Exactly. Here is a sample user story for this feature: As our company's Elastic admin, I need to be able to give my users the ability to view synthetics data, as well as have the necessary permissions to manage, acknowledge, and respond to alerts WITHOUT giving them all access to Synthetics, which allows users to create/edit tests in the Synthetics UI, as well as view parameter values, which creates a security risk.
This would allow my team to store parameters in Elastic Cloud, as well as easily update them according to our internal policies. If you can point me to the correct place in your Github repo, I can submit this as a feature request.
In the meantime, is there a way to force @elastic/synthetics to use the environment variables supplied in the pod rather than push local environment variables with the test?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.