Skip to content

Instantly share code, notes, and snippets.

@ancorgs

ancorgs/firewall-at-ALP.md

Created August 2, 2022 08:10
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save ancorgs/c1397980c91593c43a8e97731d451ed4 to your computer and use it in GitHub Desktop.
Save ancorgs/c1397980c91593c43a8e97731d451ed4 to your computer and use it in GitHub Desktop.
Download ZIP
Some questions about ALP and automatic firewall management
Raw
firewall-at-ALP.md

The bold question

Is there any vision/plan/strategy on how handle firewall rules in a way that is integrated with the process of installing a package or deploying a containerized workload?

Practical example

  • Cockpit is the chosen solution for 1:1 system management.
  • Cockpit can only configure firewalld when firewalld is running.
  • If you install firewalld in your ALP system and start it with the provided default configuration then it will block connections from other hosts to the Cockpit web interface.
  • Note: so far, the Cockpit web interface is installed as RPM but in the future it should also be available as a container.

More concrete Cockpit+firewalld questions

  • Should the Cockpit package/container offer some mechanism to open the relevant port during installation/deployment?
  • Or should it show some warning about the potential chicken-egg problem?
  • Or is that maybe a mission for the Firewalld package/container?
  • Should we improve Cockpit to show an extra option when starting the firewall in the web interface (ie. automatically open Cockpit in the process)?
@dcermak
Copy link

dcermak commented Aug 2, 2022

I think this could/should be handled by ignition/combustion maybe via a more declarative way how to setup firewall rules, e.g. reusing a salt-state or ansible playbook.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment