Hi @Jason_Tran, thanks for your reply.
Indeed, is clear for me the IP ranges for terraform and Github hosted runners are not being whitelisted at the Atlas API access list, and in this case they should.
I have enabled the API access list for my organization and even I added a bunch of those ranges arrays on it. And of course, I would have to add the entire ranges to make them works, but the thing is, I want to share with you the following particular situation:
Until some days ago I didn’t need to whitelist the terraform and Github runners IP ranges on the Atlas API access list. My pipelines were working well for quite a time in that way, without atlas asking me for this.
Why suddenly Atlas API is denying me access now to my terraform and Github runners, but before it was allowing my runners to interact with it in a normal way?
I think it should be some internal stuff from Atlas API (?)
I have a hypothesis that I would like to share with you:
Last March 1, I accidentally delete my atlas cluster from an automatic process doing some tests from my local machine.
My atlas cluster is created via terraform, and I am running a terratest process to verify my infrastructure (atlas mongoDB cluster included) is being created in a proper way and after that, terratest delete the test environment created for this tests.
My mistake was to point from terratest to the current cluster in use and not to the test environment created in runtime, it was unfortunate indeed.
Then my hypothesis is:
Is Atlas MongoDB team/platform/process blacklisting the terraform hosted runners IP ranges and Github actions hosted runners IP ranges I have been using as a protection measure?
I mean perhaps they could be thinking this unfortunate situation from my side was an attack and not something from me as an owner of the cluster?
I am wondering this since from more than 1 year ago I never did need to whitelist terraform and GitHub runners IP ranges on the Atlas API access list for my organization. And after this situation, Atlas is simply asking me for doing it.
I wanted to tell you this, perhaps you can help me to think about it.
I mean for me is quite strange, why Atlas API does not demanded to whitelist the Ip ranges from the beginning and now it does it, just after this incident?
If this situation (my hypothesis) ending up affirmative … is there a chance to go with the support team, explain the situation, and perhaps reverts this behavior?
Actually, my atlas cluster is within an M10 plan, but the support for it is within the basic Free plan.
Just in case, what could you suggest to me to proceed in this case?