You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 14, 2020. It is now read-only.
// Use one of the ADR status parameter based on status
7
-
// Please add a cross reference link to the new ADR on 'superseded' ADR.
8
-
// e.g.: {adr_suposed_by} <<ADR-0000>>
9
6
10
7
| Status
11
8
| ACCEPTED
@@ -24,7 +21,7 @@
24
21
25
22
=== Status Quo
26
23
27
-
One major challenge implementing the _secureCodeBox_ is to provide a flexible and modular architecture, which enables the open source community to easily understand the concepts and especially to extend the _secureCodeBox_ with individual features. Therefore we decided to seperate the process stages of a single security scan (instance of scanType CRD) in 3 major phases:
24
+
One major challenge implementing the _secureCodeBox_ is to provide a flexible and modular architecture, which enables the open source community to easily understand the concepts and especially to extend the _secureCodeBox_ with individual features. Therefore we decided to separate the process stages of a single security scan (instance of scanType CRD) in 3 major phases:
@@ -37,9 +34,9 @@ By now the "Persisting Phase 3" was implemented by so called _persistenceProvide
37
34
38
35
=== Problem and Question
39
36
40
-
We identified different additional UseCases with a more _data proccessing oriented_ pattern than the implemented _persisting phase3_ indicates. For example, we implemented a so called "MetaDataProvider" feature, which is responsible for enhancing each security finding with additional metadata. But the MetaDataProvider must be executed after the _parsing phase 2_ and before the _persisting phase 3_ because it depends on the parsed finding results (which will be enhanced) and the update findings should be also persisted.
37
+
We identified different additional UseCases with a more _data processing oriented_ pattern than the implemented _persisting phase3_ indicates. For example, we implemented a so called "MetaDataProvider" feature, which is responsible for enhancing each security finding with additional metadata. But the MetaDataProvider must be executed after the _parsing phase 2_ and before the _persisting phase 3_ because it depends on the parsed finding results (which will be enhanced) and the update findings should be also persisted.
41
38
42
-
To find a proper solution, we splitted the topic into the follwong two questions:
39
+
To find a proper solution, we split the topic into the following two questions:
43
40
44
41
. Should we unify the concepts MetaDataProvider and PersistenceProvider?
45
42
. How should the execution model look like for each concept?
@@ -51,8 +48,8 @@ To find a proper solution, we splitted the topic into the follwong two questions
51
48
Both "modules" are "processing" the security findings, which are generated in the parsing phase.
52
49
But there is one larger difference between them:
53
50
54
-
* `PersistenceProvider` is proccesing the findings with a *ReadOnly* pattern
55
-
* `MetaDataProvider` is proccesing the findings with a *ReadAndWrite* pattern
51
+
* `PersistenceProvider` is processing the findings with a *ReadOnly* pattern
52
+
* `MetaDataProvider` is processing the findings with a *ReadAndWrite* pattern
56
53
57
54
There is a similar thing in kubernetes called [AdmissionController](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), with the exception that the are executed before a resource gets created.
58
55
@@ -125,7 +122,7 @@ Keep PersistenceProvider as they are and introduce new "MetaDataProvider" CRD wh
125
122
====== Pros
126
123
127
124
* Quicker to implement
128
-
* Might be worth it to have a seperate concept for it
125
+
* Might be worth it to have a separate concept for it
129
126
130
127
====== Cons
131
128
@@ -142,9 +139,9 @@ Basically a docker container which process takes two command line args:
@@ -172,16 +169,16 @@ Analog to kubernetes webhooks. Https server receiving findings and returning res
172
169
===== Cons
173
170
174
171
* Introduces new running Services that need to be maintained and have uptime
175
-
* Code Overhead / Boilerplate (Can be mitigated by sdk)
172
+
* Code Overhead / Boilerplate (Can be mitigated by SDK)
176
173
* Debugging of individual MetaDataProvider is harder as everything is handled by a single service
177
174
* Introduces "New" Concept
178
175
* Certificate Management for webhook services (`cert-manager` required by default?)
179
176
* Scaling for systems with lots of load could be a problem
180
-
* One service per namespace (multiple tenants) needed => results in many running active services which is ressource consuming
177
+
* One service per namespace (multiple tenants) needed => results in many running active services which is resource consuming
181
178
182
179
== Decision
183
180
184
-
Regarding the Question 1 it seems that both solution approaches are resulting in the same execution model. We descided to implement solution approach 1 and unify both concepts into a more general concept with the name _"hook concept"_. Therefore we exchange the existing name `persistenceProvider` for phase 3 in the excecution model with a more general term `DataProcessing`:
181
+
Regarding the Question 1 it seems that both solution approaches are resulting in the same execution model. We decided to implement solution approach 1 and unify both concepts into a more general concept with the name _"hook concept"_. Therefore we exchange the existing name `persistenceProvider` for phase 3 in the execution model with a more general term `DataProcessing`:
0 commit comments