Hacker News new | past | comments | ask | show | jobs | submit login

The problem with configuration expressed as a code is that it is not automatically auditable. With simple ini or json files, the auditing tool can just parse them, or, even worse, grep, and find out if a particular option has a certain legally-mandated value. This also applies to configuration files generated via templating - you just feed the end result to the auditing tool. With the code, the auditing tool would need to run the code, and this is a no-no from a security perspective.



If you need this, you can split your application in two parts: one which creates the objects, then these objects are serialised to a 'configuration file formats' which can be audited and then used by the 'real' application.

IMHO this kind of audit is useless because even if one option has the expected value what guarantees do you have that this option is used as expected? Well you have to audit the code!


I think it's better in any case to pull the config values from your actual live resources in some sort of read-only view.

This is the only way to be sure you're auditing what you think you're auditing, and it doesn't matter what kind of provisioning tool you've used.


Configuration languages typically produce a json/protobuf/thrift/etc serialization (if designed well that is) so just audit that.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: