So yeah, you probably don't want to filter resources per se, but parameters of resources I believe.
So lets take about that possibility first:
So ... hiera-eyaml knows what fields are encrypted or not ... can you see a way to let Puppet know this information as well somehow? I'm guessing not - because hiera is just a big bag of variables that can be accessed using a function then that value gets passed around ... unless people specifically follow hiera/class creation patterns explicitly perhaps ...
Still - it could be that in the class/resource/ruby type & provider we are able to mark fields as sensitive through the DSL (and type .rb file for the ruby type part). This would be a more mid/long-term solution perhaps.
That would certainly save having to build up a completely different list of resources/parameter combinations that we have to exclude/whatever somewhere else.
To explain Nick Walker why I'm going on about this ... one of the concerns I have about this is that the whole mechanism for deciding what to encode becomes an action-at-a-distance anti-pattern. It just becomes very easy for someone to encrypt something new in hiera-eyaml, but forget to put it in some static list that we create for this purpose thus exposing themselves accidentally ...
Another perspective is also like anonymization does to some degree, whereby its not just a 'list' of items, but there is support for general regexp matching for things that fall through, check out how this works in that code for example:
https://github.com/puppetlabs/puppetdb/blob/master/src/puppetlabs/puppetdb/cli/anonymize.clj#L69-L70
So here we just presume anything that matches 'password-like' words gets anon'd by default (that is anything matching: /password/, /pwd/, /secret/, /key/ or /private/), anything above and beyond that would need manual specification. This probably is reasonable bet ... having said that, it might wipe too much which is not great, we'd have to leave that kind of thing configurable.
This other problem here - is that some passwords do want to be exported and collected. How would you see us handling that case? We know what resources are 'exported' already, do we need different policies for exported stuff versus non-exported.
Going back to your 'tag' filtering idea ...
This becomes a filter on resources then - and then perhaps we add a way to pass a list of tags. Now I'm going to say straight up this is going to break the catalog graph if we remove a resource like this. I don't think we can just reconnect these edges to something else to fake this. If we just remove the resource, we'll have to do something about that loss of connectivity otherwise tools like catalog view, catalog diff, all the magical stuff we are doing with catalogs in PE basically.
Another idea is perhaps we want to retain the resource and just perhaps clear all its parameters or something like that. So yeah, we could just wipe the parameters in that case instead, or wipe the values only, retaining the 'keys'. This all sounds a bit icky, right? Or is it just me?
Henrik Lindberg - a penny for your thoughts perhaps ... I'm curious if this "type" of solution would double up as a solution for any other problems you've heard of relating to security/sensitivity. That is, has this kind of thing come up before - that you know of?
|
. Thats not my point, it's just that the problems are related - ie. field sensitivity would be great to know at the schema level for both problems, instead of trying to match it much later. There is a proper solution sitting here, I'd sleep better if we knew what that was, even if the short term was something dodgy. Creating a list of resources & parameters that must be filtered is certainly one solution though.
