I'm working in a desktop application using Electron.js with React.js and I have to store some sensitive information like API keys and database credentials. So I started digging and decided to encrypt the database credentials in a JSON file with an obfuscation method on top of it.
Now I have two SECRET_KEYS, one for the encryption and one for the obfuscation. So my concern was how to save this information safely. I'm not very familiarized with Electron but correct me if I'm wrong: as far as I know, we don't have an option to use custom environment variables safely, because we would need to store these variables locally in order to use in the application. So doing some research I found that one of the strategies would be using some kind of external services to have these keys.
PS: the encryption key would be saved in S3 but I would still need to handle my AWS KEYS.
So I'm using Github Actions and setting the keys values in the secrets option. Basically, I have a workflow which will have an env option to specify my variables. This process happens after my build. -- I'm using Typescript so I have to run my build script to convert the code to JS.
Finally, on my Webpack, I have to use EnvironmentPlugin in order to access the environment variables values in my code.
Basically, I did all of this process to not hardcode my KEYS in the code or store them locally, but I'm don't quite follow the difference between having the keys hardcoded (considering I'm using a private repository) and having this process to set the keys values using the Github Actions. Because theoretically, Github would be replacing my process.env.MY_KEY with the value, right? or not?
I mean, if a hacker uses some kind of software to get my "source code", would he be able to see my KEYS content? The process I did with Github Actions is safe enough or is just being used to hide as much as possible my keys values?
If you need the keys specifically during the build process then yes i would recommend using github action secrets. As it will keep your keys safe while you build the app.
- name: Run Build
run: # run commands that require keys for building something
env:
SECRET_KEY_1: ${{ secrets. SECRET_KEY_1 }}
SECRET_KEY_2: ${{ secrets. SECRET_KEY_1 }}
If you need them at run time, meaning while running your electron app then you will need to store keys in the system itself, using something like
https://github.com/atom/node-keytar
const keytar = require('keytar')
// Creates a secret
keytar.setPassword('MyAppName', 'AccountName', 'secret');
// Reads the secret
const secret = keytar.getPassword('MyAppName', 'AccountName');
Depending if user is in windows, linux, or MacOs, they will get get prompted by the systems secrets holder. e.g in MacOs they will get prompted by keychain
Related
We have a Vue app hosted as an Azure App Service. Under Settings\Configuration in Azure Portal We have added application settings like VUE_APP_API_ENDPOINT_URL. These become environment variables like the documentation explains, and can be verified by opening a console from the portal and type 'env'.
I Had hoped that These env variables would now be accessible inside Vue by use of
process.env.VUE_APP_API_ENDPOINT_URL
My guess is that its only becomes available in VUE when aplication is build with WebPack or similar.
At least it doesn't work.
Are there any nice way to read those env variables created from Azure App Settings into the vue app?
Some people mentions dotenv npm package, but we need to read the env variables not add them from a config file.
You would be correct that the Environment Variables only become available when you build the application. And to elaborate on that, only the Environment Variables that you specify/supply at build time are the ones that become available in the application from the build process as per the documentation here:
https://cli.vuejs.org/guide/mode-and-env.html#environment-variables
Specifically look at this:
Note that only NODE_ENV, BASE_URL, and variables that start with VUE_APP_ will be statically embedded into the client bundle with webpack.DefinePlugin. It is to avoid accidentally exposing a private key on the machine that could have the same name.
I was struggling to accomplish essentially the same thing that you're trying to accomplish. I was trying to get a value from Azure's Application Settings so that I could setup multiple environments for my application and not have to constantly change values depending on the environment I published the app to.
After realizing that you might be onto something and reading the confirmation of such in the documentation, I decided to try putting the Environment Variable that I was trying to get from Azure's Application Settings in a .env file with a default so that it would be specified at build time. I then published my app to Azure and tested it and it worked!
Try creating a .env file with all of the Azure Application Settings that you're trying to set with default values or something, like:
VUE_APP_API_ENDPOINT_URL=default_value
And then set those same variables into your Azure Application Settings with the proper values and it should work.
Zoull's comment, while somewhat factual, is not possible. His comment implies that setting VUE_APP_API_ENDPOINT in Azure's Static App Settings blade will seamlessly include that var, and perhaps other VUE_APP_* vars into the vue app.
This is wrong.
Webpack is responsible for inclusion of VUE_APP_* vars into the build, and this is only possible at build-time.
This can be verified by following his logic, and then dumping to console "env" at runtime. Values will be set to, permanently, whatever they were at build-time.
tl;dr: Vue will never read, post-build, vars from Application Settings.
I use Github actions to build and deploy. By adding an env: setting after the with: stanza, and including VUE_APP_* vars there, I can do what OP is trying to do.
I believe I can also set some github "secrets" in githubs settings for my repo, and also include them dynamically in the YAML.
Ex. If I have a github secret key/val of: "VUE_APP_FOO: true", in my github action yml, I can do:
env:
VUE_APP_FOO: ${{secrets.VUE_APP_FOO}}
Then, in my final vue build, I should have a value of "true" when I read the process.env.VUE_APP_FOO var.
Savvy?
I'm working with node-red, on boilerplate IBM cloud. I know that there is a way, changing the value of enviroments variables(NODE_RED_USERNAME and NODE_RED_PASSWORD), to change username and password of the editor flow. But, what about UI dashboard? I mean using dashboard nodes. Forbid access to
https://noderedservicename.mybluemix.net/ui/
I know that on the code, changing the variable httpNodeAuth on the file settings.js I can do what I want. What is the way for doing that on IBM Cloud?
Thank you in advance!
You need to add the httpNodeAuth (not the httpAdminAuth as this is for controlling access to the Node-RED editor and can done with the environment variables discussed in the other answer.) to the app/bluemix-settings.js file.
Something like this:
...
httpStatic: path.join(__dirname,"public"),
httpNodeAuth: {user:"user",pass:"$2a$08$zZWtXTja0fB1pzD4sHCMyOCMYz2Z6dNbM6tl8sJogENOMcxWV9DN."},
functionGlobalContext: { },
...
Details of how to generate the pass can be found here
There are a number of ways you can edit the file, some of which include linking the Node-RED deployment to a git repository or downloading the whole app, editing the file and pushing it back to Bluemix (when you first deploy Node-RED from the starter pack it gives you instructions on how to download the source to make changes and then push them back. You can get to these instructions by clicking on the "Getting started" link in your Node-RED Bluemix console page).
But the quickest/simplest/dirtiest way is probably to just SSH into the instance and change the file with something like vi. Details on how to ssh to an app instance can be found here. But the following should work:
cf ssh [app name]
Once you have edited the file you will need to tell bluemix to restart the app. You can do this from the web console or with the cf command line tool.
(The changes made by this method will not survive if the app is restaged, or bluemix decides to move your instance to another machine internally because it will rebuild the app from the pushed sources. The permanent solution is to download the source, edit and push back)
This link will help you but it's written in Japanese.
http://dotnsf.blog.jp/archives/1030376575.html
Summary
You can define the "user-defined" environment variables through the IBM Cloud dashboard.
It contains the variables to protect Node-RED GUI.
You have to be set as follows
NODE_RED_USERNAME : username
NODE_RED_PASSWORD : password
We are planning to use New Relic on our website hosted in AWS.
What would be the best option - using the copy / paste javascript or install agent?
I am new to new relic monitoring. I thought I can use Install agent, but it looks like I have to expose the licence key. This is an open source project, so exposing the licence key is not an option. Is there any alternative to that?
If I go with copy/paste Javascript, Do I need to paste the script on every page?
Can someone throw best practice here?
There are different types of New Relic monitoring including server monitoring, application monitoring and browser monitoring. Also if your application has other components such as a database, there will be a separate monitoring agent for that.
I'm assuming you are asking about node.js application monitoring since you tagged your question with node.js. Best practice here is to configure the newrelic.js settings script to pull your app_name and license_key values from a system environment variable instead of adding them directly to the source.
I'm building a web app with Yesod and am currently passing in secrets such as API keys via environment variables (as per The Twelve-Factor App) to avoid storing these values in version-controlled configuration files. For example, I run my app in dev mode as follows:
SOME_API_KEY=value yesod devel
I have a value in my config/settings.yml file that is defined in terms of this environment variable with an empty value as follows:
meetup-api-key: "_env:SOME_API_KEY:"
To deploy using Keter, I'm building the Keter package using the yesod keter command and dropping the resulting file into Keter 'sincoming directory. Since I'm using environment variable configuration, my app's .keter file does not contain the SOME_API_KEY value (which is intentional).
How should I pass SOME_API_KEY into the instance of my app running inside Keter?
I would like to avoid baking the value into my keter-config.yaml for at least the following three reasons:
It is less secure than the environment variable approach.
Being embedded directly into the configuration file for Keter itself, as opposed to the configuration to the app, the secret cannot be changed without stopping and restarting the entire Keter process.
The environment variables are passed into every app being managed by Keter.
I am hoping that there are some "best practices" out there for this scenario.
Set your secrets as environment variables on your server and ‘forward’ them to your app using forward-env in config/keter.yml as seen in the following patch: https://github.com/snoyberg/keter/commit/9e9fca314fb78860fb5c9b08cad212d92b0b20d4
When using WAS we use the j2c credentials store to hold external system's users & passwords.
WAS provides some proprietary apis to get this information.
The benefit of using this instead of a local file that:
- the WAS admin can add/modify credentials having no knowledge of the application structure.
- it is managed in a central way for the whole cluster
- WAS stores it among other own credentials in a folder that is supposed to be secure (at SO level)
- Devs do not need to know about production passwords
Now we are coding for JBOSS and we wonder if there is any similar API in JBoss to get users/passwords by code.
Thank you!!
We have found the solution. JBoss has a "vault" that is explained in the security guide.
Basically it lets you cypher everything you want in the server configuration file (i.e. standadlone.xml). Then it decyphers it when starting the server.
We simple added a JNDI String to the server xml config file with the cyphered credentials. When we get that JNDI value from our code, credentials are already in plain text.
Quite an elegant solution from JBoss dev team.