The Trivy library now supports multiple locations from where to download the DBs.
The zot code has been updated to properly call the updated library functions.
If at some point we would want to support multiple Trivy DBs in zot, we could look into it more.
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
There are 2 remaining exceptions that I am aware of:
1. The tests under test/blackbox/cve.bats
2. One of the cli tests checking the server attempts download of the databases
from the default url
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
* feat: add support for docker images
Issue #724
A new config section under "HTTP" called "Compat" is added which
currently takes a list of possible compatible legacy media-types.
https://github.com/opencontainers/image-spec/blob/main/media-types.md#compatibility-matrix
Only "docker2s2" (Docker Manifest V2 Schema V2) is currently supported.
Garbage collection also needs to be made aware of non-OCI compatible
layer types.
feat: add cve support for non-OCI compatible layer types
Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
*
Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
* test: add more docker compat tests
Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
* feat: add additional validation checks for non-OCI images
Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
* ci: make "full" images docker-compatible
Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
---------
Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
See #2744, there are 2 updates:
1. Silence the usage output in case of config verification errors
2. Wrap the error details in all of the zot configuration errors so they are propagated and shown in stdout for `zot verify`
We also need to keep logging those message to the zot logs file since the same logic is caled in the `zot serve` use case.
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
Exit early in case of all folders and known non-blob file names.
This avoids the logic for validating digests, and log message generation.
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
Looks like we didn't have many GC tests for retaining multiarch images.
I added more data to the existing image retention tests, besides the new GC tests.
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
cache.HasBlob() looks in both buckets: duplicates and original blobs
Because we want to check if the blob is in original bucket let's use
cache.GetBlob() because it's looking only in original bucket.
Signed-off-by: Eusebiu Petu <petu.eusebiu@gmail.com>
In case of delete by tag only the tag is removed, the manifest itself would continue to be accessible by digest.
In case of delete by digest the manifest would be completely removed (provided it is not used by an index or another reference).
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
chore: upgrade trivy to v0.55.2, also update the logic of waiting for zot to start in some jobs
Seems like there's an increate in the time zot requires to start before servicing requests.
From my GitHub observations it is better check using curl instead of relying on hardcoded 5s or 10s values.
The logic in .github/workflows/cluster.yaml seems to be old and out of date.
Even on main right now there is only 1 our of 3 zots actualy running.
The other 2 are actually erroring: Error: operation timeout: boltdb file is already in use, path '/tmp/zot/cache.db'
This is unrelated to this PR, I am seeing the same issue in the olders workflow runs still showing the logs
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
fix(authn): configurable hashing/encryption keys used to secure cookies
If they are not configured zot will generate a random hashing key at startup,
invalidating all cookies if zot is restarted. closes: #2526
Signed-off-by: Petu Eusebiu <peusebiu@cisco.com>
when a client pushes an image zot's inline dedupe
will try to find the blob path corresponding with the blob digest
that it's currently pushed and if it's found in the cache
then zot will make a symbolic link to that cache entry and report
to the client that the blob already exists on the location.
Before this patch authorization was not applied on this process meaning
that a user could copy blobs without having permissions on the source repo.
Added a rule which says that the client should have read permissions on the source repo
before deduping, otherwise just Stat() the blob and return the corresponding status code.
Signed-off-by: Petu Eusebiu <peusebiu@cisco.com>
Co-authored-by: Petu Eusebiu <peusebiu@cisco.com>
when a UI client tries to view image details
for an image with multiple tags pointing to the same digest
we make a query to dynamodb having duplicate keys (same digest)
resulting in an error and the client is redirect back to image
overview.
closes: #2464
Signed-off-by: Petu Eusebiu <peusebiu@cisco.com>
This commit includes support for periodic repo sync in a scale-out
cluster.
Before this commit, all cluster members would sync all the repos as
the config is shared.
With this change, in periodic sync, the cluster member checks whether
it manages the repo. If it does not manage the repo, it will skip the
sync.
This commit also includes a unit test to test on-demand sync too, but
there are no logic changes for it as it is implicitly handled by the
proxying logic.
Signed-off-by: Vishwas Rajashekar <vrajashe@cisco.com>
* feat(cluster): initial commit for scale-out cluster
Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
* feat(cluster): support shared storage scale out
This change introduces support for shared storage backed
zot cluster scale out.
New feature
Multiple stateless zot instances can run using the same shared
storage backend where each instance looks at a specific set
of repositories based on a siphash of the repository name to improve
scale as the load is distributed across multiple instances.
For a given config, there will only be one instance that can perform
dist-spec read/write on a given repository.
What's changed?
- introduced a transparent request proxy for dist-spec endpoints based on
siphash of repository name.
- new config for scale out cluster that specifies list of
cluster members.
Signed-off-by: Vishwas Rajashekar <vrajashe@cisco.com>
---------
Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
Signed-off-by: Vishwas Rajashekar <vrajashe@cisco.com>
Co-authored-by: Ramkumar Chinchani <rchincha@cisco.com>
refactor(http): refactor http client to take options struct
This commit updates the arguments for the `CreateHTTPClient`
function to consume a struct which can be extended as required.
It replaces the certPath argument with a struct of 3 paths for
client ertificate, client key, and ca cert. It also adds
a TLSEnabled option for when an HTTP Client is required
without any further TLS config.
Existing consumers of this function have been updated so that
they can work as they do today. This change is a no-op for
existing features.
This allows for certificate paths to be customised and
allows other modules to re-use the same HTTP client and get
the benefits of mTLS support and per-host certificates.
Signed-off-by: Vishwas Rajashekar <vrajashe@cisco.com>
fix(cli/server): serve command expected positinal args
Expect exactly one positional argument for the serve command with the
path to the config file.
Signed-off-by: Ramiro Algozino <ramiro@sighup.io>
Ramkumar Chinchani