Re: [Puppet Users] Facts can override variables set by puppet master
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
Re: [Puppet Users] Facts can override variables set by puppet master
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
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+unsubscr...@googlegroups.com mailto: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 https://groups.google.com/d/msgid/puppet-users/CAF_B3dceUO64PTQ0_tcVP2Vg9QDMHy1kqkRHjqfuoGP_DLR4tw%40mail.gmail.com?utm_medium=emailutm_source=footer. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
[Puppet Users] Facts can override variables set by puppet master
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] Re: Module structure for case-specific configuration
On 16.4.2013 16:30, jcbollinger wrote: [... which carries maintenance costs typical of such boilerplate repetition.] It sounds to me like requiring an explicit declaration for each project class is the way to go. As I said already, however, that's entirely unrelated to the question of avoiding repetitive declaration patterns. You might be able to use collections to solve this problem. Proceed carefully, as Puppet has at times had issues with collecting classes (as opposed to ordinary resources), but the basic idea would be for Class['apache'] to contain something along these lines: Class['apache::config'] - Class| tag == 'apache::project' | ~ Class['apache::service'] That way, you have the needed relationship declarations in one central place. It should not cause project classes that you have not otherwise declared to be declared, and I don't think it will be sensitive to the order of your declarations. You will probably find that you need to tweak that somewhat to get it to work is you want, however. You might find that it helps to require each (top) project class to explicitly tag itself with some well-known tag. Thanks! That sounds good. Will try it out. BR, Boyan signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Re: Module structure for case-specific configuration
Hi John, Thanks for your reply! On 15.4.2013 18:02, jcbollinger wrote: Single point of entry does not serve well and is not a particularly useful goal when the desired results are very divergent. The single declaration then becomes magical, and therefore difficult to understand and maintain. That makes sense. I think your specific case is even more distinguished than that, however: it sounds like you are inappropriately modeling web /site/ components (i.e. content) as part of the web /server/. I would pull the projects out as completely separate modules (and that could restore your single point of entry, on a per-module basis). Yes, your project modules might need to declare some relationships, but that is in no way a function of which module contains each class. It is not website related components, but indeed web-server - vhost definitions, special apache configuration files (e.g. module configuration overrides, etc). Besides, the apache was just an example, I have other cases where similar setup is required. In any case, the project-specific definitions are *only* for resources, directly related to the module in question (in this case, apache). Note also that you should /not/ be using subclasses for any of what you described. It's not clear whether you actually are doing so, despite your use of the term, but Puppet class inheritance is a very special- (and limited-)purpose tool that does not apply to any of the needs you described. It looks like you may simply be putting some classes in others' namespaces, however, and that's an /entirely/ different thing. Pardon my wording. By subclasses, I just meant a class inside some module (apache::projectX). No inheritance involved. If single point of entry can be avoided, then what do you think about the second part of my question? : The easy solution seems to be to forget about single point of entry and include from manifests both the apache and the apache::projectX classes with appropriate parameters. However, in order to ensure proper sequencing all the apache::projectX classes might need to contain some code like this: Class['apache::config'] - Class['apache::projectX'] ~ Class['apache::service'] I don't like the idea of having this in all project-specific classes, as modification of the module structure might become more difficult - i.e. will need to change all the apache:projectX classes if I want to add, let's say, a apache::modules class that needs to load before the projectX. BR, Boyan signature.asc Description: OpenPGP digital signature
[Puppet Users] Module structure for case-specific configuration
Hi all, Let's consider the following situation: I use the module structure, proposed by R.I.Pienaar: http://www.devco.net/archives/2012/12/13/simple-puppet-module-structure-redux.php I have a module, let's say apache, that follows that pattern for installing and setting up basic apache server. However, I also want to have a way to provide extra configuration for specific use-cases. Let's call these projects. So for each project, we want to have some additional class apache::projectX that performs these additional tasks (e.g. deploys more specific template, defines more file resources, etc, etc). My question is this: if I want to stick with a single point of entry to the module (i.e. manifests include just apache module with some parameter), what's the best way to go considering that each project subclass may have its own set of parameters? Defining all these parameters on the apache class itself, doesn't sound like a good idea. Perhaps, defining them in Hiera as apache::projetX::parameterY? The easy solution seems to be to forget about single point of entry and include from manifests both the apache and the apache::projectX classes with appropriate parameters. However, in order to ensure proper sequencing all the apache::projectX classes might need to contain some code like this: Class['apache::config'] - Class['apache::projectX'] ~ Class['apache::service'] I don't like the idea of having this in all project-specific classes, as modification of the module structure might become more difficult - i.e. will need to change all the apache:projectX classes if I want to add, let's say, a apache::modules class that needs to load before the projectX. Any thoughts on a best practice in similar situations? Regards, Boyan signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Re: Security considerations for basing decisions on facts
On 22.1.2013 23:04, jcbollinger wrote: You are correct that that only the identity of the client node is authenticated by Puppet, and even that only insomuch as the client can be relied upon to protect its SSL certificate. The $hostname fact cannot be relied upon to convey that information, as it doesn't in any sense need to be the same thing; you're looking for $certname. It is, however, $certname (not $hostname) by which a node block is selected and/or an ENC queried, so Puppet's architectural foundation is secure in that regard. You are also right that a compromised client can, in principle, falsify the fact values presented to the master in an attempt to make it divulge secret information. Whether the master might actually divulge anything is a function of the manifests with which site administration has configured it. In other words, that's a question of how Puppet is used, not of the fundamental security of Puppet itself. To the extent that you want to record server-side node data, I think hiera is the way to go. I prefer that to encoding data in an ENC or in your manifests, but those are some of the other options. All of those are secure to the extent that the master itself is secure, though I wouldn't say that any of them were designed specifically as a secure alternative to node facts. Hello, Yes, I agree it is a problem of the usage, rather than puppet itself. Thanks for the confirmation! Best regards, Boyan signature.asc Description: OpenPGP digital signature
[Puppet Users] Security considerations for basing decisions on facts
Hello,
Let's consider the scenario when a client node in a puppet environment
gets compromised.
In case some of the puppet modules make decisions based on agent facts,
these modules are potentially exposed to abuse from the malicious puppet
agent.
For example, if a class has:
if $some_fact == 'some value' {
# deploy some configuration
}
then the compromised node could send falsified value of that fact to
obtain configuration that potentially contains secrets (private keys,
passwords, etc) that was meant only for other nodes.
AFAIK, the only authenticated piece of information that a puppet agent
passes to the puppetmaster server is the name of the node, as specified
in the SSL certificate for the agent. However, the value of $fqdn, as
seen in a manifest / class on the puppetmaster seems to be based on the
agent-supplied fact 'fqdn'.
Having said that, then can the value of $hostname be trusted to come
from the identity in the agent's SSL certificate? What are best
practices for ensuring that a compromised agent can't access
configuration meant for different nodes?
Are an ENC or external data sources (Hiera) designed to provide trusted
puppetmaster-side metadata for nodes? Is that the way to go?
Thanks in advance!
Best regards,
Boyan Tabakov
signature.asc
Description: OpenPGP digital signature
