Fix DNS based CWNPs for network-isolated Clusters #177
Conversation
vknabel
changed the title
|
|
||
| # Add additional DNS addresses for dnat redirection for the dns proxy | ||
| table inet nat { | ||
| set public_dns_servers { |
There was a problem hiding this comment.
To me still the name of this set is a bit misleading because a user might provide a DNS server that is not publicly reachable. Apart from that, my expectation was that the statically defined public DNS servers are not used for resolving queries in case a dedicated DNS server was specified (of course this is problematic as this DNS server needs to resolve the shoots API server DNS but if someone sets this configuration I think it's fine to expect this complex implication).
So, from my side it would be good to duplicate the DNAT rules from the metal-networker. This enables us to remove the DNS proxy related code from the metal-networker and move it the here. Then, we can also implement that only the user-given DNS server is used and fallback to 1.0.0.1, 1.1.1.1, 8.8.4.4, 8.8.8.8 if nothing was given?
There was a problem hiding this comment.
Renamed the set in metal-stack/metal-networker#106
| // do nothing if message and state already have the desired values | ||
| if cwnp.Status.Message == msg && cwnp.Status.State == state { | ||
| return nil | ||
| } |
There was a problem hiding this comment.
I will try to investigate the impact on update traffic this will produce as this essentially updates all CWNPs of a cluster very regularly. Maybe it's worth to implement an update that only occurs if necessary (by comparing contents).
There was a problem hiding this comment.
I don't see a significant difference between requests of this firewall-controller and 2.3.0 for CWNPs in API server dashboards, so I assume we can start doing this.
Co-authored-by: Gerrit <[email protected]>
Requires:
Todo: