Provide an option to not display value for some events?

[voxpupuli]

Provide an option to not display value for some events?

[daenney]

The problem here is that we can't possibly keep a list around of resource types to obfuscate so we'd have to be a whole lot more clever about it.

As far as the user type goes, what I would do instead is generate the hash of the password and pass that in. The formats for /etc/passwd are well documented. This would mediate the issue as seeing the hash will not tell you the password.

Scrubbing the output in Puppetboard still means that the data itself is stored in PuppetDB and others can still query for it though a variety of other tools.

[href]

I face the same issue. As long as you're managing passwords or other sensitive information for something that supports hashed passwords it's fine. But many of our deployments don't have that option. For example, a script sending an e-mail through smtp needs the password in cleartext.

There are ways to work around this issue and I made sure our puppetboard does not support custom queries and can only be accessed using a good password from inside our network, but it still leaves an uneasy feeling.

However, I feel like this is something that should be solved on the Puppet/PuppetDB level. Ideally, one could mark certain properties as sensitive inside of Puppet, which would lead to them not being stored.

[daenney]

Lets see if @kbarber has an idea on the subject because I tend to agree that it's not an issue that should be solved client side. However, I can imagine that not being able to store the entry and retrieve it as such could cause a heap of trouble for other things, exported resources being one.

[stack72]

Just to chime in here, we use hiera-eyaml to encrypt our passwords etc. but the plain text is still kept in puppetdb

[daenney]

Pulling in @senior too.

[senior]

Seems to me the feature that you're wanting (on the PuppetDB side) is a user with a role that omits certain resources (or parameters of a resource). Puppetboard could query as that user and that stuff would be removed before Puppetboard even saw the results.

This is something we have talked about but don't currently have on the roadmap. When I was looking through our tickets, I found an access control ticket, but it's focus was more around walling off environments. I've created a new ticket that we can use to catch the requirements of this feature. I've made a note of this discussion, but feel free to comment if you have additional ideas.

[zoredache]

I wasn't sure if puppetboard was the correct place for this. I am not sure puppetdb is the right place either. I almost wish the individual providers within puppet would have some control over reporting in the resource directly. It sure seems like it would make a lot of sense if the windows_adsi User provider had a way to opt out of providing the new/old values as part of the reports.

daenney: This would mediate the issue as seeing the hash will not tell you the password.

You cannot pre-hash the password when using the windows_adsi provider, the password must be provided as plain text. Plus this was just an example. I have other resources that also reporting values I wish would remain secret, or at least hidden from reports. I was kind of hoping for some kind of generic filter where I could just configure puppetboard to not display values for a given "resource-type". But it also make sense to try working on fixing this as close to the source of the problem as possible first.

[daenney]

You cannot pre-hash the password when using the windows_adsi provider, the password must be provided as plain text.

I know :( and that greatly bothers me. I'd have hoped that by 2014 we would have API's that allowed us to pass in pre-hashed passwords everywhere. Storing passwords in plain text for so many things is a big no no, unfortunately it still applies to systems management.

I was kind of hoping for some kind of generic filter where I could just configure puppetboard to not display values for a given "resource-type".

I'll have a look at how Django does this, perhaps I can shove in some kind of anonymisation middleware that you can configure with a bunch of regexes.

I almost wish the individual providers within puppet would have some control over reporting in the resource directly.

Totally.

[pckroon]

I apologize for my necromancy, but it appears that this will be fixed in puppet. I haven't read through all the bugs/fixes referenced, but maybe it's in a workable state already.
https://tickets.puppetlabs.com/browse/PUP-6433

[juniorsysadmin]

The Sensitive data type is in 4.6.1 , Puppetdb might be oblivious to it though:
https://www.devco.net/archives/2016/09/05/puppet-4-sensitive-data-types.php