@bionel u r so funny! Here is a forum, and the people has question…
My question is why the configuration cannot be done at client side.
And I didn’t find any explanation of differences between Platform vs Standalone.
You have an existing test project in Azure Repos / Bitbucket / GitHub / GitLab / AWS CodeCommit.
This description is not clear enough to me. We have 2 cases where
user’s GitLab server is public; open to the Internet
user’s GitLab server is private; it is on the companies intranet; their network is isolated from the Internet. Their repository is not accessible for the external services (such as TestOps)
Does Katalon Studio Platform Edition support both cases?
Is it possible for a user to use Platform Edtion using his private GitLab?
Is it possible for a user to use Platform Edition using his private GitHub Enterprise server on his intranet?
I ask this to Katalon team because I only use v8.3.0, so that I don’t know anything about v8.5.0 Platform Edition.
I ask this because I suppose I would not be able use my private Git repository hosting server in Katalon Studio Platform Editon.
I ask this because Katalon’s documation is not clear enough about the case where user’s Git repository hosting server is on their private network.
I guess that Katalon team strategically ignored (somebody tell me better english please) the users who are capable to build&maintain their testing infrastructure for themselves. Katalon wants to promote their TestOps product which is forcused to serve users who are unable to build&maintain the infrastructure for themselves.
To me it seems that Katalon Team is reluctant to write “you can not use your private GitHub Enterprise server with TestOps, therefore Platform Edition is not good fit for you” in the documentation, as this sounds bad for marketing.
Am I wrong or right? Please clarify.
I believe that this umbiguity confuses many people.
How is this supposed to work?
Let’s say, I have my Gitlab on-prem installed on a certain internal datacenter, behind the company firewall, having the DNS like gitlab.mydomain.com.
The DNS is handled by the company DNS services, also behind the firewall.
From the company intranet I may be able to reach www, but from www I am not able to reach intranet resources (obviously why) without connecting my VPN client.
So, even if (by luck) the IT team agrees to “whitelist” the needed Katalon domains for out-going traffic (provided are blocked), how the requests (incoming traffic) from www (where TestOps resides) are handled ?
How the DNS will be resolved to point to my on-prem resource?
How TestOps will tunnel to my intranet without knowing what VPN client / server is in place?
I am afraid that this sentence reveals that @albert.vu does not appreciate the significance of security concerns for serious enterprises appropriately.
“Whitelisting” is not something we, Katalon users, can try casually.
If an employee who has a private Git repository wants to try whitelisting, he/she must convice the companies’ network administrators and the high-level managements (CTO) as it matters (breaks) their current security policy. I am sure that it will be quite tough to lay the groundwork. If he/she tried whitelisting TestOps without authorization, will be fired.
This suggestion implies that Katalon requests us to turn our private GitLab to public = exposed to the Internet so that it is accessible for TestOps.
Am I wrong or right?
I think it is OK if users must choose either of the following:
they will do whitelist the TestOps on the Internet so that TestOps is granted to access to their Git repository.
they will never allow access to their private Git repository from the Internet. Therefore they should just drop TestOps from their option.
If Katalon explains this clearly, the users who have a private Git respository on their companies’ private network will think and decide.
please stop using this term until we get a fully explanation
whitelist it is usually used in the context of outgoing traffic. which is not solving anything imho.
what seems to be actually needed is to fully expose a private resource to www for incoming requests.
such is not trivial to achieve for a single internal resource paired to a single external domain and any sane it team will reject such abominating idea. period
If applied, TestOps must publish its static IP addresses to be listed by users, which must be maintained for its lifetime; no DNS to be used.
Publishing its static IP address would cause serious difficulties to the TestOps service itself. Katalon can never change the IP address. They would need Elastic IP provided by AWS or something like that, and keep the address unchanged forever. If I were the admin of TestOps, I would ban the idea.
Most probably. I wish luck with this.
In addition to some more data needed from TestOps side (clear list of ip:port pairs) , this involve some effort at org level also (company side) to be sure only what is needed and only for what is needed is … mhm, ok, ‘’ whitelisted".
And this it is also highly dependant on the firewall solution used and the internal network configuration company side.
And usually, this will involve a security assesment from the company side, since, most probably, the company policy is ‘zero-trust level’.
I suppose the intention is to achieve such via the Tunnel feature which is (poorly) documented here:
But I still cannot see how:
this is aplicable for TestOps
this is applicable for git repositories
Another thing I don’t understand is
… looks like, in TestOps, actually we don’t set a git repository (so the code is pulled at the moment of running the tests from the company git) but we upload it one time and further the development should happen on the repository from TestOps.
Which makes the code to be public actually since is no longer hosted on a private resource but on TestOps.
Which, again, may infrige the company policies …
I suppose, those enterprise with “zero-trust level” policy would never be interested in TestOps which effectively violates their policy. So, it is pointless to discuss about “Incoming IP whitelisting” for TestOps.
I suppose Katalon Team would be able to strategically concentrate their development efforts to the potential users who have relaxed security policies and public Git hostings.