<p>Q: <em><strong>&quot;Disable communication to all the systems you do not want to update.&quot;</strong></em></p>
<p>A: The only safe way is to physically isolate such <a href="https://docs.ansible.com/ansible/latest/tips_tricks/ansible_tips_tricks.html#separate-production-and-staging-inventory" rel="nofollow noreferrer">environment</a>. A firewall might be an option. But, it's not feasible if you want to keep ssh or other <a href="https://docs.ansible.com/ansible/latest/inventory_guide/connection_details.html#connection-methods-and-details" rel="nofollow noreferrer">connections</a> that Ansible might use.</p>
<p>On the configuration level, there are many options.</p>
<p><strong>1) Special user</strong></p>
<p>Create a special user for this purpose on the systems you want to update. For example user <em>ansible_update</em>. Depending on your <a href="https://docs.ansible.com/ansible/latest/tips_tricks/ansible_tips_tricks.html#separate-production-and-staging-inventory" rel="nofollow noreferrer">environment</a> configure the <a href="https://docs.ansible.com/ansible/latest/reference_appendices/config.html#default-remote-user" rel="nofollow noreferrer">DEFAULT_REMOTE_USER</a> to <em>ansible_update</em>. This way you make sure no other systems can be connected by mistake.</p>
<p>In addition to this, you control who can connect to these systems by putting their public keys into the <em>authorized_keys</em> of the user <em>ansible_update</em> at the remote hosts.</p>
<p>To enforce this you have to:</p>
<ul>
<li>monitor users at the remote hosts and their <em>authorized_keys</em></li>
<li>scan your project (playbooks, roles, inventory, configuration) for remote users other than <em>ansible_update</em></li>
</ul>
<p><strong>2) Bastion host</strong></p>
<p>A better option is creating a <a href="https://en.wikipedia.org/wiki/Bastion_host" rel="nofollow noreferrer">bastion host</a> and making it the only source of the configuration for the environment.</p>
<p><strong>3) ansible-pull</strong></p>
<p>The most flexible option is configuring the remote hosts to <a href="https://docs.ansible.com/ansible/latest/cli/ansible-pull.html" rel="nofollow noreferrer">pull</a> their updates on their own.</p>
<p><strong>Conclusion</strong>: Create special users, create a bastion host, and make the remote hosts pull the updates from it.</p>

CC BY-SA 4.0
2022-11-24T05:06:20.223Z
2022-11-24T05:06:20.223Z
Vladimir Botka
<p>I think you might be approaching the problem backwards and are using &quot;hosts: all&quot; instead of specific groups, then limiting with --limit.  But if not, here's a solution I've used to target specific hosts (such as those in their maintenance window) within an existing group.</p>
<p>I start running against <code>hosts: all</code></p>
<p>Then I find some sort of limiting criteria like, use the url module to query my ticketing system to tell me which devices have open changes for patching or something.</p>
<p>Then I use &quot;<a href="https://docs.ansible.com/ansible/latest/collections/ansible/builtin/add_host_module.html" rel="nofollow noreferrer">add_host</a>&quot; to create a temporary subgroup*</p>
<pre><code>- name: Add a host alias that we reach through a tunnel (Ansible 2.0 and newer)
  ansible.builtin.add_host:
    ansible_host: '{{ inventory_hostname }}'
    groups: subgroup


</code></pre>
<p>and I run against <code>hosts: subgroup</code></p>
<p>*warning if you refresh your inventory, this will get hosed</p>

CC BY-SA 4.0
2022-11-30T22:16:26.700Z
2022-11-30T22:16:26.700Z
Peter Turner
<p>If you are really paranoid, generate a custom inventory containing only the hosts you want to update, and pass that.</p>

CC BY-SA 4.0
2022-11-30T22:09:35.670Z
This post could use some improvement (like a link/explanation on to how to create a custom inventory).
Peter Turner
CC BY-SA 4.0
2022-11-29T09:19:05.280Z
2022-11-29T09:19:05.280Z
Chris Becke
<p>If you enable firewalld rule for ansible, how you want to disable it? Yeah, there are ways, but hey! we talk here about having some sense in the work.</p>
<p>Where is your environment? I assume it is not dynamic, as for dynamic environment you use dynamic inventory.</p>
<p>First idea - split hosts per environments and corresponding directories. This way you have to provide the correct env and file. It gives the time to think.</p>
<p>Not-very-good-solution - run ansible through script. Makefile, bash, whatever, with confirm action.</p>
<p>The best - use CI/CD. Of course, you can do the mistake there, but... only once ;)</p>

CC BY-SA 4.0
2022-11-27T15:46:49.313Z
2022-11-27T15:46:49.313Z
Pawel Piwosz
<p>It is too easy to run playbooks on the wrong hosts in Ansible</p>
<p>I know the best practice would be to use --limit to make sure you can not select the wrong host.  I do not trust --limit to ensure Ansible runs playbooks only on the intended hosts.</p>
<p>Is it a crazy idea to use firewalld to disable communication to all the systems you do not want to update?   Is there a more logical way to accomplish the same thing?</p>

CC BY-SA 4.0
2022-11-30T07:46:58.320Z
I'm having a hard time understanding how this problem can actually arise. This sounds like an inventory management problem - playbooks target hosts which find themselves in the wrong groups for some reason. Can you please elaborate on what your environment looks like - is it dynamic, how are you tagging hosts, creating groups, etc?
Bruce Becker
<ansible><ansible-inventory><firewall>
What is a good strategy to prevent Ansible playbook runs against the wrong hosts?
timfox123
# What is a good strategy to prevent Ansible playbook runs against the wrong hosts?

(Asked by: username_0 on 2022-11-24)

It is too easy to run playbooks on the wrong hosts in Ansible

I know the best practice would be to use --limit to make sure you can not select the wrong host. I do not trust --limit to ensure Ansible runs playbooks only on the intended hosts.

Is it a crazy idea to use firewalld to disable communication to all the systems you do not want to update? Is there a more logical way to accomplish the same thing?

**Tags:** ansible, ansible-inventory, firewall

> **Comments:**
> **username_1**: I'm having a hard time understanding how this problem can actually arise. This sounds like an inventory management problem - playbooks target hosts which find themselves in the wrong groups for some reason. Can you please elaborate on what your environment looks like - is it dynamic, how are you tagging hosts, creating groups, etc?  

---

## 4 answers

### Answer by username_2 on 2022-11-24. Score: 1

Q: ***"Disable communication to all the systems you do not want to update."***

A: The only safe way is to physically isolate such [environment](https://docs.ansible.com/ansible/latest/tips_tricks/ansible_tips_tricks.html#separate-production-and-staging-inventory). A firewall might be an option. But, it's not feasible if you want to keep ssh or other [connections](https://docs.ansible.com/ansible/latest/inventory_guide/connection_details.html#connection-methods-and-details) that Ansible might use.

On the configuration level, there are many options.

**1) Special user**

Create a special user for this purpose on the systems you want to update. For example user *ansible\_update*. Depending on your [environment](https://docs.ansible.com/ansible/latest/tips_tricks/ansible_tips_tricks.html#separate-production-and-staging-inventory) configure the [DEFAULT\_REMOTE\_USER](https://docs.ansible.com/ansible/latest/reference_appendices/config.html#default-remote-user) to *ansible\_update*. This way you make sure no other systems can be connected by mistake.

In addition to this, you control who can connect to these systems by putting their public keys into the *authorized\_keys* of the user *ansible\_update* at the remote hosts.

To enforce this you have to:

* monitor users at the remote hosts and their *authorized\_keys*
* scan your project (playbooks, roles, inventory, configuration) for remote users other than *ansible\_update*

**2) Bastion host**

A better option is creating a [bastion host](https://en.wikipedia.org/wiki/Bastion_host) and making it the only source of the configuration for the environment.

**3) ansible-pull**

The most flexible option is configuring the remote hosts to [pull](https://docs.ansible.com/ansible/latest/cli/ansible-pull.html) their updates on their own.

**Conclusion**: Create special users, create a bastion host, and make the remote hosts pull the updates from it.


---

### Answer by username_3 on 2022-11-30. Score: 0

I think you might be approaching the problem backwards and are using "hosts: all" instead of specific groups, then limiting with --limit.  But if not, here's a solution I've used to target specific hosts (such as those in their maintenance window) within an existing group.
I start running against hosts: all
Then I find some sort of limiting criteria like, use the url module to query my ticketing system to tell me which devices have open changes for patching or something.
Then I use "add_host" to create a temporary subgroup*
- name: Add a host alias that we reach through a tunnel (Ansible 2.0 and newer)
  ansible.builtin.add_host:
    ansible_host: '{{ inventory_hostname }}'
    groups: subgroup



and I run against hosts: subgroup
*warning if you refresh your inventory, this will get hosed


---

### Answer by username_4 on 2022-11-29. Score: 0

If you are really paranoid, generate a custom inventory containing only the hosts you want to update, and pass that.

> **Comments:**
> **username_3**: This post could use some improvement (like a link/explanation on to how to create a custom inventory).  

---

### Answer by username_5 on 2022-11-27. Score: 0

If you enable firewalld rule for ansible, how you want to disable it? Yeah, there are ways, but hey! we talk here about having some sense in the work.

Where is your environment? I assume it is not dynamic, as for dynamic environment you use dynamic inventory.

First idea - split hosts per environments and corresponding directories. This way you have to provide the correct env and file. It gives the time to think.

Not-very-good-solution - run ansible through script. Makefile, bash, whatever, with confirm action.

The best - use CI/CD. Of course, you can do the mistake there, but... only once ;)


---

