search

metal-stack / firewall-controller

A kubernetes controller running on bare-metal firewalls, creating nftables rules, configures suricata, collects network metrics
MIT License
47 stars 4 forks source link

Egress IP can still be used after free #64

Closed Gerrit91 closed 3 years ago

Gerrit91 commented 3 years ago

Don't know if this project is the right place, but when you delete an Egress IP from a cluster via metal-api the IP can still be used for outgoing requests:

metalctl network ip ls --ipaddress 212.34.83.16
IP      DESCRIPTION     NAME    NETWORK PROJECT TYPE    TAGS

But in a cluster container:

/ # wget ipconfig.me
Connecting to ipconfig.me (72.52.10.14:80)
Connecting to ifconfig.me (216.239.36.21:443)
saving to 'index.html'
index.html           100% |*******************************************************************************************************************************************************************|    12  0:00:00 ETA
'index.html' saved
/ # cat index.html 
212.34.83.16
mwindower commented 3 years ago

This is an issue for gardener-extension-provider-metal

Gerrit91 commented 3 years ago

Right, we could possibly fix it there, but one question that comes to my mind is... if routing with a a "non-existing" source address that does not exist should also be prevented through the switch config of the leaves?

mwindower commented 3 years ago

No this is not possible, as there is no possibility to have CIDR-Filters for EVPN Type-5 routes at the leaves for firewall ports.

What bothers me in the scenario you described: what happens with the shoot spec ... at the moment the old address will still be there.

Gerrit91 commented 3 years ago

We implemented a check in cloud-api that prevents a user from removing an IP... but if a user does that with metalctl, I think he broke something.

mwindower commented 3 years ago

Closing this: cluster will get into error state in this scenario and directly using metalctl is potentially unsafe in various situations.

Gerrit91 commented 3 years ago

Mh. I don't know. Don't really like the fact that it's generally possible to disguise behind IPs that are not even allocated in the metal-api, probably from other projects, too. I always thought that from the metal-stack perspective a user should be able to create his own firewalls and that the user is free to access it through SSH or console if he so desires. But now it sounds like accessing a firewall is more of a "provider admin" thing because malicious users could do evil things.

Maybe the check in the cloud-api prevents this scenario for most of the time, but to me this still leaves a bad aftertaste. 🤔