Cluster control plane endpoint public access

Questions and Answers
1

Because of compliance reasons, I need to close public access to the control plane endpoint on AWS and, at the same time, enable the private endpoint for internal communication with the nodes. What alternatives do I have today to make this change without interrupting the operation of Qovery?

The cluster is an EKS, Qovery managed cluster.

Thanks
(Let me know if you need more info)

2

Hi @donald-inostroza , I’m looping with the team internally - we’ll come back to you asap.

1 Like
3

Thank you @rophilogene.

4

Hi @rophilogene, did you have the chance to review this?

5

Hello @donald-inostroza ,

We are reviewing your needs internally, and we try to find the best way to do this.

We don’t have an ETA yet but we’ll get back to you when we do.

Regards,
Charles-Edouard

7

Hello @donald-inostroza,

I have a question regarding your needs:

  • Is a whitelist on the control plane endpoint enough to achieve compliance?

For the private endpoint, we can work on adding an option in your cluster to choose if you want to activate the private endpoint.

Thanks for your answer.
Charles-Edouard

8

Hi @ce_gagnaire

Yes, that would be enough.

Thanks

9

I had a similar request a while back and a whitelist would also achieve the necessary compliance standards for our organization as well.

10

Hi,

just a quick update on this one.

We will work over the next weeks on allowing you to update the cluster configuration to have:

  • private endpoint: enabled
  • public endpoint: enabled but only allowing the Qovery control plane to access it (via an IP whitelist)

We’ll let you know once it is released

1 Like
11

That’s awesome! thank you @a_carrano.

1 Like
12

the infrastructure change is not trivial on our side but we should be able to expose the Qovery control plane from one single IP in the upcoming weeks.

There is one drawback (please let me know if this is a blocker):

  • if you are deploying images from public container registries (mostly Dockerhub)
    or
  • if your Dockerfile has FROM condition pulling images from the Dorckerhub

you will have to add some Dockerhub credentials to the default Dockerhub registry that is created within in your organization.

Why?

Dockerhub has a rate limit system by IP when pulling from their registry.

Since the Qovery control plane will be seen as a single IP, we will quickly reach the limit. This limit can be increased if you are a logged-in user and thus, if you put your credentials in the Dockerhub registry configuration of your organization, you should not encounter any rate limit issue during the deployment.

2 Likes
13

Yes, I understand the context and it wouldn’t be a block on my side. We do indeed pull images from the Dockerhub, but I already have credentials configured in Qovery. Not sure if we will hit the rate limits, but that would be a different problem.

1 Like
14

We also pull images from Dockerhub. I know we ran into the rate limit thing in the past through Qovery. I’ll make sure we make an account and add it to our Qovery registration configuration.

1 Like
15

For your information, we are going to deliver the feature next week.

We’ll communicate further on it to let you know when it will be available and how to activate it.

1 Like
16

The feature has been delivered! Note: it is available only for AWS clusters

We strongly recommend you to test it on your non-production cluster before moving to the production one.

how to activate it:

  • ensure to have a [Dockerhub registry] created and configured with your own credentials. As explained above, this is a requirement we have set to avoid rate limit issues when pulling images from the Dockerhub registry (more info here).
  • set the cluster advanced settings qovery.static_ip_mode to true
  • re-deploy your cluster

This will apply a whitelist on the cluster public endpoints and activate the private endpoint.

:warning: if you need access to the Kube API from other locations (like connecting via k9s from your own laptop), you will have to add those additional IP/CIDR in the advanced settings k8s.api.allowed_public_access_cidrs

Update: we have been giving access for free to this feature to our existing customers but given the infrastructure cost and the value it brings from a security stand-point we will add it to our pricing page in a dedicated section.

Let me know if you need more information

3 Likes
17

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.