Hacker News new | ask | show | jobs
by yodon 3811 days ago
it's a huge pain point for us. We're a .NET shop rolling our own that mimics/overlays app.config and web.config patterns for both dev and production usage. Our concern is less on how do you get the secrets to the box (though that's obviously important) and more on how do you keep an attacker who has started penetrating your infrastructure from gaining control of the infrastructure that holds your secrets.
2 comments
voltagex_ 3811 days ago
Have you had a look at the new ASP.NET Configuration classes? [1]

I hate having to manage web.config but I get your point about keeping attackers at bay (and not providing pivot points).

[1]: http://docs.asp.net/en/latest/fundamentals/configuration.htm...

link
yodon 3811 days ago
Thanks - it's clear MSFT is working hard to get to a place where secret management is a first class part of the dev process and we're attempting to integrate with the classes you mention but as I understand it they only work with ASP.NET 5 so you can't use them in console app based test harnesses or Windows services or etc. That means we end up needing to have a bunch of provider mechanisms, all essentially the same in principle but with different implementations for the different platform details. If it's not super easy for the dev to drop into a quick test app, they'll "just copy and paste the secrets for now" which is always the path to darkness.
link
dsp1234 3811 days ago
It's 100% possible to use the new ConfigurationBuilder class outside of a asp.net site (like a console application). ex: http://stackoverflow.com/questions/31885912/how-to-read-valu...
link
voltagex_ 3811 days ago
Maybe a local (LAN?) NuGet feed with your preferred mechanism would help with the dev experience? You could even go as far as deploying custom templates. I don't think the new Configuration classes are limited to ASP.NET any more - and from the response I got on the issue tracker, if you find any hard dependencies report them as a bug.
link
kkamperschroer 3811 days ago
That's very similar to the problem we are encountering. Getting the secrets to the machines at deploy time isn't too bad, but then they are available to a potential attacker.

Accessing secrets as needed at runtime instead requires some kind of extremely reliable service nearby. This is what I find most concerning about Vault since it can lock on you if the cluster goes down.

link