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
After upgrading from helm chart v1.14.0 to v1.15.0 we noticed in our test environment that the trivy pod sends requests to the core pod now.
v1.14.0
Trivy -> registry
v1.15.0
Trivy -> core
Is there any service/architecture map with ports? That would help us to write/optimize the network policies and we could also contribute the network policies to the helm chart.
The text was updated successfully, but these errors were encountered:
@snakebyte91 could you please provide us with details showing that trivy pod sends requests to registry in Harbor helm v1.14.0 while trivy pod sends requests to core in Harbor helm v1.15.0?
We do introduced SBOM generation in harbor helm v1.15.0, in addition to vulnerability scan in v1.14.0, but these two features follow the same request-response process as defined in this pluggable-scanner-spec. There should be no changes regarding the request-response between harbor component and trivy pod.
Sorry for the delay I was on parental leave. I compared the network policies from our dev and prod environment and I saw that in our prod environment the trivy pod was already able to send requests to the core pod. That rule was missing in our dev environment. So there is no change between 1.14 and 1.15.
It would be great to have a service map with ports so it would be much easier to write the right network policies.
This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.
After upgrading from helm chart v1.14.0 to v1.15.0 we noticed in our test environment that the trivy pod sends requests to the core pod now.
v1.14.0
Trivy -> registry
v1.15.0
Trivy -> core
Is there any service/architecture map with ports? That would help us to write/optimize the network policies and we could also contribute the network policies to the helm chart.
The text was updated successfully, but these errors were encountered: