Re: [openstack-dev] [tripleo] [tripleo-validations] using using top-level fact vars will deprecated in future Ansible versions
> so if, for convenience, we do this:
> vars:
> a_mounts: "{{ hostvars[inventory_hostname].ansible_facts.mounts }}"
>
> That's completely acceptable and correct, and won't create any security
> issue, right?
Yes, that will work, but you don't need to use the hostvars dict. You can
simply use ansible_facts.mounts.
Using facts in no way creates security issues. The attack vector is a managed
node setting local facts, or a malicious playbook author setting a fact that
contains executable and malicious code. Ansible uses an UnsafeProxy class to
ensure text from untrusted sources is properly handled to defend against this.
> I think the last thing we want is to break TripleO + Ceph integration so we
> will maintain Ansible 2.5.x in TripleO Rocky and upgrade to 2.6.x in Stein
> when ceph-ansible 3.2 is used and working well.
This sounds like a good plan.
---
Respectfully,
Sam Doran
Senior Software Engineer
Ansible by Red Hat
sdo...@redhat.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] [tripleo-validations] using using top-level fact vars will deprecated in future Ansible versions
On Thu, Jul 26, 2018 at 12:30 PM John Fulton wrote: > Do we have a plan for which Ansible version might be the default in > upcoming TripleO versions? > > If this is the thread to discuss it then, I want to point out that > TripleO's been using ceph-ansible for Ceph integration on the client > and server side since Pike and that ceph-ansible 3.1 (which TripleO > master currently uses) fails on Ansible 2.6 and that this won't be > addressed until ceph-ansible 3.2. > I think the last thing we want is to break TripleO + Ceph integration so we will maintain Ansible 2.5.x in TripleO Rocky and upgrade to 2.6.x in Stein when ceph-ansible 3.2 is used and working well. Hope it's fine for everyone, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] [tripleo-validations] using using top-level fact vars will deprecated in future Ansible versions
On Thu, Jul 26, 2018 at 1:48 AM Cédric Jeanneret wrote:
>
> Hello Sam,
>
> Thanks for the clarifications.
>
> On 07/25/2018 07:46 PM, Sam Doran wrote:
> > I spoke with other Ansible Core devs to get some clarity on this change.
> >
> > This is not a change that is being made quickly, lightly, or without a
> > whole of bunch of reservation. In fact, that PR created by agaffney may
> > not be merged any time soon. He just wanted to get something started and
> > there is still ongoing discussion on that PR. It is definitely a WIP at
> > this point.
> >
> > The main reason for this change is that pretty much all of the Ansible
> > CVEs to date came from "fact injection", meaning a fact that contains
> > executable Python code Jinja will merrily exec(). Vars, hostvars, and
> > facts are different in Ansible (yes, this is confusing — sorry). All
> > vars go through a templating step. By copying facts to vars, it means
> > facts get templated controller side which could lead to controller
> > compromise if malicious code exists in facts.
> >
> > We created an AnsibleUnsafe class to protect against this, but stopping
> > the practice of injecting facts into vars would close the door
> > completely. It also alleviates some name collisions if you set a hostvar
> > that has the same name as a var. We have some methods that filter out
> > certain variables, but keeping facts and vars in separate spaces is much
> > cleaner.
> >
> > This also does not change how hostvars set via set_fact are referenced.
> > (set_fact should really be called set_host_var). Variables set with
> > set_fact are not facts and are therefore not inside the ansible_facts
> > dict. They are in the hostvars dict, which you can reference as {{
> > my_var }} or {{ hostvars['some-host']['my_var'] }} if you need to look
> > it up from a different host.
>
> so if, for convenience, we do this:
> vars:
> a_mounts: "{{ hostvars[inventory_hostname].ansible_facts.mounts }}"
>
> That's completely acceptable and correct, and won't create any security
> issue, right?
>
> >
> > All that being said, the setting to control this behavior as Emilien
> > pointed out is inject_facts_as_vars, which defaults to True and will
> > remain that way for the foreseeable future. I would not rush into
> > changing all the fact references in playbooks. It can be a gradual process.
> >
> > Setting inject_facts_as_vars toTrue means ansible_hostname becomes
> > ansible_facts.hostname. You do not have to use the hostvars dictionary —
> > that is for looking up facts about hosts other than the current host.
> >
> > If you wanted to be proactive, you could start using the ansible_facts
> > dictionary today since it is compatible with the default setting and
> > will not affect others trying to use playbooks that reference ansible_facts.
> >
> > In other words, with the default setting of True, you can use either
> > ansible_hostname or ansible_facts.hostname. Changing it to False means
> > only ansible_facts.hostname is defined.
> >
> >> Like, really. I know we can't really have a word about that kind of
> >> decision, but... damn, WHY ?!
> >
> > That is most certainly not the case. Ansible is developed in the open
> > and we encourage community members to attend meetings
> > and
> > add
> > topics to the agenda
> > for discussion.
> > Ansible also goes through a proposal process for major changes, which
> > you can view here
> > .
> >
> > You can always go to #ansible-devel on Freenode or start a discussion on
> > the mailing list
> > to speak with
> > the Ansible Core devs about these things as well.
>
> And I also have the "Because" linked to my "why" :). big thanks!
Do we have a plan for which Ansible version might be the default in
upcoming TripleO versions?
If this is the thread to discuss it then, I want to point out that
TripleO's been using ceph-ansible for Ceph integration on the client
and server side since Pike and that ceph-ansible 3.1 (which TripleO
master currently uses) fails on Ansible 2.6 and that this won't be
addressed until ceph-ansible 3.2.
John
>
> Bests,
>
> C.
>
> >
> > ---
> >
> > Respectfully,
> >
> > Sam Doran
> > Senior Software Engineer
> > Ansible by Red Hat
> > sdo...@redhat.com
> >
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> --
> Cédric Jeanneret
> Software Engineer
> DFG:DF
>
> __
> OpenStack Development Mailing List (not for usage
Re: [openstack-dev] [tripleo] [tripleo-validations] using using top-level fact vars will deprecated in future Ansible versions
Hello Sam,
Thanks for the clarifications.
On 07/25/2018 07:46 PM, Sam Doran wrote:
> I spoke with other Ansible Core devs to get some clarity on this change.
>
> This is not a change that is being made quickly, lightly, or without a
> whole of bunch of reservation. In fact, that PR created by agaffney may
> not be merged any time soon. He just wanted to get something started and
> there is still ongoing discussion on that PR. It is definitely a WIP at
> this point.
>
> The main reason for this change is that pretty much all of the Ansible
> CVEs to date came from "fact injection", meaning a fact that contains
> executable Python code Jinja will merrily exec(). Vars, hostvars, and
> facts are different in Ansible (yes, this is confusing — sorry). All
> vars go through a templating step. By copying facts to vars, it means
> facts get templated controller side which could lead to controller
> compromise if malicious code exists in facts.
>
> We created an AnsibleUnsafe class to protect against this, but stopping
> the practice of injecting facts into vars would close the door
> completely. It also alleviates some name collisions if you set a hostvar
> that has the same name as a var. We have some methods that filter out
> certain variables, but keeping facts and vars in separate spaces is much
> cleaner.
>
> This also does not change how hostvars set via set_fact are referenced.
> (set_fact should really be called set_host_var). Variables set with
> set_fact are not facts and are therefore not inside the ansible_facts
> dict. They are in the hostvars dict, which you can reference as {{
> my_var }} or {{ hostvars['some-host']['my_var'] }} if you need to look
> it up from a different host.
so if, for convenience, we do this:
vars:
a_mounts: "{{ hostvars[inventory_hostname].ansible_facts.mounts }}"
That's completely acceptable and correct, and won't create any security
issue, right?
>
> All that being said, the setting to control this behavior as Emilien
> pointed out is inject_facts_as_vars, which defaults to True and will
> remain that way for the foreseeable future. I would not rush into
> changing all the fact references in playbooks. It can be a gradual process.
>
> Setting inject_facts_as_vars toTrue means ansible_hostname becomes
> ansible_facts.hostname. You do not have to use the hostvars dictionary —
> that is for looking up facts about hosts other than the current host.
>
> If you wanted to be proactive, you could start using the ansible_facts
> dictionary today since it is compatible with the default setting and
> will not affect others trying to use playbooks that reference ansible_facts.
>
> In other words, with the default setting of True, you can use either
> ansible_hostname or ansible_facts.hostname. Changing it to False means
> only ansible_facts.hostname is defined.
>
>> Like, really. I know we can't really have a word about that kind of
>> decision, but... damn, WHY ?!
>
> That is most certainly not the case. Ansible is developed in the open
> and we encourage community members to attend meetings
> and add
> topics to the agenda
> for discussion.
> Ansible also goes through a proposal process for major changes, which
> you can view here
> .
>
> You can always go to #ansible-devel on Freenode or start a discussion on
> the mailing list
> to speak with
> the Ansible Core devs about these things as well.
And I also have the "Because" linked to my "why" :). big thanks!
Bests,
C.
>
> ---
>
> Respectfully,
>
> Sam Doran
> Senior Software Engineer
> Ansible by Red Hat
> sdo...@redhat.com
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Cédric Jeanneret
Software Engineer
DFG:DF
signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] [tripleo-validations] using using top-level fact vars will deprecated in future Ansible versions
I spoke with other Ansible Core devs to get some clarity on this change.
This is not a change that is being made quickly, lightly, or without a whole of
bunch of reservation. In fact, that PR created by agaffney may not be merged
any time soon. He just wanted to get something started and there is still
ongoing discussion on that PR. It is definitely a WIP at this point.
The main reason for this change is that pretty much all of the Ansible CVEs to
date came from "fact injection", meaning a fact that contains executable Python
code Jinja will merrily exec(). Vars, hostvars, and facts are different in
Ansible (yes, this is confusing — sorry). All vars go through a templating
step. By copying facts to vars, it means facts get templated controller side
which could lead to controller compromise if malicious code exists in facts.
We created an AnsibleUnsafe class to protect against this, but stopping the
practice of injecting facts into vars would close the door completely. It also
alleviates some name collisions if you set a hostvar that has the same name as
a var. We have some methods that filter out certain variables, but keeping
facts and vars in separate spaces is much cleaner.
This also does not change how hostvars set via set_fact are referenced.
(set_fact should really be called set_host_var). Variables set with set_fact
are not facts and are therefore not inside the ansible_facts dict. They are in
the hostvars dict, which you can reference as {{ my_var }} or {{
hostvars['some-host']['my_var'] }} if you need to look it up from a different
host.
All that being said, the setting to control this behavior as Emilien pointed
out is inject_facts_as_vars, which defaults to True and will remain that way
for the foreseeable future. I would not rush into changing all the fact
references in playbooks. It can be a gradual process.
Setting inject_facts_as_vars to True means ansible_hostname becomes
ansible_facts.hostname. You do not have to use the hostvars dictionary — that
is for looking up facts about hosts other than the current host.
If you wanted to be proactive, you could start using the ansible_facts
dictionary today since it is compatible with the default setting and will not
affect others trying to use playbooks that reference ansible_facts.
In other words, with the default setting of True, you can use either
ansible_hostname or ansible_facts.hostname. Changing it to False means only
ansible_facts.hostname is defined.
> Like, really. I know we can't really have a word about that kind of decision,
> but... damn, WHY ?!
That is most certainly not the case. Ansible is developed in the open and we
encourage community members to attend meetings
and add
topics to the agenda for
discussion. Ansible also goes through a proposal process for major changes,
which you can view here
.
You can always go to #ansible-devel on Freenode or start a discussion on the
mailing list to speak
with the Ansible Core devs about these things as well.
---
Respectfully,
Sam Doran
Senior Software Engineer
Ansible by Red Hat
sdo...@redhat.com __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] [tripleo-validations] using using top-level fact vars will deprecated in future Ansible versions
I've captured this as a point of discussion for the TripleO CI Team's planning session(s). Matt On Tue, Jul 24, 2018 at 4:59 AM Bogdan Dobrelya wrote: > > On 7/23/18 9:33 PM, Emilien Macchi wrote: > > But it seems like, starting with Ansible 2.5 (what we already have in > > Rocky and beyond), we should encourage the usage of ansible_facts > > dictionary. > > Example: > > var=hostvars[inventory_hostname].ansible_facts.hostname > > instead of: > > var=ansible_hostname > > If that means rewriting all ansible_foo things around the globe, we'd > have a huge scope for changes. Those are used literally everywhere. Here > is only a search for tripleo-quickstart [0] > > [0] > http://codesearch.openstack.org/?q=%5B%5C.%27%22%5Dansible_%5CS%2B%5B%5E%3A%5D=nope=roles=tripleo-quickstart > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] [tripleo-validations] using using top-level fact vars will deprecated in future Ansible versions
On 7/23/18 9:33 PM, Emilien Macchi wrote: But it seems like, starting with Ansible 2.5 (what we already have in Rocky and beyond), we should encourage the usage of ansible_facts dictionary. Example: var=hostvars[inventory_hostname].ansible_facts.hostname instead of: var=ansible_hostname If that means rewriting all ansible_foo things around the globe, we'd have a huge scope for changes. Those are used literally everywhere. Here is only a search for tripleo-quickstart [0] [0] http://codesearch.openstack.org/?q=%5B%5C.%27%22%5Dansible_%5CS%2B%5B%5E%3A%5D=nope=roles=tripleo-quickstart -- Best regards, Bogdan Dobrelya, Irc #bogdando __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] [tripleo-validations] using using top-level fact vars will deprecated in future Ansible versions
On 07/23/2018 08:33 PM, Emilien Macchi wrote: > Thanks Monty for pointing that out to me today on #ansible-devel. > > Context: https://github.com/ansible/ansible/pull/41811 > The top-level fact vars are currently being deprecated in Ansible, maybe > 2.7. > It looks like it only affects tripleo-validations (in a quick look), but > it could be more. > See: http://codesearch.openstack.org/?q=ansible_facts=nope== > > An example playbook was written to explain what is deprecated: > https://github.com/ansible/ansible/pull/41811#issuecomment-399220997 > > But it seems like, starting with Ansible 2.5 (what we already have in > Rocky and beyond), we should encourage the usage of ansible_facts > dictionary. > Example: > var=hostvars[inventory_hostname].ansible_facts.hostname > instead of: > var=ansible_hostname guh I'm sorry, but this is a non-sense, ugly as hell, and will just make things overcomplicated as sh*t. Like, really. I know we can't really have a word about that kind of decision, but... damn, WHY ?! Thanks for the heads-up though - will patch my current disk space validation update in order to take that into account. > > Can we have someone from TripleO Validations to help, and make sure we > make it working for future versions of Ansible. > Also there is a way to test this behavior by disabling the > 'inject_facts_as_vars' option in ansible.cfg. > > Hope this helps, > -- > Emilien Macchi > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Cédric Jeanneret Software Engineer DFG:DF signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] [tripleo-validations] using using top-level fact vars will deprecated in future Ansible versions
Thanks Monty for pointing that out to me today on #ansible-devel. Context: https://github.com/ansible/ansible/pull/41811 The top-level fact vars are currently being deprecated in Ansible, maybe 2.7. It looks like it only affects tripleo-validations (in a quick look), but it could be more. See: http://codesearch.openstack.org/?q=ansible_facts=nope== An example playbook was written to explain what is deprecated: https://github.com/ansible/ansible/pull/41811#issuecomment-399220997 But it seems like, starting with Ansible 2.5 (what we already have in Rocky and beyond), we should encourage the usage of ansible_facts dictionary. Example: var=hostvars[inventory_hostname].ansible_facts.hostname instead of: var=ansible_hostname Can we have someone from TripleO Validations to help, and make sure we make it working for future versions of Ansible. Also there is a way to test this behavior by disabling the 'inject_facts_as_vars' option in ansible.cfg. Hope this helps, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
