Security Group update on AWS

News
1

To enhance security practices on AWS, Qovery will remove the ALLOW_ALL rules from the default VPC security group on November 10th 2024.

What Does This Mean?

When a network VPC is created for your EKS cluster, AWS automatically sets up a default security group with rules that allow all ingress and egress traffic.

While Qovery does not use this default security group, it remains and can trigger false alerts in security scanners.

To adhere to best practices, we will remove these permissive rules, even though they are not utilized by Qovery.

Are You Impacted?

  • Custom VPC: No change if you manage your own VPC.
  • Managed EKS Cluster (No AWS Console Modifications): This change should be transparent.
  • Managed EKS Cluster (Attached Resources to Default Group): You must migrate your resources.

To check if resources are attached to the default security group, run:

aws eks list-clusters --query "clusters[?starts_with(@, 'qovery-')]" --output text
CLUSTER_NAME=qovery-xxxxx
VPC_ID=$(aws eks describe-cluster --name ${CLUSTER_NAME} --query "cluster.resourcesVpcConfig.vpcId" --output text)
aws ec2 describe-network-interfaces --filters "Name=vpc-id,Values=${VPC_ID}" --filters "Name=group-name,Values=default"

Next Steps If You Are Impacted

Create your own security group with appropriate rules (including ALLOW_ALL if desired) and attach your resources to this new group.

2 Likes
3

Would it be possible to post a link to the best practices that is mentioned in this blog post?

The default security group allows all inbound only from within the default security group itself and allows all outbound to 0.0.0.0/0. While I agree that it is better to use specific security groups instead of the default one I’m not sure if I understand the severity that would cause Qovery to make this change to my accounts. Especially since Qovery is not using the default security group.

Also from a customer standpoint, why is Qovery adopting resources that it did not create in my accounts? I understand that Qovery is trying to take care of it’s customers but I feel like this may be stepping a little outside your mission of making it easy to deploy to k8s.

My suggestion is that if Qovery would like to promote a best practice it should send out a notice to customers and allow them to decide if they want to follow that practice or not.

4

Hello Kevin,

To be honest, this is something we would have done since day 1 if we hadn’t missed it.
In managed cluster mode, Qovery creates and owns the VPC where the cluster is created. This security group is created by default at the VPC creation, is too wide open, and is not used at all by default. The only reason why we haven’t cleared it is because it is un-deletable for AWS and requires special care in our terraform.

Qovery has always tried to provide secure clusters by default and help customers achieve compliance (SOC2/HIPAA). And this security group, that we missed, makes alerts pop up for everybody that aims to achieve this goal.

This change does not restrict customization, as the announcement states, users only need to be explicit and create their security group to do some modifications.
This change is mainly here to clarify and provide a sane default for everyone without having to tweak parameters.

Regarding your last statement, while we want to allow the maximum of customizations for our customers. Qovery still promotes best practices (i.e.: EKS clusters are spawned across 3 zones), and it is in part the value we provide to our customers, to not have a deep expertise and be able to rely on us.

5

Thanks for the response!

It hadn’t occurred to me or one of my peers as we read and discussed this post that this was the default security group created in the VPC that Qovery had built and managed. I do agree that you should take ownership of that VPC’s default security group.

The way we had read the post it sounded to us as if you were reaching outside of what you all had deployed and adopting resources within the account.

Sorry for my misunderstanding and thank you for your clarifying response.

1 Like