[Puppet Users] 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



signature.asc
Description: OpenPGP digital signature

Re: [Puppet Users] Facts can override variables set by puppet master

[José Luis Ledesma]

you can use the Full qualified variable name like

::class_name::variable

Regards,
El 09/05/2014 13:15, "Boyan Tabakov"  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+unsubscr...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Facts can override variables set by puppet master

[Laurent CREPET]

The master stores the configuration for the nodes it manages. When
requested by a node (agent), it compiles the manifests for this node and
send it to the node.

You should probably post in english. I'm answering after using google
translate on your message.

-- Laurent.


-- Laurent.
Le 9 mai 2014 17:52, "José Luis Ledesma"  a
écrit :

> you can use the Full qualified variable name like
>
> ::class_name::variable
>
> Regards,
> El 09/05/2014 13:15, "Boyan Tabakov"  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+unsubscr...@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
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAL4DqqxrsbbRpKRJcP9CsQps0z1bm2gKpCY2qd_TaBAOfi8hsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Facts can override variables set by puppet master

[Laurent CREPET]

Sorry, replying To wrong message.

-- Laurent.
Le 9 mai 2014 19:16, "Laurent CREPET"  a écrit :

> The master stores the configuration for the nodes it manages. When
> requested by a node (agent), it compiles the manifests for this node and
> send it to the node.
>
> You should probably post in english. I'm answering after using google
> translate on your message.
>
> -- Laurent.
>
>
> -- Laurent.
> Le 9 mai 2014 17:52, "José Luis Ledesma"  a
> écrit :
>
>> you can use the Full qualified variable name like
>>
>> ::class_name::variable
>>
>> Regards,
>> El 09/05/2014 13:15, "Boyan Tabakov"  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+unsubscr...@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
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAL4DqqxkqjNU_%2B_u0cr_w8zLvh-HNZkX1kqsVSLq24diTaZ7OA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Facts can override variables set by puppet master

[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"  > 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+unsubscr...@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
> .
> For more options, visit https://groups.google.com/d/optout.




signature.asc
Description: OpenPGP digital signature

Re: [Puppet Users] Facts can override variables set by puppet master

[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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/af02d5fa-d002-4950-bfa4-7ce63b8de981%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Facts can override variables set by puppet master

[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




signature.asc
Description: OpenPGP digital signature

Re: [Puppet Users] Facts can override variables set by puppet master

[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,
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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAF_B3ddWV5zqoKMOfaY9PSjwo-h9ETD-pg%3DUJV_19K8P4CbhYg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Facts can override variables set by puppet master

[Henrik Lindberg]

On 2014-20-05 13:02, Boyan Tabakov wrote:

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?

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/

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/llfi8f%24e9n%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Facts can override variables set by puppet master

[jcbollinger]

On Tuesday, May 20, 2014 6:02:17 AM UTC-5, Boyan Tabakov wrote:
>
> 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? 
>
>

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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/5d5a4d3e-6ecb-49af-8744-b6d6ffa41a4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Facts can override variables set by puppet master

[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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/c8980729-9066-4490-9720-7dc65fd773d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Facts can override variables set by puppet master

[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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/fe0e28a3-bdcd-43ff-9ea5-d1fb6877a8b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Facts can override variables set by puppet master

[Boyan Tabakov]

On 20.5.2014, 17:05, jcbollinger wrote:
> 
> 
> 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.
> 
> 

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



signature.asc
Description: OpenPGP digital signature