Cloud9 is a cool service. IF you create a workspace that is public it will mean that everyone who knows your project url and have an account at cloud9 can browse and download your code. This means that if my project have, for example, connectivity to mongodb, everyone will see login and password to connect to mongo (because it will be in some source file).
The only option I can see to store passwords securely (except making project private) is to somehow add them to environment variables, and use process.env.XXXXXX call within the code. This seems to be secure because even if others may browse my code they cannot open terminal and check what environment variables I have defined.
So, is there a way to add my custom environment variable(s) to that they would be accessible via process.env.XXXXXX inside node's code?
You can define environment variables in ~/.profile. Files outside of the workspace directory /home/ubuntu/workspace are not accessible for read only users. You can do e.g.
$ echo "export SECRET=geheim" >> ~/.profile
to define the variable SECRET and then use it through process.env.SECRET from your application. The runners (from the "run" button) and the terminal will evaluate ~/.profile and make the environment variable available to your app.
When running project with cloud9 runners there is Environment popup on the right side of the runner toolbar. You can use it to add environment variables the way you want, but make sure to not add a name to the config since configs with name are automatically saved in .c9/project.settings
Another solution is to create a file in the directory not exposed in readOnly mode. e.g
echo "password" | sudo tee /xxx
you can even edit /xxx file using vi inside cloud9 terminal.
But Of course the best solution is to buy premium subscription, and get more private workspaces:)
Related
I am using mongoose with MongoDB in a NodeJS application. Right now, in development, I have a configuration (.env) file which stores sensitive information my code needs to run. For example, the MongoDB password & URL, emails & passwords needed to email using the code, etc.
When I put it into production, it would obviously be wrong to upload this configuration file anywhere on the cloud, given the information in it. How can I make it so my production code, hosted somewhere such as Heroku, can access these needed variables without letting undue access to them?
Thanks in advance!
You are right, pushing your env file to production is pretty bad from a security perspective.
The way you would go with storing your environmental variables differs between cloud platforms, but essentially you should get a secure way of adding them through either an user interface or through terminal (You usually find these information easily by looking into your provider documentation).
To store them in a project deployed on Heroku, you will need to:
Log to Heroku
Open the newly deployed project
Head over the Settings tab
Find the section named Config Vars
Click on Reveal Vars
Add your variables in there
And you are good to go!
Can someone explain what's benefits of environment variables in Node.js over regular config file?
In my project I have config.js files with DB details, AWS keys, etc. This file is added to .gitignore and never shared on repository, instead there is demo.config.js file with all required parameters filled with fake creditentials, so you can just copy it as config.js and fill it with correct details after fresh install.
This file is "required" in every file when I need credentials in my project and on my development machine this config file is configured with test server details and with actual production server details on production machine.
Lately I read everywhere that everyone should use environment variables to store credentials safely, but I don't see any benefit to doing so in my project.
I'm not saying it's bad and my approach is better, I just want to know what actual benefit (security or otherwise) will I get with environment variables over my setup?
For me it is more like a common standard than anything else. The way how you use config.js is practically the same as using environment variables. But instead of storing the configuration in environment variables, you store it in js file.
The main difference is how you read that config. All mainstream languages I know, will easily allow you to read from environment variables, there is really wide support for it. Reading from config files brings additional complexity as you need to know the structure of that file, how to parse etc. In some languages (maybe node.js) it is probably easy to read from js file, but in others it could be difficult task.
That's why using environment variables is just a common standard and language agnostic. You can even read it in bash scripts etc.
Edit: adding reference to The Twelve-Factor App, the Config section is particularly connected with above question:
https://www.12factor.net/config
One benefits i see when you are using docker for local development and kubernetes or any container orchestration for SIT/UAT etc where config setting is there . In local development we keep all env variable required and move the same on container based system
I know that a good way to store data like db passwords, etc. is via environment variables, but setting environment variables manually for every server instance created is time consuming.
I'm planning to deploy my project to the cloud (using aws ebs or heroku).
where should I store my db password?
I think the .ebextensions file isn't a good option because it's tracked in vcs
Don't ever store secrets in source control. A common practice is to either put them in a secure file or in something like https://www.vaultproject.io/ then inject them (programmatically via a script or some other deployment/configuration tool) into the environment when you bring up your VM (or container or whatever).
My recommendation is to create a properties file which can be stored in the resources folder of your application and the code can access the resources. do not need environment variable. One property file can contain all db's userid and passwords. Deploy job based on url mapping in the properties file. For example, look at a spring hibernate example project which uses a property file. Or look at ant deploy scripts. Hope it helps.
In the origen docs it says that the gems are installed in the user's home directory. Can this be configured by each user?
EDIT *
I placed a copy of the origen_site_config.yml file in my application's root directory and enabled the following line:
# Define where a typical user's home directory will be, with a hidden directory for Origen.
home_dir: /users/thisuser/origen
I expected this to work and start installing at /users/thisuser/origen/.origen but it did not. I deleted the .bundle and lbin directories and got no change in the installation directory either.
thx
This question prompted a PR and some new documentation on how to change the install directory of gems within Origen.
I haven't ever tried it but you should be able to override the install using the site_config.
Ruby/Bundler will by default install gems into the Ruby installation directory.
However, since it is commonplace in corporate engineering compute environments for users to share a common Ruby installation to which they don't have write access, Origen provides a default Bundler configuration which will instead install gems to the user's home directory.
This install location is defined by the gem_install_dir attribute of the Origen Site Config.
This can be overridden on a company level in the master site config, however this is (currently at least) a static variable, so the only way to make it user specific is to reference $HOME or some similar Linux-level variable used within the given environment.
It is possible to have all users share a gem installation directory, however the downside to that is that all users will need to have write access to it and therefore potentially a hack to a gem source by one user could end up introducing a very hard to detect bug that affects the whole company.
Better then, is to override on a per-user basis if you don't like filling up your home directory with gem files.
Here are the various ways to do that:
1) Any site config variable can be overridden by setting an environment variable named ORIGEN_<uppercased variable name>, so ORIGEN_GEM_INSTALL_DIR in this case.
2) Symlink $HOME/.origen to somewhere else.
3) Users can use their own site config file. See the guide for more details, but Origen will search multiple places for a config and parameters defined in configs which are closest to where the application lives will override more distant defaults. So for example, say a user kept all of their Origen workspaces in /my_projects/origen/, e.g. /my_projects/origen/my_app, then anything config attributes defined in /my_projects/origen/origen_site_config.yml would override those set at the company-level.
Bundler will cache this configuration on a per-workspace basis, so anytime you make changes to a configuration like this it is recommended to either start with a fresh workspace, or run the fix_my_workspace script.
What is the recommended way to add user level environment variables to be used by a GUI application (binary of a wxPython application) in linux (Ubuntu)? I know there are ~/.bashrc, ~/.cshrc, ~/.profile etc for console apps.
Where can I add new paths to existing PATH?
(/bin:/usr/bin/:/usr/X11R6/bin/usr/local/bin)?
How to add settings as new key value pairs? This is meant to be used by a bunch of applications.
PATH and some other variables are stored in /etc/environment
In my opinion, the best place for settings is /etc/.APPNAME/conf or ~/.APPNAME/conf