Currently, when pushing an image, validation is performed to check that
a layer/blob in the manifest already exists. For non-distributable
layers, that check needs to be skipped.
Fixes issue #1394
Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
Initial code was contributed by Bogdan BIVOLARU <104334+bogdanbiv@users.noreply.github.com>
Moved implementation from a separate db to repodb by Andrei Aaron <aaaron@luxoft.com>
Not done yet:
- run/test dynamodb implementation, only boltdb was tested
- add additional coverage for existing functionality
- add web-based APIs to toggle the stars/bookmarks on/off
Initially graphql mutation was discussed for the missing API but
we decided REST endpoints would be better suited for configuration
feat(userdb): complete functionality for userdb integration
- dynamodb rollback changes to user starred repos in case increasing the total star count fails
- dynamodb increment/decrement repostars in repometa when user stars/unstars a repo
- dynamodb check anonymous user permissions are working as intendend
- common test handle anonymous users
- RepoMeta2RepoSummary set IsStarred and IsBookmarked
feat(userdb): rest api calls for toggling stars/bookmarks on/off
test(userdb): blackbox tests
test(userdb): move preferences tests in a different file with specific build tags
feat(repodb): add is-starred and is-bookmarked fields to repo-meta
- removed duplicated logic for determining if a repo is starred/bookmarked
Signed-off-by: Laurentiu Niculae <niculae.laurentiu1@gmail.com>
Co-authored-by: Andrei Aaron <aaaron@luxoft.com>
The zap scanner started to check the csp header, which is causing a warning.
We also need to ignore the rule, as both settings are read by the scanner.
Per https://w3c.github.io/webappsec-csp/#example-7bb4ce67 we can have multiple
Content-Security-Policy headers, and the most restrictive policies apply.
This rule doesn't seem to be applied by zap.
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
upgrade to github.com/aws/aws-sdk-go@v1.44.237
upgrade to github.com/aquasecurity/trivy@v0.38.3
upgrade to oras.land/oras-go@v1.2.3
upgrade to github.com/google/go-containerregistry@v0.14.0
upgrade to github.com/moby/buildkit@v0.11.4
Note we can't switch to trivy 0.39.0 as well as some other updates
because they would also require upgrade of cosign to v2 with
breaking api changes
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
sync: remove sync WaitGroup, it's stopped with context
sync: onDemand will always try to sync newest image when a tag is used
if a digest is used then onDemand will serve local image
test(sync): fix flaky coverage in sync package
closes#1294
Signed-off-by: Petu Eusebiu <peusebiu@cisco.com>
* refactor(repodb): moving common utilities under pkg/meta
Signed-off-by: Laurentiu Niculae <niculae.laurentiu1@gmail.com>
* refactor(repodb): moved update, version components under pkg/meta
- updated wrapper initialization to recieve a log object in constructor
Signed-off-by: Laurentiu Niculae <niculae.laurentiu1@gmail.com>
* refactor(repodb): moved repodb initialization from controller to pkg/meta/repodb
Signed-off-by: Laurentiu Niculae <niculae.laurentiu1@gmail.com>
---------
Signed-off-by: Laurentiu Niculae <niculae.laurentiu1@gmail.com>
- before, the download count for a manifest and repo star count were lost after reload
- now we are keeping these values when we reset the repo-meta structure
Signed-off-by: Laurentiu Niculae <niculae.laurentiu1@gmail.com>
Changed repodb to store more information about the referrer needed for the referrers query
Signed-off-by: Laurentiu Niculae <niculae.laurentiu1@gmail.com>
putting this info into error detail would be ideal, but skopeo
doesn't print them, so overwrite the error message.
Signed-off-by: Petu Eusebiu <peusebiu@cisco.com>
If we push an artifact and give it a tag, repodb would crash because of the null pointer dereferencing
Now when iterating over the tags of a repo and stumbling upon a unsupported media type, it's being ignored
Signed-off-by: Laurentiu Niculae <niculae.laurentiu1@gmail.com>
The condition to generate trivyDB download tasks was bugged,
and new tasks were generated in case the download had already been
successful (state `done`).
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
BREAKING CHANGE: repository paths are now specified under a new config key called "repositories" under "accessControl" section in order to handle "groups" feature. Previously the repository paths were specified directly under "accessControl".
This PR adds the ability to create groups of users which can be used for authZ policies, instead of just users.
{
"http": {
"accessControl": {
"groups": {
Just like the users, groups can be part of repository policies/default policies/admin policies. The 'groups' field in accessControl can be missing if there are no groups. The permissions priority is user>group>default>admin policy, verified in this order (in authz.go), and permissions are cumulative. It works with LDAP too, and the group attribute name is configurable. The DN of the group is used as the group name and the functionality is the same. All groups for the given user are added to the context in authn.go. Repository paths are now specified under a new keyword called "repositories" under "accessControl" section in order to handle "groups" feature.
Signed-off-by: Ana-Roberta Lisca <ana.kagome@yahoo.com>
