When a CKS cluster has nodes added with addNodesToKubernetesCluster, a later scale-up that
increases the number of managed nodes fails while rebuilding the SSH firewall rules, because the
new rule range overlaps the existing rule of an imported node. By the time it fails, the old SSH
rule and the SSH port forwarding rules of the managed nodes are already removed.
From the code:
addFirewallRulesForNodes opens one range for the managed nodes, 2222 to 2222+M-1 (M =
managed non-etcd nodes), and one single-port rule per imported node after that range
(KubernetesClusterActionWorker.java#L1116-L1146).
KubernetesClusterAddWorker creates the same single-port rule when a node is imported
(KubernetesClusterAddWorker.java#L229).
All rules use the source CIDR 0.0.0.0/0.
On scale-up, scaleKubernetesClusterIsolatedNetworkRules revokes a single rule with
removeSshFirewallRule (the one starting at 2222), removes the port forwarding rules of the
old range, and calls setupKubernetesClusterIsolatedNetworkRules, which calls
addFirewallRulesForNodes again
(KubernetesClusterScaleWorker.java#L128-L149).
The single-port rules of the imported nodes are not revoked.
With one more managed node the new range ends on the port of the first imported node.
FirewallManagerImpl.detectRulesConflict rejects two firewall rules with the same protocol,
the same source CIDR and overlapping ports, so addFirewallRulesForNodes fails with "Failed to
provision firewall rules for SSH access", and the scale-up fails with "unable to update network
rules"
(KubernetesClusterScaleWorker.java#L518-L525).
The new VMs are cleaned up and the cluster goes back to Running (Scaling + OperationFailed
→ Running), but the revoked SSH rule and the removed port forwarding rules of the managed
nodes are not restored. The cluster looks healthy while the management server can no longer
reach the managed nodes over SSH, which later operations such as an upgrade need.
Example: 1 control node and 1 worker (rule 2222-2223), one imported node (rule 2224), scale to 2
workers: the new range 2222-2224 conflicts with the rule for 2224.
This affects isolated networks today. With #14670, which adds the same firewall
rules on VPC tiers whose VPC has the Firewall service, it affects those VPC tiers as well. VPC
tiers without the Firewall service have no firewall rules and are not affected by this part.
versions
Apache CloudStack main (a7be64a), 4.23.0.0 and the 4.22 branch: the code paths above
are the same in all three
Isolated network with the virtual router; CKS cluster with at least one node added via
addNodesToKubernetesCluster
Found by reading the code during the review of #14670, not reproduced on a live system yet.
The steps to reproduce the bug
Create a CKS cluster on an isolated network with 1 control node and 1 worker. CKS creates the
firewall rule TCP 2222-2223 on the source NAT IP.
Add a prepared VM with addNodesToKubernetesCluster. CKS creates a firewall rule and a port
forwarding rule for TCP 2224.
Scale the cluster to 2 workers with scaleKubernetesCluster.
Expected: the cluster is Running with 2 managed workers plus the imported node. From the code,
the scale-up fails instead and the cluster is back in Running with 1 worker, but the firewall
rule for 2222-2223 and the port forwarding rules 2222-2223 are gone.
What to do about it?
When the SSH rules are rebuilt for a new node count, revoke the single-port rules of the imported
nodes together with the range rule before calling addFirewallRulesForNodes, which recreates them
after the new range (and move their port forwarding rules accordingly). A regression test that
imports a node and then scales up would cover it.
removeSshFirewallRule is also being changed in #14165 (scale-down with separate etcd nodes), so
a fix should be coordinated with that PR. Related: #14670 (VPC tiers with the Firewall service).
threat detection engine error
The threat detection engine encountered an error and could not complete analysis. This is a tooling failure, not a security finding.
What happened
The threat detection engine failed to produce results.
After nodes are added with addNodesToKubernetesCluster, a later scale-up that increases the managed node count fails while rebuilding the SSH firewall rules. The new range overlaps the single-port rule of an imported node, and the rules conflict check rejects it. By then the old SSH rule and the port forwarding rules have been removed, and the cluster returns to Running without restoring them, so later operations such as upgrade may not reach the managed nodes. The reporter found this by reading code and has not reproduced it.
📊 Assessment
Dimension
Value
Reasoning
Type
type:bug
Failed scale-up leaves SSH access removed; reported from code analysis
Component
component:cks
SSH firewall rules in the CKS scale worker
Severity
Severity:Major
Cluster appears healthy while managed nodes are unreachable for SSH
Labels
type:bug, component:cks, Severity:Major
Not yet reproduced, so confidence is medium
Coding agent
Needs more info
Not reproduced; the change must be coordinated with #14165
Reproduction (from the report): isolated network, 1 control and 1 worker, add an imported node, then scale to 2 workers. Check the firewall rules and port forwards after the failed scale.
A regression test that imports a node and then scales up would cover the case.
This is the same problem as #12633, which I missed before opening this issue. I have since reproduced it on 4.23.0.0 as well. I'm closing this one as a duplicate of #12633; a fix is proposed in #14683.
removeSshFirewallRule does not always revoke the rule starting at 2222. It revokes the first rule that either starts at 2222 or has a port forwarding rule to port 22 on the same ports. After earlier scaling that can be an old rule of an external node, and then the range rule stays and the new range conflicts with it. I saw this on 4.23.0.0 after a scale-down.
Activity
github-actions commented on Nov 11, 2026
Warning
threat detection engine error
What happenedThe threat detection engine encountered an error and could not complete analysis. This is a tooling failure, not a security finding.
The threat detection engine failed to produce results.
Review the workflow run logs for details.
🎯 Triage report
After nodes are added with addNodesToKubernetesCluster, a later scale-up that increases the managed node count fails while rebuilding the SSH firewall rules. The new range overlaps the single-port rule of an imported node, and the rules conflict check rejects it. By then the old SSH rule and the port forwarding rules have been removed, and the cluster returns to Running without restoring them, so later operations such as upgrade may not reach the managed nodes. The reporter found this by reading code and has not reproduced it.
📊 Assessment
🔗 Similar issues
- CKS: scale-down with separate etcd revokes wrong SSH rules and fails (4.22.1.1) #14159 (related) — scale-down with separate etcd revokes the wrong SSH rules; same removeSshFirewallRule area
- CKS: make the source CIDR of the auto-provisioned node SSH firewall rules configurable #13970 (related) — make the source CIDR of auto-provisioned SSH rules configurable
- CKS: cluster on a VPC tier fails when the VPC has the Firewall service (#12706) #14668 (related) — CKS on a VPC tier with the Firewall service; the reporter notes the same rules would apply there
💡 Notes and suggestions- Reproduction (from the report): isolated network, 1 control and 1 worker, add an imported node, then scale to 2 workers. Check the firewall rules and port forwards after the failed scale.
- A regression test that imports a node and then scales up would cover the case.
- Coordinate with kubernetes: prefer the node SSH rule when scaling a cluster with etcd nodes #14165, which also changes removeSshFirewallRule.
Add this agentic workflow to your repoTo install this agentic workflow, run
adestis-mf commented on Nov 12, 2026
This is the same problem as #12633, which I missed before opening this issue. I have since reproduced it on 4.23.0.0 as well. I'm closing this one as a duplicate of #12633; a fix is proposed in #14683.
Three corrections to the description above: