Closed ThomasLaPiana closed 3 years ago
Notes from standup with Steven:
fidesctl evaluate --dry-run <manifests_dir>
@stevenbenjamin this feels pretty closely tied to the workflow things we want to solve, and we're in agreement there should only be one command that can be used with or without a dry-run flag. feel free to put your workflow thoughts here or in another issue
After some additional thought I believe the server should separate out different kinds of rating operations, and separate these from basic CRUD operations (i.e. create/update/delete a system, etc etc). We'd thought about having a system POST return an approval, but I think this makes the response kind of confusing , since every other CRUD endpoint should return the object in question.
Ultimately came up with this:
For consistency all rating actions will happen under /endpoint/rate. /system/rate/:id Create and return the approval for an existing system
/system/rate/dry-run Create and return the approval for the posted system as a dry-run. In this case the posted system is not stored
(proposed) /system/rate/:id/current Last seen rating for this system (i.e. the current known state)
/registry/rate/:id Create and return the approval record for an existing registry
/registry/rate/dry-run Create and return the approval for the posted registry as a dry-run. In this case the posted registry is not stored
(proposed) /registry/rate/:id/current Last seen rating for this registry (i.e. the current known state)
@stevenbenjamin A few thoughts here
fidesKey
instead of the id for lookups, otherwise it always adds another step of the CLI needing to look up the object first just to get its idrate
term is being deprecated in favor or evaluate
, rate
evokes a numerical scoring or a spectrum, whereas we just have a pass/faili understand the convenience of this, but it does get into consistency issues. How do we make this consistent with the rest of the API? shouldn't there be some way of assigning/storing the api values with the manifest?
There are no other manifests other than system manifests.
Policy changes need to be submitted separately, since a policy is organization wide, it needs to be re-applied to everything when you update it. this is not workable if you're constantly re-submitting. Ditto for resubmitting a piece of the taxonomy.
The model of "systems, rules, taxonomy types, etc" all stored in one place and continually reapplied is broken and will not work with the server as written. the server is built on the model of an in-place set of rules/taxonomy values that systems/registries are evaluated against. Your model will break completely if commits are coming from multiple places.
Naming change is not a problem.
One of the core components of Fides is the ability for it to run as part of CI and the greater "SDLC". For this to be possible, Fides needs to be aware of when its running on main/master and when its running in a branch. My proposed solution for this is to add a new field to all database objects called
branch
or something similar, and have Fidesctl inject the name of the git branch into that field when sending objects to the server and also filtering for that field when querying the server for objects.