with #148 admins will be able to enable/disable and also configure executors at runtime.
But when we provide many tools and not every enabled executor shall be availabel for every project we need a layer between.
E.g.
project1 is written in go
project2 is written in java
project3 is written in c/c++
project4: is written in python
project5: is written in kotlin
when we provide
a) checkmarx adapter
b) PDS: gosec
c) PDS: findbugs
d) PDS: SAST-tool-only-python
e) PDS: SAST-tool-only-kotlin
f) netsparker adapter
g) PDS: an-extreme-brand-new-tool-testing
All of those executors are run (depending of codescan type)
Wanted
We want
only executors running being suitable for dedicated project
a way to administrate this by something between project and execution configurations
a way to activate a dedicated new tool only for a (pilot) project without affecting all other projects
Solution
Introduction of execution profiles
We provide execution profiles.
Every project is related to n execution profiles
Every execution profile is related to n product executor configurations (introduced with #148)
Instead of collecting all enabled executor configurations a job will only use the enabled executor configuration available in related execution profiles.
Execution Profile with id "profile-ab": configurations A,B added
Execution Profile with id "profile-c" : configuration C added
Execution Profile with id "profile-d" : configuration D added
Project1 has "profile-ab"
Project2 has "profile-c"
Project3 has "profile-ab" and "profile-c" and "profile-d"
Project4 has no profile
What shall happen ?
Project1 scan will execute checkmarx and also with gosec for code scans, webscans not possible
Project2 scan will execute python sast tool, webscans not possible
Project3 scan will execute checkmarx, gosec and python sast tool for webscans and netsparker for webscans
Project4 scan will do NOTHING because no profile at all
Necessary migration
We have already created projects. Those projects have no profiles at the moment.
When this features is active a current setup would not work any longer.
We will handle this by providing a mass CSV operation inside Developer Admin UI.
CSV assign profile to projects mass operation
CSV will look like:
projectId, profileId
So when doing a CSV mass create project operation were owners and projects are automatically created in addition
this mass operation must be done as well
The next parts would be nice and more convenient, will be done by simple update at the beginning
(but could be done later - so easier for administration):
UC_ADMIN_ADDS_CONFIG_TO_EXECUTION_PROFILE
UC_ADMIN_REMOVES_CONFIG_FROM_EXECUTION_PROFILE
TODO
[ ] implement all mentioned use cases
[ ] create/add concept documentation
[ ] handle existing integration testcases
every scenario must have a default profile were standard executors are inside and applied to existing projects
so existing tests do not fail
[ ] write integration tests for new usecases
[ ] add missing restdoc tests
[ ] write CSV mass operation for developer admin ui
This will be made together with #148 because otherwise #148 integrations tests are extreme slow and also executor configuration changes could lead to race conditions in tests
Situation
with #148 admins will be able to enable/disable and also configure executors at runtime.
But when we provide many tools and not every enabled executor shall be availabel for every project we need a layer between.
E.g. project1 is written in go project2 is written in java project3 is written in c/c++ project4: is written in python project5: is written in kotlin
when we provide a) checkmarx adapter b) PDS: gosec c) PDS: findbugs d) PDS: SAST-tool-only-python e) PDS: SAST-tool-only-kotlin f) netsparker adapter g) PDS: an-extreme-brand-new-tool-testing
All of those executors are run (depending of codescan type)
Wanted
We want
Solution
Introduction of execution profiles
We provide
execution profiles
.Instead of collecting all enabled executor configurations a job will only use the enabled executor configuration available in related execution profiles.
Example
Setup
Executor Config A: checkmarx adapter (SAST) Executor Config B: PDS: gosec (SAST) Executor Config C: PDS: python tool (SAST) Executor Config D: netsparker adapter (DASP)
Execution Profile with id "profile-ab": configurations A,B added Execution Profile with id "profile-c" : configuration C added Execution Profile with id "profile-d" : configuration D added
Project1 has "profile-ab" Project2 has "profile-c" Project3 has "profile-ab" and "profile-c" and "profile-d" Project4 has no profile
What shall happen ?
Project1 scan will execute checkmarx and also with gosec for code scans, webscans not possible Project2 scan will execute python sast tool, webscans not possible Project3 scan will execute checkmarx, gosec and python sast tool for webscans and netsparker for webscans Project4 scan will do NOTHING because no profile at all
Necessary migration
We have already created projects. Those projects have no profiles at the moment. When this features is active a current setup would not work any longer.
We will handle this by providing a mass CSV operation inside Developer Admin UI.
CSV assign profile to projects mass operation
CSV will look like: projectId, profileId
So when doing a CSV mass create project operation were owners and projects are automatically created in addition this mass operation must be done as well
Usecases
The next parts would be nice and more convenient, will be done by simple update at the beginning (but could be done later - so easier for administration): UC_ADMIN_ADDS_CONFIG_TO_EXECUTION_PROFILE UC_ADMIN_REMOVES_CONFIG_FROM_EXECUTION_PROFILE
TODO
Albert Tregnaghi albert.tregnaghi@daimler.com, Daimler TSS GmbH, imprint