kubeseal does not respond

[druskus20]

Which component:

chart 2.14.2 (and others)
kubseal: 0.25 (and previous)

Describe the bug
Same issue as: #317 (CLOSED)
The following command does not respond:

kubeseal --controller-namespace kube-system --controller-name sealed-secrets --format yaml < a.yaml

The suggestion by this user works:
#317 (comment)

Expected behavior
Kubeseal seals my secret a.yaml and prints it to screen.

Additional context

• Using EKS, k8s version 1.27.
• I've tried several versions of kubeseal and the helm chart.
• I am currently using ArgoCD but using helm results in the same.
• Kubeseal is working fine on another, very similar, older cluster. (older sealed-secrets version). But even that older version does not work in my current cluster.

I believe the issue is not yet resolved, hence why I am opening a new one.

[agarcia-oss]

Hi @druskus20

I just tried to verify the issue in an EKS cluster but I cannot reproduce it. Did you try the fetch-cert command to check the connectivity?

kubeseal --fetch-cert

Also, I executed your same command and it works for me:
kubeseal --controller-namespace kube-system --controller-name sealed-secrets-controller --format yaml < a.yaml

Please notice that I changed the controller name to the default sealed-secrets-controller. Are you sure the sealed secrets service in your cluster is not named like that?

Regards

[agarcia-oss]

Also, could your issue be related to this one? #1450 (comment)

[druskus20]

Hi @agarcia-oss

I tried to run kubeseal --fetch-cert with the same result. The CLI hangs waiting for the response of kubeseal.
The controller-namespace and controller-name flags in my cluster are correct.

Here you can see how, executing a kubeseal command with the wrong namespace or name results in an error message.
However, when set correctly, the CLI hangs.

I also checked the aws-auth configmap, and copied the one from my working cluster into the cluster in which kubeseal fails to respond, with no success.

[agarcia-oss]

Can you try the same fetch-certificate command but the the verbose option in kubeseal?
kubeseal --controller-namespace kube-system --controller-name sealed-secrets --fetch-cert -v 100

This should give you a full log of the request to the cluster from kubeseal.

[metalwhale]

@druskus20 cc @agarcia-oss
I believe the cause of this issue is not from kubeseal or sealed-secrets, but from the connection between the control plane and worker nodes on EKS.

If you use eks module for creating your cluster, you can try adding this following code inside the module:

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "20.8.3"

  # ...
  node_security_group_additional_rules = {
    # Allow ingresses from control plane to worker nodes
    ingress_from_control_plane = {
      type                          = "ingress"
      # Feel free to change these to your desired ports
      # Port `0` and protocol `-1` mean that I trust the control plane enough to allow ingresses of any ports & protocols to my worker nodes
      from_port                     = 0
      to_port                       = 0
      protocol                      = "-1"
      # `cluster_security_group` is the security group that control plane uses
      source_cluster_security_group = true
    }
  }
  # ...
}

By default eks module has enabled some ingresses that allow connections from control plane to worker nodes, but AFAIK port 8080 (as used by sealed-secrets controller) is not included.

I got the same problem and after adding the above security group kubeseal works like a charm.

[druskus20]

@agarcia-oss @metalwhale
Thanks! that helped.
All is left is for me to figure out exactly which security rules I'm missing

[druskus20]

I believe I figured out why:

resource "aws_security_group_rule" "sealed-secrets-access" {
  type              = "ingress"
  from_port         = 8080
  to_port           = 8080
  protocol          = "tcp"
  security_group_id = module.eks.node_security_group_id
   source_security_group_id = module.eks.cluster_security_group_id
  description = "Allow inbound traffic to sealed-secrets controller"
}

I had this rule configured on the cluster security group, instead of the node security group. Thanks!