When building an environment-specific Grails WAR file configurations from other environments are included in the WAR file as well. For example, all the database connections properties from the production environment are also included in a WAR file built for test. Even though the configuration is compiled to class files it's quite simple to extract sensitive data from there.
In order to improve security, I want to exclude unrelated environment configurations from a WAR file. Is there a way to strip this configuration automatically during the WAR build or do I have to externalize these configurations and deploy them separately?
I suppose if you could somehow analyse the bytecode and work out precisely which Config$_closure3$_closure12 corresponds to the bit you don't need then you might be able to replace it in the war with an empty closure, but it's probably more hassle than it's worth. There's certainly no easy way I'm aware of.
I would put the config for each env in a separate file. If you put the prod config in web-app/WEB-INF/classes/myapp-prod.groovy (still in an environments block) and the dev config in a file in the top directory, and say
grails.config.locations = ["classpath:myapp-prod.groovy", "file:myapp-dev.groovy"]
then only the prod configuration will end up in the war. Though it would be completely human readable, so it may be more secure to simply leave the prod config directly in Config.groovy (so it gets compiled) and just use the external to override for dev mode.
Related
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
Is there a way to set up a project in Eclipse so that if my code has a reference to the system root directory then it will point to my workspace instead? (I am not seeing anything in the Run Configurations that would help me with this.) Something like the equivalent of making a sym link / that points to my workspace directory.
I'm working on a perl project that has absolute references to the hosting Linux file system in what would be the production environment. Those directories don't exist in my development Eclipse environment. My workspace is located in an NFS space mounted on a cluster of servers that run Eclipse I access in my laptop via client software.
So root can be any server's local space within the cluster and I don't have any access to anything above the workspace, and so I can't create the directory structures I need. I would rather not hard-code alternate directory paths to accommodate differences between the sandbox and production environments and having to comment them out when deploying to the prod environment.
I'm not finding a straightforward answer online. Maybe I'm not articulating the question correctly and help with that would also be appreciated if that is the case.
No. Good practice is to have paths like that configurable at runtime, usually via an environment variable or command line argument, specifically to accommodate changes between development, sandbox, and production environments.
Our asp mvc is published automatically using octopus deploy. We use web config transformations and we always end up with additional environment specific files in the installation folder. Eg
Web.development.config
Web.test.config
Web.preprod.config
There is a slight advantage in having these files deployed since we can easily compare values between different environments when troubleshooting.
Is there an security risk in having different config files deployed to a production environment??
IIS should be configured to prevent the download of .config files by default, but depending on how tight your security needs are, it might be worth getting rid of them. (eg if someone comprises a test server, they do not gain access to production).
If you do want to get rid of the, you can write a PostDeploy.ps1 script to remove Web.*.config
These files can be removed using the community-contributed step File System - Clean Configuration Transforms.
If you want them to be available for diagnostic purposes, redeploy the Release, but switch off this step.
Is there a standard location on Linux (Ubuntu) to place external config files that a web application (Grails) uses?
UPDATE: Apparently, there is some confusion to my question. The way Grails handles config files is fine. I just want to know if there is a standard location on linux to place configuration files. Similar to how there is a standard for log files (/var/log). If it matters, I'm talking about a production system.
Linux configuration files typically reside in /etc. For example, apache configuration files live in /etc/httpd. Configuration file not associated with standard system packages often live in /usr/local/etc.
So I'd suggest /usr/local/etc/my-grails-app-name/. Beware that this means you can't run two different configurations of the same app on the same server.
I don't believe there is a standard location. You usually define the location for your external config files via the grails.config.locations property in config.groovy.
EDIT
After reading your comment, I suppose the standard locations would be:
Somewhere on the classpath
OR
In the .grails folder in your home directory.
As these are the defaults in config.groovy file.
grails.config.locations = [ "classpath:${appName}-config.properties",
"classpath:${appName}-config.groovy",
"file:${userHome}/.grails/${appName}-config.properties",
"file:${userHome}/.grails/${appName}-config.groovy"]
There's a plugin Standardized external configuration for your app which you might find useful if the grails.config.locations parameter is insufficient.
I am looking at the cruisecontrol web dashboard. I can see one farm and one server. However, I don't see any way to add a project?
Is this something I can do with the UI or do I need to edit the config file by hand?
You'll need to edit the ccnet.config file by hand (located within the CruiseControl directory) to add projects. There are some graphical tools to help you do this however you do get used to doing it by hand fairly quickly - just have the documentation near by!
Update: An example of one such tool is http://www.codeplex.com/ccnetconfig
You can use CCNETConfig to edit the config file through an UI although it doesn't support higher version > CruiseControl.NET 1.4.
You have to basically edit the configuration file by hand, however I have it setup so that the raw config file is split into different include files, each of which is setup in my source control system. Then I created a project for the configuration, and then for the whole config. So when something changes in the config, CC.NET itself pulls out the changes, recreates it's config files and the refreshes the system configuration.
This means that anyone can edit the config (if they can access the files in sourcecontrol), and no-one has to go into the program files directory of the CC.NET machine itself.
Not sure whether this answers the question you asked, but this is how our setup works