I am in the last part of a SOC2 certification process and there are 2 rules that I have not been able to close, which are related to exposed ports without restriction. In particular:
EC2 instances have public port(s) other than 80 and 443.
EC2 instances allow unrestricted access to TCP port 22.
I tried to restrict ports from the security group configuration in AWS but all services stopped responding.
What is the recommendation to be able to make this modification without affecting the operation of Qovery (and the cluster)?
Hi @donald-inostroza , I get back to you after discussing with my team. EC2 K3S is not a type of cluster we recommend for production, and by extent for being SOC2 compliant.
Please look at the limitation of EC2 K3S here
In your case, one more limitation is that we can’t close the SSH port of your instance since it’s the only way we have to get access to it in case something goes really wrong.
I’d really push you to consider using our EKS offer which will resolve this issue and guarantee the level of security and availability you might except.
Note: EC2 K3S instance is cost effective, but it was not designed for production, neither security compliance.
Hi Romaric, thanks for your answer. We’re actually using a managed EKS cluster for production. My question is about restricting the access to the nodes.
@donald-inostroza , from what I see you have 3 clusters. 2 EKS and 1 EC2, I assume you are talking about restricting SSH from your EC2 instance right? (this is what you mentioned in your first message).
I didn’t know you were already using EKS, so it’s great. But for EC2, unfortunately we can’t restrict the SSH port - but let me see with @Pierre_Mavro what we can do to prevent unrestricted connections from outside.
In this case I’m talking about the nodes of the EKS Cluster. These are the rules I need to apply to the inbound rules in the security group.
Verify that the protocol is not “All traffic” and that the port or port range is explicitly specified in each of your rules. The ICMP protocol is not considered public.
Check for values in the Source column that are set to 0.0.0.0/0 or ::/0 (Anywhere) with corresponding Port range column values that are not 80 and 443. If these two settings are true, the selected security group allows unrestricted traffic on this port range.
For the rows seen in step 7, change the Port range values to 80 and 443 or change the Source values to not be 0.0.0.0/0 or ::/0.
And, as an example, this is the inbound rules configuration for one of the security groups.
After reviewing this in detail, I understand that the security group of the nodes (ec2) of the cluster exposes some ports to publicly expose the APIs that require it and that this is done using NodePort. I also understand that in order to close these ports, a solution would be to enable the static IP (and NAT gateway) in the cluster. To do this, it is necessary to migrate to a new cluster because currently it can only be enabled in a new cluster.
I just ask you to confirm if what I described is correct.
Yes, your understanding is correct. When you enable the static IP through NAT gateway, the ports will not be exposed publicly. To enable a static IP, you will need to create a new cluster.
Later in the quarter, we will propose a new solution where Qovery will manage the Kube cluster, except for the network part that can be configured and managed directly by the client.
