-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dso: add models for findings from gardener/inventory #1166
base: master
Are you sure you want to change the base?
Conversation
b20d14f
to
53e42ae
Compare
53e42ae
to
0c116cf
Compare
0c116cf
to
3cb5c63
Compare
|
||
@property | ||
def key(self) -> str: | ||
return _as_key(self.provider_name, self.resource_kind) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The key
is used to construct stable IDs for findings.
I am not familiar with gardener/inventory, however can you confirm that it is intended to only track one finding per e.g. gcp-vm
?
From a gut feeling, I would have expected that we want to track each resource individually, e.g. gcp-vm-testvm1
.
This will be crucial if we want to create github issues for orphaned resources.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @zkdev ,
An example for orphan GCP Virtual Machines with the current key set to provider_name
and resource_kind
would look like this (simplified):
{
"provider_name": "gcp",
"resource_kind": "virtual_machine",
"summary": "Orphan GCP Instances",
"resources": [
{
"name": "vm-01",
"project": "project-1",
},
{
"name": "vm-02",
"project": "project-2"
}
]
}
This will be crucial if we want to create github issues for orphaned resources.
Correct, we want to have Github issues created for orphan resources.
In the example above only a single Github issue should be created, and the issue details would list two virtual machines as being orphan.
Let me know if you have other questions, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should work like this. However, note, that if we do not create individual entries for each orphaned resource, we will have no means to track those individually. In case of vulnerabilities (where we also started by grouping - in this case by oci-image - we had the issue that tracking-issues were never closed in some cases (because of constant ingress of new findings).
That being said, I think it might be preferable to not group at this level, but do the grouping in delivery-gear-extension.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That being said, I think it might be preferable to not group at this level, but do the grouping in delivery-gear-extension.
I'm not familiar with this one, can you please provide more details?
The grouping we want for gardener/inventory
will be similar to the way the Diki integration works -- one issue with multiple findings in it.
@TuanAnh17N, @8R0WNI3 You have pull request review open invite, please check |
@dnaeon You need rebase this pull request with latest master branch. Please check. |
This PR adds models to support the integration between OCM Gear and gardener/inventory
Release note: