This feature allows ClusterWare to check the Firewall and Security Policies status without the need to provide a root password. With Non-root status check enabled ClusterWare is able to verify the Firewall status and its compliance with Security Policies automatically.
Some operating system distributions have non-root status checking enabled by default.
With non-root status checking enabled, modifications of the firewall configuration such as enabling/disabling or applying Security Policies still require root privileges.
Non-root status check enabled
Non-root status check disabled
Syncing firewall status without non-root status check
If non-root status checking is disabled, the Firewall status and Security Policies status will remain unknown until you manually sync Firewall insights in ClusterWare Console. Syncing Firewall insights in this case will require providing the root password.
This section provides information if the Firewall is active or inactive and provides options to change the Firewall status.
Options (three-dot menu)
Activate UFW
Deactivate UFW
Reset UFW
Do not activate the firewall until the security policies are applied. Otherwise ClusterWare will lose access to the server and you will not be able to manage it in the ClusterWare Console.
Security Policies are the rules of traffic that are allowed or not allowed in your cluster. This section shows the status of all Security Policies that are targeting the server and allows to apply them to the server Firewall configuration. Read more about Security Policies.
Security Policies are not enforced if the Firewall status is inactive.
Security Policy Statuses
Applied (green checkmark): All rules from this policy are included in the Firewall configuration.
Not applied (red cross): At least one rule from this policy is not included in the Firewall configuration.
Unknown (yellow question mark): ClusterWare could not determine if this policy is applied. This may happen when UFW is not installed.
External: External tag indicates that this policy comes from the same server, but in a different cluster on your account. Servers with the same hostname and port created in different clusters share their Security Policies. This allows you to reuse the same server in different clusters and apply cluster-specific Security Policies seamlessly.
Auto-generated Security Policies
Incoming/Outgoing default: ClusterWare by default blocks all incoming traffic and allows all outgoing traffic from the server.
Allow SSH from ClusterWare: All servers are included in this policy allowing ClusterWare to access them and collect insights surfaced in the ClusterWare Console.
Allow from Internet to Load Balancer: For each server hosting a Load Balancer ClusterWare generates a policy allowing incoming traffic from the Internet to the Load Balancer server on the specified port.
Allow From Load Balancer to Applications: For each server hosting a Load Balancer ClusterWare generates a policy allowing outgoing traffic from the Load Balancer server to all Applications in the cluster.
To override the behavior of auto-generated policies you can create your own policy targeting the same hostname and port range.
Extra Firewall rules not included in any Security Policy
When ClusterWare detects Firewall rules that are not included in any Security Policy, those rules are reported at the end of Security Policies list. This situation may happen when you delete some resources from your cluster (load balancers, applications, security policies etc) or when the Firewall rules are applied manually on the server.
ClusterWare prevents permissions drift by reporting stale Firewall rules, so that the principle of least privilege is applied by default.
Click on Extra firewall rules not covered by any policy are applied button to check the details.
In this section you can quickly access the server public key for example to allow list it in external systems such as your Git repository. This field is read-only.
