Puppet » Facter

Adrien, what are you planning to do here? Just filter out the facts that are sensitive? Filter them out only if the root user is running a process?

Adrien Thebo wrote:

Dan and I discussed the particulars of this a while back, and talked of possibly redacting access passwords or values like that, but it hadn’t been exactly nailed down. I need to get some testing done before I can provide you with more particulars.

This is absolutely a security risk, BUT. The but is: the user supplies this data. We cannot ever know the form of that, or that it contains security sensitive data. The only useful responses we could make are (a) not to have it as a fact at all, disappointing many, or (b) allow the user to make it “not a fact” when they have sensitive data.

There is absolutely no point solving this for CloudFormation only.

(Notably, though, we do treat facts as “public” grade information in much of the rest of the system, making this a potentially broad security exposure.)

Daniel Pittman wrote:

There is absolutely no point solving this for CloudFormation only.

That’s awfully binary Daniel, and I disagree.

If there is a particular piece of EC2 metadata that is always sensitive, is commonly found on EC2 instances, and is never the sort of information one needs to use within Puppet manifests, there is absolutely a point in sanitizing this bit of info for CloudFormation only.

Nigel Kersten wrote:

Daniel Pittman wrote:

There is absolutely no point solving this for CloudFormation only.

That’s awfully binary Daniel, and I disagree.

You are welcome to be wrong. ;)

If there is a particular piece of EC2 metadata that is always sensitive, is commonly found on EC2 instances, and is never the sort of information one needs to use within Puppet manifests, there is absolutely a point in sanitizing this bit of info for CloudFormation only.

I see your point. I am very concerned that we would give a false impression to users who saw this data cleaned up in one case, but then found out that their own use of private data was not equivalently fixed; that creates a complex and invisible mental model that I fear would lead people astray.

OTOH, if there was some rule we could clearly call out or, better, would match user expectations, then I wouldn’t ultimately object…

Having some way to configure that certain facts should not be sent to the master would be an acceptable solution for my use case.

Dan Bode wrote:

Having some way to configure that certain facts should not be sent to the master would be an acceptable solution for my use case.

A configuration option which allows you to specify exclusions is an old discussion. Something that supports masks/wildcards and such? This could be an element in the puppet configuration that decides what is sent to a master. Arguably the problem also appears for mcollective registration as well I suppose, so a facter global configuration is also an option: #11449. (more nobs I know, Daniel).

Daniel Pittman wrote:

I see your point. I am very concerned that we would give a false impression to users who saw this data cleaned up in one case, but then found out that their own use of private data was not equivalently fixed; that creates a complex and invisible mental model that I fear would lead people astray.

You’re arguing that the absence of a particular part of EC2 metadata in Facter will lead to people thinking that their own facts will get automatically sanitized?

One is a data source that facts are generated from. The other is data that users have chosen to be displayed as facts.

The intention is completely different.

In the first case the user is required to put this data into EC2 metadata to make cloud-init work. The user has expressed no intention for this to be in Facter. In the second case the user has expressly intended to make certain data available in Facter.

These are not equivalent.

Ken Barber wrote:

Dan Bode wrote:

Having some way to configure that certain facts should not be sent to the master would be an acceptable solution for my use case.

A configuration option which allows you to specify exclusions is an old discussion. Something that supports masks/wildcards and such?

We have no evidence to date that wildcards are needed, just a plain blacklist to exclude certain facts by name on some clients.

This could be an element in the puppet configuration that decides what is sent to a master. Arguably the problem also appears for mcollective registration as well I suppose, so a facter global configuration is also an option: #11449.

Seems like a justification for configuration over Facter, yup.

Nigel Kersten wrote:

Daniel Pittman wrote:

I see your point. I am very concerned that we would give a false impression to users who saw this data cleaned up in one case, but then found out that their own use of private data was not equivalently fixed; that creates a complex and invisible mental model that I fear would lead people astray.

You’re arguing that the absence of a particular part of EC2 metadata in Facter will lead to people thinking that their own facts will get automatically sanitized?

Oh, no, I must have misunderstood your concerns. I thought you objected to my suggestion that we either ship this data raw, or don’t ship it at all, with the obvious conclusion being that sanitation – stripping the password only – would be the right thing to do. That model, where we clean some security related data, concerns me.

If we don’t ship this data at all, or give the user the knobs to not ship it, then I have no problem at all, and the user has a simple and clear model.

I would prefer something like the blacklist option, so that this can apply to the, eg, Rackspace or OpenStack, or VMWare equivalent data as well, but just excluding the one fact from core would satisfy my concerns.

excellent :) I totally agree that stripping the password only would not make sense. We don’t ship that bit of data at all.

I wouldn’t mind a blacklist model either, but I don’t think it’s a strict requirement at this stage.