13

Authentication information such as database connection strings or passwords should almost never be stored in version control systems.

It looks like the only method of specifying environment variables for an app hosted on OpenShift is to commit them to the Git repository. There is a discussion about this on the OpenShift forums, but no useful suggested workarounds for the problem.

Is there another approach I can use to add authentication information to my app without having to commit it to the repository?

drzax
  • 1,675
  • 1
  • 16
  • 20

4 Answers4

27

SSH into you application and navigate to your data directory

cd app-root/data

in this directory create a file with your variables (e.g. ".myenv") with content like

export MY_VAR="something"

and then in your repository in ".openshift/action_hooks/pre_start" add this line

source ${OPENSHIFT_DATA_DIR}/.myenv
xeor
  • 5,301
  • 5
  • 36
  • 59
Marek Jelen
  • 794
  • 6
  • 7
  • This seems like the answer I'm looking for, but in my quick testing the custom variable doesn't show up in the `process.env` object in Node.js. I'll have a closer look on the weekend. – drzax Nov 29 '12 at 00:27
  • This does at the environment variable and make it available in the app. One note for Node apps: a bunch of the environment you would expect (including custom ones added like this) are not available in scripts run directly on the command line over SSH. – drzax Jan 08 '13 at 01:58
  • Mine had to be in the file `.openshift/action_hooks/pre_start_nodejs-0.6`. Found the app name gem in a [random comment](https://www.openshift.com/forums/openshift/permanently-add-to-path) somewhere. But doing that fixed my problem :) – kentcdodds Jul 17 '13 at 04:13
  • Worked for me in node.js none of the others did. Had to put in .pre_build though. – Jackie Apr 08 '14 at 03:40
18

Openshift supports now setting environment vaiables with the rhc commandline tool like this:

rhc set-env HEROKU_POSTGRESQL_DB_URL='jdbc:postgresql://myurl' -a myapp

I think thats way easier than all the other answers...

See: https://blog.openshift.com/taking-advantage-of-environment-variables-in-openshift-php-apps/

bmaupin
  • 14,427
  • 5
  • 89
  • 94
jbandi
  • 17,499
  • 9
  • 69
  • 81
5

Adding .openshift/action_hooks/pre_start_* is not very cool, because you have to modify your repository in addition to add a file by SSH.

For nodejs, editting nodejs/configuration/node.env works well for some days, but I experienced the file got reverted several times. So it is not stable.

I found a much better solution.

echo -n foobar > ~/.env/user_vars/MY_SECRET

This works perfectly.

(Maybe this is what is done with rhc set-env ...?)

Hope this helps!

user2524758
  • 272
  • 3
  • 3
2

Your other option is to create an openshift branch of your project on your local machine. You can create a folder/files for the private information that only lives in your openshift branch. You would still need to source the files in your pre_start hook, something like source ${OPENSHIFT_REPO_DIR}/.private.

Then develop in your master branch, merge into your openshift branch, and push from your openshift branch to OpenShift master branch. This sound convoluted at first, but does make for a very easy workflow, especially if you're origin is shared.

This would be the workflow if your origin was on GitHub.

github/master <--> local/master --> local/openshift --> openshift/master

Notice the only bidirectional link is between github and your local master, so there should be no reason for your credentials to "escape".

This approach also has the added benefit of being able to keep any OpenShift specific changes confined to the openshift branch (like for Gemfiles, ENV variables, paths, etc).

As for security, on the OpenShift server, the repo should have the same security as your $OPENSHIFT_DATA_DIR, so you're not really exposing yourself any more.

Caveat: Depending on your framework, the files in your $OPENSHIFT_REPO_DIR may be directly accessible via HTTP. You should be able to prevent this with an .htaccess file.

Fotios
  • 3,643
  • 1
  • 28
  • 30
  • I specifically wanted to avoid this convoluted multiple repository setup, but I can see some of the benefits. Also, thanks for the heads up about the repo directory being accessible over HTTP - another good reason to keep credentials completely out of the repository. – drzax Nov 29 '12 at 00:25