Open de-jcup opened 7 months ago
We have big problems with Variants A + C: The DNS (domain name space)! Means we need something like Variant B!
The current PDS solutions using 05 scripts, connect to an internal sechub network (provided by sechub solution). In our system tests, e.g. for gosec we have an URL like https://pds.gosec:8444
.
SystemTest (local machine )
(starts) ---> docker: sechub-solution ---V
(creates network "sechub")
(starts) ---> docker: PDS-solution1 ---^ (connects to)
If we would just add local network access to our PDS-solution1 and define https://localhost:8444
inside our system test, this would not long work, because
localhost
inside sechub-solution
would point to sechub-solution
itself and sechub could not connect in this case!
Also this is very similar to a remote approach (currently not implement for systemtests, but would be useful as well).
Solution: We handle this issue as an "epic" and list here all necessary steps:
Situation
In
we introduced automatic PDS stream resolution inside system tests.
It works great with
SystemTestFrameworkIntTest
and has the wanted output (here the PDS and the SecHub server instance are accessible from localhost).But for some existing system tests with docker compose the systemtest framework has no access to the solution network, but only to SecHub server instance.
Reproduce
Just call
This builds the pds tools locally and after this, starts systemtest gosec "sanity-check". The test will not fail, but inside the log output there is an error, that the debug information cannot be fetched.
Wanted
Change the setup of the existing system tests in a way, that the PDS debug information can be downloaded automatically.
Solution
The problem is the missing possibility for the systemtest framework to get access to PDS REST API because of network issues.
Variant A: Change docker compose
PRO: no changes at SecHub side or at systemtest framework necessary
CON: PDS instance available from localhost
Variant B: SecHub as Proxy
SecHub could introduce a way to fetch data from PDS instances. Maybe by executor configuration identifiers and a dedicated admin api.
PRO: PDS not available at localhost
CON: At the moment SecHub does only need the technical PDS user. Here we would change to admin user - without a real need. Also systemtest framework and SecHub server itself would be changed
Variante C: Like A, but dedicated systemtest way
PRO: no changes at SecHub side or at systemtest framework necessary, "normal" docker compose parts not involved, still protected CON: addtitional configuration