Related
Question
Question
Question
firewall source tag does not see new droplets?
For example:
If I have droplets B1, B2 and B3, all tagged “B”, and a droplet A1 with the firewall rule “allow HTTP from tag:B”, A1 receives HTTP traffic from B1, B2 and B3. All OK so far.
But if I then create B4, tagged “B”, A1 does not accept traffic from it, unless I remove “B” from the firewall rule and re-add it.
This would seem to be problematic when adding new droplets that need to consume a secured internal service.
Is this expected behaviour? I can use the API to add a rule for each new droplet, but that seem like a pity.
Cheers,
Graham.
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
×
I was going to report this issue but after reading it seems you’re all experiencing the same problem as I am. Core issue is that there is a noticeable delay between API creation of a new droplet (with tag), and firewall adding said droplet (by tag) to the firewall. As a result, I’m unable to communicate with new droplets. I’m not sure if this is accurate or not, but it seems as though after I browse the UI in the firewalls section, the droplet becomes listed, though I’m unsure as to whether or not this is purely coincidence.
An update to this post, I’ve had success applying the tag to the newly created droplet in a separate call to the “tags” API after the droplet is in the active state. It seems the firewall doesn’t pick up the droplet only if the tag is included in the droplet creation body. I’m wondering if this has something to do with the unavailability of the droplet at the time of creation.