Skip to content

Latest commit

 

History

History
67 lines (44 loc) · 3.76 KB

known_issues.md

File metadata and controls

67 lines (44 loc) · 3.76 KB
Raw

Troubleshooting and Known Issues

This topic contains troubleshooting and known issues for Supply Chain Security Tools - Store.

CrashLoopBackOff from password authentication failed

Symptom

Supply Chain Security Tools - Store does not start up. You see the following error in the metadata-store-app pod logs:

$ kubectl logs pod/metadata-store-app-* -n metadata-store -c metadata-store-app
...
[error] failed to initialize database, got error failed to connect to `host=metadata-store-db user=metadata-store-user database=metadata-store`: server error (FATAL: password authentication failed for user "metadata-store-user" (SQLSTATE 28P01))

Solution

If you see the error above, you have changed the database password between deployments, which is not supported. If you need to change the password, follow the steps to remove the delete the data in the volume.

Warning: Changing the database password will delete your Supply Chain Security Tools - Store data.

Persistent Volume Retains Data

Symptom

If Supply Chain Security Tools - Store is deployed, deleted, and then redeployed the metadata-store-db pod fails to start up if the database password changed during redeployment. This is due to the persistent volume used by postgres retaining old data, even though the retention policy is set to DELETE.

Solution

If you need to redeployed the app, either use the same database password, or follow these steps below to erase the data on the volume:

  1. deploy metadata-store app (via kapp)
  2. watch the metadata-store-db-* pod fail
  3. kubectl exec -it metadata-store-db-<some id> -n metadata-store /bin/bash
  4. rm -rf /var/lib/postgresql/data/* (path found in postgres-db-deployment.yaml) - This should delete all database data
  5. delete the metadata-store app via kapp
  6. deploy metadata-store app (via kapp)

Where:

  • some id: Is the ID generated by Kubernetes and appended to the pod name.

Querying local path source reports

Symptom

If a source report has a local path as the name (ex: /path/to/code), the leading / on the resulting repository name will cause the querying packages and vulnerabilities to return the following error from the client lib and the CLI:

{ "message": "Not found" }`.

The URL of the resulting HTTP request is properly escaped. For example, /api/sources/%2Fpath%2Fto%2Fdir/vulnerabilities. The rbac-proxy used for authentication, handles this URL in a way that the response is a redirect (ex: HTTP 301\nLocation: /api/sources/path/to/dir/vulnerabilities). The Client Lib follows the redirect, making a request to the new URL which does not exist in the Supply Chain Security Tools - Store API, resulting in the error message above.

No support for installing in custom namespaces

All of our testing uses the metadata-store namespace. Using a different namespace breaks authentication and certificate validation for the metadata-store api.

Deploying for Internal/External customers

Using imgpkg copy command copies the image bundle along with all images it references to a target repository. This is very useful as it ensures the images used in the bundle are always available, even if the images in where they originally came from are no longer available (since there is now a copy in the target repo.)

To deploy the bundle, run the following command:

imgpkg copy -b <bundle image registry>:<bundle version tag> --to-repo <target image registry repo>/

where:

  • bundle image registry is the registry where the image bundle currently will be copied from
  • bundle version tag is the image bundle version tag to copy
  • target image registry repo is where the image bundle and all associated images will be copied to