We are undertaking a significant shift-left initiative and have mandated that all container builds must be scanned prior to deployment. To maintain control, ensure availability, and comply with data sovereignty requirements, we operate a fully internal, air-gapped container registry (a mirrored instance of JFrog Artifactory). Our Black Duck instance is configured with the standard Docker registries (Docker Hub, GCR, etc.), but it consistently fails to authenticate and scan images from our internal registry.
From an integration architecture perspective, the data flow is broken at the authentication and endpoint configuration layer. The Black Duck scan client (or the Synopsys Detect tool) does not seem to recognize our custom registry URL, and the documentation on configuring custom Docker registries is fragmented across several knowledge base articles.
My primary questions are about the precise configuration mapping:
1. **Authentication Method:** Is the supported method strictly a `.docker/config.json` file placed on the scan client host, or are there alternative methods for supplying credentials (e.g., environment variables, command-line parameters to Synopsys Detect) that are more suitable for CI/CD pipelines? The security team is particular about where credentials are stored.
2. **Registry URL Specification:** Must the custom registry be declared within a `blackduck-docker-registries.json` file, or is there a more dynamic method? Our registry uses a non-standard port (`:8082/docker-proxy`) and a self-signed certificate, which adds complexity.
3. **Certificate Trust:** For self-signed certificates, does the Java truststore for the Black Duck scan client need to be modified, or is it sufficient to set `DOCKER_DAEMON_CERT_PATH` or similar environment variables?
I have attempted a configuration based on inferred patterns from the documentation. The following is my current, non-working `blackduck-docker-registries.json` template:
```json
{
"registries": [
{
"url": "https://artifactory.internal.domain:8082",
"repository": "docker-proxy",
"credentials": {
"username": "service_account",
"password": "encrypted_password"
}
}
]
}
```
And the corresponding `.docker/config.json` for the same host:
```json
{
"auths": {
"artifactory.internal.domain:8082": {
"auth": "base64_encoded_credentials"
}
},
"HttpHeaders": {
"User-Agent": "Docker-Client/19.03.12 (linux)"
}
}
```
Despite this, the scan logs indicate `Failed to get docker image manifest for [artifactory.internal.domain:8082/docker-proxy/my-image:latest]` with a `401 Unauthorized` error. This suggests either the credential mapping is incorrect, the registry path is malformed, or the certificate is not trusted.
I am seeking a detailed, step-by-step workflow for mapping an internal registry into Black Duck's scanning pipeline, including the order of operations for certificate handling, credential injection, and URL parsing. A comparison of the effectiveness of the `blackduck-docker-registries.json` method versus relying solely on the Docker daemon's configuration would also be highly valuable.