Allow customization of default egress security group rules in CAPO managedSecurityGroups

[alejandro-ripoll]

/kind feature

Describe the solution you'd like

Currently, when Cluster API Provider OpenStack (CAPO) creates security group rules, it defines default egress rules that allows all outbound traffic (0.0.0.0/0). This behavior is implemented here:

cluster-api-provider-openstack/pkg/cloud/services/networking/securitygroups_rules.go

Lines 32 to 51 in a6f9102

	var defaultRules = []resolvedSecurityGroupRuleSpec{
	{
	Direction: securityGroupRuleDirectionEgress,
	Description: "Full open",
	EtherType: securityGroupRuleEtherTypeIPv4,
	PortRangeMin: 0,
	PortRangeMax: 0,
	Protocol: "",
	RemoteIPPrefix: "",
	},
	{
	Direction: securityGroupRuleDirectionEgress,
	Description: "Full open",
	EtherType: securityGroupRuleEtherTypeIPv6,
	PortRangeMin: 0,
	PortRangeMax: 0,
	Protocol: "",
	RemoteIPPrefix: "",
	},
	}

In some environments, this default behavior is too permissive and does not comply with security or business constraints that require restricting outbound traffic to specific CIDRs.

I would like to have a way to customize or restrict the default egress rules generated by CAPO without having to disable managedSecurityGroups, since this feature provides other valuable functionality that I want to keep (such as automated lifecycle management of security groups).

A possible solution could be one of the following:

• Allow configuring egress CIDR ranges via OpenStackCluster spec
• Provide a flag to disable the default "allow all egress" rule so that I can add only allowed egress ranges via OpenStackCluster.spec.managedSecurityGroups.allNodesSecurityGroupRules

The goal is to support environments where outbound traffic must be explicitly restricted without losing the benefits of managed security groups.

Anything else you would like to add:

This limitation makes it difficult to adopt CAPO in environments with strict network segmentation requirements (e.g., regulated industries or zero-trust networks), where unrestricted egress is not allowed even temporarily.

A configurable approach would significantly improve the provider’s flexibility and enterprise readiness.

[lentzi90]

Sounds good to me. Would you be able/interested to work on this?
This could be a fairly large task so I think some kind of design would be good as a first step. We could do that either here as comments on the issue (if it doesn't end up being too large) or as a proposal in https://github.com/kubernetes-sigs/cluster-api-provider-openstack/tree/main/docs/proposals.

[alejandro-ripoll]

Thanks for your response @lentzi90. I would be interested in working on this.

As a first step, I tried to put together a lightweight design here in the issue, since I think the scope is still small enough to discuss as comments. If it grows too much or maintainers prefer a more formal review process, I can move this into a proposal under docs/proposals.

The high-level idea would be to add a generic opt-out mechanism for CAPO predefined security group rules, instead of solving this only for egress CIDRs.

Design Proposal

I would propose addressing this by adding a new opt-out flag under managedSecurityGroups, for example:

managedSecurityGroups:
  enablePredefinedRules: false

The goal would be to keep CAPO-managed security group lifecycle management enabled, while allowing users to fully opt out of the predefined rules that CAPO currently creates.

Today, when managedSecurityGroups is enabled, CAPO creates and reconciles the security groups, but it also adds a predefined set of rules. This includes rules such as default egress, API server ingress, NodePort access, kubelet/etcd traffic, additional API server load balancer ports, bastion SSH rules, and the optional allowAllInClusterTraffic rules.

The feature requested in this issue could be solved narrowly by allowing configurable egress CIDRs. However, that would only address one specific predefined rule. The broader problem is that CAPO predefined rules may not be aligned with the requirements of some deployments. Restricted egress is one example, but the same problem can apply to other predefined rules as well.

Because of that, I think this should be solved generically rather than by adding an egress-specific option. This proposal would therefore add a generic opt-out mechanism for all predefined rules, rather than a rule-specific API.

With enablePredefinedRules: false, CAPO would still create, tag, attach, reconcile, and delete the managed security groups, but the desired rule set would only be built from user-provided rules:

clusterNodesSecurityGroupRules
controlPlaneNodesSecurityGroupRules
workerNodesSecurityGroupRules

If the flag is omitted or set to true, the current behavior would remain unchanged.

This would make the change backward compatible while allowing users to define the complete security group rule set themselves when the predefined CAPO rules do not match their requirements.

I would also suggest rejecting or documenting the combination of:

managedSecurityGroups:
  enablePredefinedRules: false
  allowAllInClusterTraffic: true

since allowAllInClusterTraffic asks CAPO to generate predefined broad in-cluster rules, while enablePredefinedRules would explicitly disable CAPO-generated rules.

This avoids forcing users to disable managedSecurityGroups entirely just because the predefined rules are too permissive or not suitable for their environment.

Edit: Switch disablePredefinedRules for enablePredefinedRules to use positive polarity fields.

[lentzi90]

Sounds good!
As part of cleaning up our API in v1beta2, we have been trying to use positive polarity for all fields (to avoid hard to understand double/triple negatives). So I would suggest we go with enablePerdefinedRules and default true instead.

Let's see what others have to say 🙂
CC @nikParasyr @bnallapeta @smoshiur1237

[alejandro-ripoll]

Thanks @lentzi90, I've updated the design with your feedback.