Describe the issue
This is ticket that before proceeding I would like to discuss with the team, specially Bruce, if it is worth the time and effort.
The test plan approach to verify the update/upgrades do not introduce any surprise is to analyze the state of the SEA before and after the u/u. To test the guardrails and policies what I am doing is to run scripts that query the AWS api , store the info in a json file. These files are like a snapshot of the SEA at the give moment.
It is possible to do something similar using the Cloudguard API (probably less, as it has some limitations and bugs).
However, notice the information can be considered redundant with the info provided by AWS as it is a sort of double verification of the SEA guardrails state.
The question is if this exercise is to analyze if it is worth to proceed,
Additional context
There are two approaches to use the extracted information:
What I am calling the snapshot: for example, how many accounts are in the system? This provides a single integer, that can later be used to learn how the number of accounts change in time. Also, provides the means to quickly compare the value with the one obtained by AWS
The more extensive one is to get, for example, the list of all policies. These results can be compared with the ones obtained by AWS and highlight the differences between the two lists
Definition of done
If we go ahead, done will mean to create new tickets to cover the work to
Create a guardrails-snpashot usingCloudGuard
Compare the results obtained trough the Cloudguard API with the results obtained from AWS API.
The tickets will be
Scripts that will extract information from Cloudguard (using its API) (note: this is partially done)
Scripts that will parse the previous information and save it as an snapshot of the SEA Guardrails at a given time
Script that will compare the results obtained from AWS with the ones from Cloudguard
I think we want to proceed as is with the lightweight already implemented AWS test, and later in another quarter, we can explore new approaches in CSPM
Describe the issue This is ticket that before proceeding I would like to discuss with the team, specially Bruce, if it is worth the time and effort.
The test plan approach to verify the update/upgrades do not introduce any surprise is to analyze the state of the SEA before and after the u/u. To test the guardrails and policies what I am doing is to run scripts that query the AWS api , store the info in a json file. These files are like a snapshot of the SEA at the give moment.
It is possible to do something similar using the Cloudguard API (probably less, as it has some limitations and bugs).
However, notice the information can be considered redundant with the info provided by AWS as it is a sort of double verification of the SEA guardrails state.
The question is if this exercise is to analyze if it is worth to proceed,
Additional context There are two approaches to use the extracted information:
Definition of done If we go ahead, done will mean to create new tickets to cover the work to
The tickets will be