The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #11031

capturing ec2 userdata as a fact may be a security risk

Added by Dan Bode almost 3 years ago. Updated almost 2 years ago.

Status:InvestigatingStart date:11/23/2011
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-
Keywords: Affected Facter version:
Branch:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket may be automatically exported to the FACT project on JIRA using the button below:


Description

When cloud-init is used for bootstrapping nodes, a script contained in the userdata is often passed to the node to perform bootstrapping.

In the case of cloud formation, this script often contains IAM credentials (access code/secret code) that are used to call cfn-init.

In my integration of PE with cloudformation, I can see the AWS credentials in the inventory service when running b/c they are captured as a part of the ec2 metadata.

This is not that big of a deal for my use case b/c the credentials only refer to a temporary account that only has the permissions to read metadata from cloudformation instances.

In general, I have concerns over rather capturing userdata with facter may potentially (and unexpectedly) expose a user’s credentials in some cases.

Screen_shot_2011-11-23_at_10.22.27_AM.png (257 KB) Dan Bode, 11/23/2011 10:55 am


Related issues

Blocked by Facter - Feature #11449: Facter should have a configuration file Needs Decision 12/16/2011

History

#1 Updated by Adrien Thebo almost 3 years ago

  • Status changed from Unreviewed to Accepted
  • Assignee set to Adrien Thebo
  • Target version set to 144

#2 Updated by Nigel Kersten over 2 years ago

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?

#3 Updated by Adrien Thebo over 2 years ago

  • Status changed from Accepted to Investigating

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.

#4 Updated by Anonymous over 2 years ago

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.)

#5 Updated by Nigel Kersten over 2 years ago

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.

#6 Updated by Anonymous over 2 years ago

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…

#7 Updated by Dan Bode over 2 years ago

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

#8 Updated by Ken Barber over 2 years ago

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).

#9 Updated by Nigel Kersten over 2 years ago

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.

#10 Updated by Anonymous over 2 years ago

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.

#11 Updated by Anonymous over 2 years ago

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.

#12 Updated by Nigel Kersten over 2 years ago

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.

#13 Updated by Adrien Thebo over 2 years ago

  • Assignee deleted (Adrien Thebo)

#14 Updated by Jeff Weiss over 2 years ago

  • Target version deleted (144)

#15 Updated by Patrick Hemmer almost 2 years ago

Chiming in here as there is another reason for wanting to exclude certain facts.
EC2 allows you to provide binary data for userdata (ie; gzip). This generates 2 problems:

  1. If you ever run facter, you will have this binary data dumped to your terminal which can mess it up (or in some rare scenario, cause your terminal to send something back and run a bad command).
  2. This binary data gets sent to puppetdb which triggers bug #15903

#16 Updated by Nigel Kersten almost 2 years ago

That sounds like a slightly different issue, where we shouldn’t ever try and deal with binary data?

Also available in: Atom PDF