-
Notifications
You must be signed in to change notification settings - Fork 567
Private Registry Authentication
When a container runtime is not present, Syft can still utilize credentials configured in common credential sources (such as ~/.docker/config.json
). It will pull images from private registries using these credentials. The config file is where your credentials are stored when authenticating with private registries via some command like docker login
. For more information see the go-containerregistry
documentation.
An example config.json
looks something like this:
{
"auths": {
"registry.example.com": {
"username": "AzureDiamond",
"password": "hunter2"
}
}
}
You can run the following command as an example. It details the mount/environment configuration a container needs to access a private registry:
docker run -v ./config.json:/config/config.json -e "DOCKER_CONFIG=/config" anchore/syft:latest <private_image>
Here's a simple workflow to mount this config file as a secret into a container on Kubernetes.
-
Create a secret. The value of
config.json
is important. It refers to the specification detailed here. Below this section is thesecret.yaml
file that the pod configuration will consume as a volume. The keyconfig.json
is important. It will end up being the name of the file when mounted into the pod.# secret.yaml apiVersion: v1 kind: Secret metadata: name: registry-config namespace: syft data: config.json: <base64 encoded config.json>
kubectl apply -f secret.yaml
-
Create your pod running syft. The env
DOCKER_CONFIG
is important because it advertises where to look for the credential file. In the below example, settingDOCKER_CONFIG=/config
informs syft that credentials can be found at/config/config.json
. This is why we usedconfig.json
as the key for our secret. When mounted into containers the secrets' key is used as the filename. ThevolumeMounts
section mounts our secret to/config
. Thevolumes
section names our volume and leverages the secret we created in step one.# pod.yaml apiVersion: v1 kind: Pod metadata: name: syft-k8s-usage spec: containers: - image: anchore/syft:latest name: syft-private-registry-demo env: - name: DOCKER_CONFIG value: /config volumeMounts: - mountPath: /config name: registry-config readOnly: true args: - <private_image> volumes: - name: registry-config secret: secretName: registry-config
kubectl apply -f pod.yaml
-
The user can now run
kubectl logs syft-private-registry-demo
. The logs should show the Syft analysis for the<private_image>
provided in the pod configuration.
Using the above information, users should be able to configure private registry access without having to do so in the grype
or syft
configuration files. They will also not be dependent on a Docker daemon, (or some other runtime software) for registry configuration and access.
The ability to convert existing SBOMs means you can create SBOMs in different formats quickly, without the need to regenerate the SBOM from scratch, which may take significantly more time.
syft convert <ORIGINAL-SBOM-FILE> -o <NEW-SBOM-FORMAT>[=<NEW-SBOM-FILE>]
This feature is experimental and data might be lost when converting formats. Packages are the main SBOM component easily transferable across formats, whereas files and relationships, as well as other information Syft doesn't support, are more likely to be lost.
We support formats with wide community usage AND good encode/decode support by Syft. The supported formats are:
- Syft JSON (
-o syft-json
) - SPDX 2.2 JSON (
-o spdx-json
) - SPDX 2.2 tag-value (
-o spdx-tag-value
) - CycloneDX 1.4 JSON (
-o cyclonedx-json
) - CycloneDX 1.4 XML (
-o cyclonedx-xml
)
Conversion example:
syft alpine:latest -o syft-json=sbom.syft.json # generate a syft SBOM
syft convert sbom.syft.json -o cyclonedx-json=sbom.cdx.json # convert it to CycloneDX