document support for using a custom certificate with Docker image via Golang's SSL_CERT_FILE and SSL_CERT_DIR

[ChetRHosey]

Is your feature request related to a problem? Please describe.
Our environment requires the use of a custom root certificate for calls to the public Internet.

The Docker image can be used in this type of environment by setting SSL_CERT_FILE and mounting the certificate within the container.

But the option isn't currently documented.

The documented invocation for the Docker image results in messages like the following:

2024/08/09 19:07:27 [WARNING] failed to install provider "azurerm" for directory /tf because of errors registry service is unreachable, check https://status.hashicorp.com/ for status updates

Golang makes it easy to reference custom trust stores. I was able to make this work with an invocation like the following:

docker pull bridgecrew/yor

docker run --tty --volume /local/path/to/tf:/tf --volume /local/path/to/root.crt:/crt/root.crt:ro -e SSL_CERT_FILE=/crt/root.crt bridgecrew/yor tag --directory /tf

Or as an alternative:

docker run --tty --volume /local/path/to/tf:/tf --volume /local/path/to/cert/dir:/crt:ro -e SSL_CERT_DIR=/crt bridgecrew/yor tag --directory /tf

This makes the organization's certificate(s) available within the container and uses Golang's SSL_CERT_FILE or SSL_CERT_DIR to override its default trust settings.

Describe the solution you'd like
Document the use of SSL_CERT_FILE and SSL_CERT_DIR to support custom trust requirements.

Describe alternatives you've considered
I'd abandoned two initial suggestions:

• call update-ca-certificates from the entrypoint script, so that users could mount custom certificates in /usr/local/share/ca-certificates
• update Yor to accept an argument like Checkov's --ca-certificate

The first option would work reasonably but would make it less likely that the image could be run as a nonroot user.

I'd begun exploring the second before realizing that Golang already offered a built-in option to get the same behavior.

One could argue that recommending the use of SSL_CERT_FILE/SSL_CERT_DIR breaks encapsulation and creates a dependency on implementation. It would even be possible for an entrypoint script to look for a "--ca-certificate" option, set SSL_CERT_FILE if a value is found, and strip it from the options passed to Yor.

However even if Golang's functionality changed or Yor were to be ported to another language, it would be trivial to use SSL_CERT_DIR or SSL_CERT_FILE in a way that's appropriate for future implementations. So the risk of documenting their use is fairly low.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.