Description of problem: I have a customer asking for details and advice on how to implement firewall rules for OpenStack, specifically pertaining to Host Aggregates and Availability Zones. I have found the standard firewall port lists as linked below, but the customer is looking for further guidance here. Do we have any documentation or advice on best practises here? Thank you, David https://access.redhat.com/documentation/en/red-hat-openstack-platform/8/paged/configure-firewall-rules-for-red-hat-openstack-platform-director/ https://access.redhat.com/solutions/2678381
(In reply to David Peacock from comment #0) > Description of problem: > > I have a customer asking for details and advice on how to implement firewall > rules for OpenStack, specifically pertaining to Host Aggregates and > Availability Zones. Can you expand on their host aggregate/availability zone setup? From a Compute POV these are scheduling constructs and don't change our expectation of the networking setup (hence why there is no specific documentation for them).
(In reply to Stephen Gordon from comment #1) > (In reply to David Peacock from comment #0) > > Description of problem: > > > > I have a customer asking for details and advice on how to implement firewall > > rules for OpenStack, specifically pertaining to Host Aggregates and > > Availability Zones. > > Can you expand on their host aggregate/availability zone setup? From a > Compute POV these are scheduling constructs and don't change our expectation > of the networking setup (hence why there is no specific documentation for > them). I've asked for more detail; thank you Stephen.
Hey Stephen, Customer came back; is this too high level or enough to go on? ~~~ Our environment holds 3 Controller Nodes and 17 Compute Nodes, with an external Ceph Storage. In general we want to have an external zone which is only accepting connections to the Openstack API, VPN and ssh. The internal zone should include all the connections between controllers, compute and ceph storage - but none of those ports should be accessible from the external zone. ~~~
Hey there, Any news on this? Thanks! David
Hey there, Customer is chasing me again - just wondering if there's any news on this? Thank you, David
(In reply to David Peacock from comment #5) > Hey there, > > Customer is chasing me again - just wondering if there's any news on this? > > Thank you, > David It seems to me that rather than relating to host aggregates or availability zones the customer is asking for some form additional marker in the documentation indicating which ports are API ports?
Hey Stephen, Your guess is better than mine, so I'll take it. Sadly I'm not particularly knowledgeable in this area hence my BZ. Are you able to provide this info conveyed in a way relating to the customer's enquiry regarding availability zones? Thank you, David
Ping - do you have any more insight for me please Stephen? I'm out of my depth here. Thank you for any help you can give me. David
(In reply to David Peacock from comment #7) > Hey Stephen, > > Your guess is better than mine, so I'll take it. Sadly I'm not particularly > knowledgeable in this area hence my BZ. Are you able to provide this info > conveyed in a way relating to the customer's enquiry regarding availability > zones? > > Thank you, > David This is I guess my point, the firewall rules have nothing to do with availability zones because availability zones are a Nova scheduling construct. They do not fundamentally alter the topology of the deployment (though they can be used to expose it to users). Whether my host is in an AZ or not it needs the same firewall rules to talk to the rest of its dependencies within the environment. I think what the customer likely actually wants is information on the ports that need to be available on the public versus internal network (which does not change depending on whether you use AZs or not) but I do not have further information on that and would instead recommend looking at the default as per the director deployed configuration, which the documentation should also be updated to match.