Facts can override variables set by puppet master

[Boyan Tabakov]

Hi,

The puppet master sets several global variables, including $environment,
$serverip, etc
(http://docs.puppetlabs.com/puppet/latest/reference/lang_facts_and_builtin_vars.html).
However, looks like client facts with the same names can mask out these
variables. How can one determine reliably the current environment inside
a manifest/module?

I'd consider this an issue, for example, because with puppet 3+ the
environment set by ENC is authoritative and may differ from the
client-set environment and/or client fact with name 'environment'.

Thanks!

BR,
Boyan

[José Luis Ledesma]

you can use the Full qualified variable name like

::class_name::variable

Regards,

[Boyan Tabakov]

Hi,

The variable I want to access is not defined in a module/class. It's the
globally defined $::environment. Since facts are also exposed as global
variables, the server-defined $::environment gets overridden when
there's a fact with the same name.

So any ideas on how to avoid that? As it is, it looks like a module
can't reliably detect environment, because a (potentially malicious)
client can send an 'environment' fact with arbitrary value.

Thanks,
Boyan

On 9.5.2014, 18:52, José Luis Ledesma wrote:
> you can use the Full qualified variable name like
>
> ::class_name::variable
>
> Regards,
>
> El 09/05/2014 13:15, "Boyan Tabakov" <bl...@alslayer.net

> <mailto:bl...@alslayer.net>> escribió:

>
> Hi,
>
> The puppet master sets several global variables, including $environment,
> $serverip, etc
> (http://docs.puppetlabs.com/puppet/latest/reference/lang_facts_and_builtin_vars.html).
> However, looks like client facts with the same names can mask out these
> variables. How can one determine reliably the current environment inside
> a manifest/module?
>
> I'd consider this an issue, for example, because with puppet 3+ the
> environment set by ENC is authoritative and may differ from the
> client-set environment and/or client fact with name 'environment'.
>
> Thanks!
>
> BR,
> Boyan
>

> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to puppet-users...@googlegroups.com
> <mailto:puppet-users...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CAF_B3dceUO64PTQ0_tcVP2Vg9QDMHy1kqkRHjqfuoGP_DLR4tw%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CAF_B3dceUO64PTQ0_tcVP2Vg9QDMHy1kqkRHjqfuoGP_DLR4tw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[jcbollinger]

On Monday, May 19, 2014 6:06:45 AM UTC-5, Boyan Tabakov wrote:

Hi,

The variable I want to access is not defined in a module/class. It's the
globally defined $::environment. Since facts are also exposed as global
variables, the server-defined $::environment gets overridden when
there's a fact with the same name.

So any ideas on how to avoid that? As it is, it looks like a module
can't reliably detect environment, because a (potentially malicious)
client can send an 'environment' fact with arbitrary value.

If you do not trust your nodes to specify their own environment, then you should set up an ENC that specifies the correct environment for each node to Puppet.  That can be the only thing it does.  The environment specified by an ENC will be used instead of the one (if any) specified by the agent.

More generally, you should avoid declaring global variables in your Puppet manifests, and especially you should avoid declaring globals that collide with facts or with variables provided by the master itself.  Such collisions should cause catalog compilation to fail with an error message, but conceivably could fail silently instead.  Puppet variables cannot be changed once set.


John

[Boyan Tabakov]

Hi,

On Mon May 19 16:39:25 2014, jcbollinger wrote:
>
>
> On Monday, May 19, 2014 6:06:45 AM UTC-5, Boyan Tabakov wrote:
>
> Hi,
>
> The variable I want to access is not defined in a module/class.
> It's the
> globally defined $::environment. Since facts are also exposed as
> global
> variables, the server-defined $::environment gets overridden when
> there's a fact with the same name.
>
> So any ideas on how to avoid that? As it is, it looks like a module
> can't reliably detect environment, because a (potentially malicious)
> client can send an 'environment' fact with arbitrary value.
>
>
>
> If you do not trust your nodes to specify their own environment, then
> you should set up an ENC that specifies the correct environment for
> each node to Puppet. That can be the only thing it does. The
> environment specified by an ENC will be used instead of the one (if
> any) specified by the agent.
>
> More generally, you should avoid declaring global variables in your
> Puppet manifests, and especially you should avoid declaring globals
> that collide with facts or with variables provided by the master

> itself. Such collisions /should/ cause catalog compilation to fail

> with an error message, but conceivably could fail silently instead.
> Puppet variables cannot be changed once set.

That is exactly what I try to do.

Still, this is what happens (puppetmaster 3.5.1, puppet agent 3.4.3):

Agent's configured environment is "agent_env". Agent also has a fact
called "environment" with value "agent_env_fact". There is ENC,
enforcing environment for that node to be "enc_env". The node's catalog
gets compiled in the "enc_env", as it should. For example the node
reports:

Local environment: "agent_env" doesn't match server specified node
environment "enc_env", switching agent to "enc_env".

However if any of the modules use the $::environment variable, it's
value is "agent_env_fact". So the agent's fact masks the real value and
any modules/manifests that make decisions based on the environment can
be fooled.

This means that any conditionals that are based on $::environment are
not reliable. It would be totally fine, if that's documented and people
are discouraged to use the $::environment variable, but I could not
find anything like that. So, my original question still stands: is
there a reliable way to find out the current node's environment in a
module/manifest?

Cheers,
Boyan

[José Luis Ledesma]

But, who can run puppet?

I mean, most puppet configurations needs root, so if someone malicious is a root which is the point of being able to cheat the environment? He can do whatever wants.

Regards,

[Henrik Lindberg]

This suggests a design that is somewhat inside-out, the idea is that
what is *in* the environment defines what you want, not that you inside
the environment make decisions based on the name of the environment.

Typically, you benefit from setting up special environments when
developing and testing and it becomes a horrible problem when the
modules themselves have to be aware of an environment naming scheme.

Or put differently, logic inside your environment should not care what
the name of the environment is.

- henrik

--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

[jcbollinger]

Per the docs, the $::environment variable should do what you want.  That it is not doing so is a bug (at minimum, it is a documentation bug, but I think the behavior is wrong).  I recommend you file a ticket.  I'm afraid I don't have a workaround to offer.


John

[jcbollinger]

On Tuesday, May 20, 2014 7:36:31 AM UTC-5, Henrik Lindberg wrote:

This suggests a design that is somewhat inside-out, the idea is that
what is *in* the environment defines what you want, not that you inside
the environment make decisions based on the name of the environment.

Agreed, and therein may be the workaround that I couldn't come up with.

Nevertheless, the observed value of $::environment differs from what the docs say it should be in the OP's case.  The only plausible reason for Puppet to provide the $::environment variable at all is so that its value can influence catalog building, whether directly in manifests or by interpolation into hiera hierarchy definitions, or whatever.  It's not reasonable to say the variable shouldn't be used according to its docs for its apparent intended purpose.

John

[jcbollinger]

On Tuesday, May 20, 2014 6:55:31 AM UTC-5, Jose Luis Ledesma wrote:

But, who can run puppet?

I mean, most puppet configurations needs root, so if someone malicious is a root which is the point of being able to cheat the environment? He can do whatever wants.

Yes, generally speaking, if the target node is compromised so that an attacker can compromise the node facts sent to the master, then the attacker can modify the node as he wants without going through Puppet.  Mandatory access controls (e.g. SELinux) can factor into that, but the real risk here is that by spoofing the puppet environment, the attacker might be able to extract information about the organization that otherwise would not be available from the compromised node.  In some cases, he might also be able to cause damage or interfere with operations.

Generally, I'm inclined to say that sites employing environments should always assign nodes to environments centrally, rather than by relying on agents to declare their own.


John

[Boyan Tabakov]

Exactly. As suggested, I'll open a bug report and see what opinions will
there be.