Cannot connect to cluster after creation because of missing firewall rule

[exocode]

How can we reproduce it?

Simply use your examples folder cluster.yaml

What environment did it happen in?

• Civo

❯ k version
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.3", GitCommit:"c92036820499fedefec0f847e2054d824aea6cd1", GitTreeState:"clean", BuildDate:"2021-10-27T18:34:20Z", GoVersion:"go1.16.10", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.2+k3s1", GitCommit:"1d4adb0301b9a63ceec8cabb11b309e061f43d5f", GitTreeState:"clean", BuildDate:"2021-01-14T23:52:37Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}
WARNING: version difference between client (1.22) and server (1.20) exceeds the supported minor version skew of +/-1

I only get it working when I manually create a firewall rule which opens all ports:

Without this rule above I cannot connect to the cluster.

So one of the following features should be available to follow GitOps:

a.) able to assign existing firewall rulesets to the cluster manifest via ids

(like: firewall: ["k3s-cluster-production-crossp-6b99-37a574"])

b.) a declarative way for firewall rules/rule-sets in form of manifests which then could be connected to the cluster manifest like in a.)

Hope its not described to complicate. :-)

BTW: the firewall is not cleaned up after cluster deletion.

[exocode]

Hi again, weired issue. I cannot connect to newly created clusters, even with the firewall rules applied:

[exocode]

ok, I've to delete this empty first entry, which is automatically created when cluster is created. But the second entry must exist, and it must be created MANUALLY., which breaks GitOps practice