Old Containers & Security Vulnerabilities #528
Comments
|
Can I suggest we list the particular things you think we should update as a PR would be preferable. |
|
Here's some of the output from our image scanner twistlock. This is based off the images I found in the helm chart off commit 0df5904 of seldon-core. We're primarily concerned with critical & high vulnerabilities. bitnami/minideb:latest bitnami/redis:4.0.14 oliver006/redis_exporter:v0.31.0 quay.io/datawire/ambassador:0.40.2 seldonio/apife:0.2.8-SNAPSHOT seldonio/cluster-manager:0.2.8-SNAPSHOT seldonio/engine:0.2.8-SNAPSHOT |
|
Our corporate policy says that all our dependencies need to have reasonably current version (including direct and indirect dependencies). So we are basically not allowed to use Seldon just because it uses outdated libraries. I went through all Seldon Java third-party dependencies (I did not deal with seldon-core-h2o-example and seldn-core-model-template). Here are my findings: api-frontendOutdated dependencies:
Dependencies which should have test scope instead of compile scope:
cluster-managementOutdated dependencies:
engineOutdated dependencies:
Overall recommendations
|
|
Also it would be good to update following python modules: Flask-OpenTracing 0.2.0 (last version is 1.0.0) |
|
We've done an initial update to the seldon-core images. @log0ymxm we dont have access to "twistlock" but have tested these against another open source scanner. seldonio/apife:0.2.8-SNAPSHOT Would be useful if you test again and see which vulnerabilities are remaining. For ambassador its possible to use another version via the helm value @martinpanacek We will review the other changes. |
|
@gsunner This is great, this solve some of the system installed dependencies, but it looks like there's still quite a few of the Java dependencies that have known CVE's attached. |
|
@gsunner I have pulled the new images and ran a Twistlock vuln scan. It appears literally all of the critical (one with a CVSS of 10!) come from an outdated version of seldonio/engine:0.2.8-SNAPSHOTseldonio/cluster-manager:0.2.8-SNAPSHOTseldonio/apife:0.2.8-SNAPSHOT |
|
We've updated the 'jackson' dependencies in #547 The latest snapshot images will have this change |
|
Github also reported: Upgrade com.fasterxml.jackson.core:jackson-databind to version 2.9.9 |
|
Closing this for the added fixes. |
agrski
added a commit
that referenced
this issue
Dec 2, 2022
* Use angle brackets to denote metadata direction & position (header/trailer) Right angle brackets (>) indicate outgoing headers. Single left angle brackets (<) indicate incoming headers. Double left angle brackets (<<) indicate incoming trailers. * Add blank lines after inbound/outbound metadata in gRPC inference requests * Show response metadata before response itself for gRPC requests This is consistent with the REST/HTTP1 approach, and also provides better logical grouping by keeping all metadata for a single request together. * Use unary interceptor to log request metadata Using an interceptor allows us to capture the request method being called, which is more similar to the REST equivalent. * Check headers & set up context before creating connection for gRPC * Add header validation func for gRPC * Change method -> func as no state used * Refactor gRPC header parsing/validation to function * Refactor gRPC metadata injection logic to functions This makes the main inference call concise and clean to read. * Use background not TODO context * Add line breaks for logical grouping * Move function to under caller * Use helper functions for REST request metadata injection * Reorder statements for legibility * Reorder imports into stdlib/third party dichotomy * Add missing argument to helper function * Use closure to capture authority for metadata-logging interceptor * Simplify setting gRPC authority in connection setup * Rename var for concision * Fix typo in function name * Conditionally use logging interceptor * Add blank lines for logical separation * Split long method args list over multiple lines * Fix typo in var name * Pass logging options via struct to gRPC inference method This starts to impose structure on the rather long list of method parameters. It has the added benefit that the entire group of logging options can then be passed on to other functions or methods easily. * Pass inference call options via struct to gRPC inference method * Fix typos in model inference subcommand * Provide call & log options in pipeline inference subcommand * Use logging & call options for REST inference method * Pass logging options to gRPC connection setup * Use logging options in unary interceptor for gRPC connections * Print request in gRPC interceptor, if required * Print gRPC response metadata in interceptor, if required * Remove unused trailers var for gRPC inference requests * Rename interceptor var * Chain unary gRPC interceptors * Refactor stream-retry interceptor to var for consistency * Rename method for clarity Firstly, it is good to clarify that the object being returned is for gRPC. Secondly, 'get' implies (potential) reuse of an existing object, whereas we are creating a fresh object. In turn, this makes the passing of arguments more reasonable. * Add comment explaining ordering of chained interceptors
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Seldon seems like a great project that helps solve a real problem. We've explored using it within our organization, but we audit & scan all containers that go into our kubernetes clusters. The containers used in the variety of seldon services are all significantly out of date and make it's deployment a non-starter. Many of the issues can be solved by using more up to date OS versions.
Is it possible to review the containers, the jdk, dependency and OS versions that are being used and update to newer versions? Is the build process for the container builds documented anywhere? Maybe this could allow us to fork only the build process and work out updating underlying containers ourselves.
The text was updated successfully, but these errors were encountered: