Provide a separate directive for the default firewall rule
onnimonni opened this issue · 3 comments
The current implementation is that the default firewall rule eg reject: all
needs to be the last rule in the upcloud_firewall
directive.
Because of that the last rule is completely different than the other rules and the ansible user needs to apply all sorts of hacks to really get this working.
for example if I run this:
- debug:
var: upcloud_firewall_rules
- name: Setup firewalls for the backend groups
upcloud_firewall:
state: present
ip_address: "{{ item }}"
firewall_rules: "{{ upcloud_firewall_rules }}"
with_flattened:
- "{{ groups['db']|default([]) }}"
- "{{ groups['web']|default([]) }}"
Works just fine and outputs this =>
_________________________________
< TASK [upcloud-firewall : debug] >
---------------------------------
ok: [localhost] => {
"upcloud_firewall_rules": [
{
"action": "accept",
"comment": "Member of this cluster",
"destination_port_end": "22",
"destination_port_start": "22",
"direction": "in",
"family": "IPv4",
"protocol": "tcp",
"source_address_end": "94.237.29.230",
"source_address_start": "94.237.29.230"
},
{
"action": "reject",
"direction": "in",
"comment": "Default rule"
}
]
}
______________________________________________________
/ TASK [upcloud-firewall : Setup firewalls for the backend groups ]
------------------------------------------------------
changed: [localhost] => (item=example-machine)
But If I later on change that machine 94.237.29.230
=> 94.237.26.186
and apply these rules again the new machine gets just appended in the back of the list and the default rule isn't last one anymore. So then I'll get this:
Could you please provide better methods for updating the default rule?
I think this needs some changes to your API as well since there's no easy way to implement this after looking at your API documentation:
https://www.upcloud.com/api/11-firewall/
@onnimonni we'll take a look into this, there are some API updates coming in the near future :)
Since this repo will be deprecated this issue won't be fixed here. I will add this as a bug for the main API though. So thanks for the input.