Not able to build the image due to the base image being in a private registry

[leelavg]

Unable to pull the base image registry.ci.openshift.org/ocp/builder:rhel-9-golang-1.24-openshift-4.21 and fails with authentication required
Error: Podman build failed

[smith-xyz]

@leelavg can you take a look at the docker.local build file to see if that will help. Are you needing something more generic like that in different CI pipeline?

[leelavg]

ack, I'll try with that and not for CI (yet) as we have more than 10 servers spread across multiple repos, want to see how it's working before mandating for other maintainers in DF.

anyways, any reason in not publishing the package to repo ghcr rather than every user needing to do a local build?

[smith-xyz]

oh that would be great - is there anything in ci that helps do that for the openshift org?

[leelavg]

I did this https://github.com/leelavg/sanim/blob/main/.github/workflows/build-image.yml recently, can tweak it to push on certain events or weekly etc, I made it a manual workflow for my project.

As a onetime setting just make sure you make the image public (simple google search would do) after pushing it for first time.

Edit: cancel-in-progress in my workflow should've been true.

[shajmakh]

oh that would be great - is there anything in ci that helps do that for the openshift org?

@smith-xyz Yes, you can use https://github.com/openshift/release, it uses prow configuration to run jobs, and in tls-scanner it can be on PRs' push (postsubmit). It allows mirroring the images to quay registry (see
https://github.com/openshift/release/blob/main/ci-operator/config/openshift-kni/numaresources-operator/openshift-kni-numaresources-operator-main.yaml#L19 and
https://github.com/openshift/release/blob/main/core-services/image-mirroring/openshift-kni/mapping_openshift-kni_quay#L20).

[jcantrill]

oh that would be great - is there anything in ci that helps do that for the openshift org?

@smith-xyz Yes, you can use https://github.com/openshift/release, it uses prow configuration to run jobs, and in tls-scanner it can be on PRs' push (postsubmit). It allows mirroring the images to quay registry (see https://github.com/openshift/release/blob/main/ci-operator/config/openshift-kni/numaresources-operator/openshift-kni-numaresources-operator-main.yaml#L19 and https://github.com/openshift/release/blob/main/core-services/image-mirroring/openshift-kni/mapping_openshift-kni_quay#L20).

openshift/release#78982

[leelavg]

take a look at the docker.local build file

• sry, it didn't help because the tool expects to have lsof in the target container.

nevertheless, I created my own for my usecase https://github.com/leelavg/scantls and the problems that I see with tls-scanner are:

1. requiring lsof in target image
2. custom build step, golang, oc and a lot other dependencies
3. using exec as the main mechanism to reach the target container
4. using testssl for validation, I was excited about this initially and thought the options would include reducing the time it takes to validate even in parallel

all these minor things adds up and increases the overall time to more than a couple of hours for something that could be done under 5 min even with all bells & whistles, anyways my observations are around a month old and probably tls-scanner need to do many other things but the base could be changed.

anyways, always open to be corrected, my intention is to raise the pain points and suggest alternate methods.

[smith-xyz]

@leelavg

Thanks for the feedback and for sharing your tool. Acknowledged:

1. lsof: we exec it into target pods for process name mapping. Falls back to /proc/net/tcp when unavailable, but agree it should be skippable/documented better.

2. exec for discover: adds latency. Your nsenter approach avoids this.

3. Performance: biggest gap. testssl gives comprehensive audit (full cipher enum, vuln scanning, cert chain, compliance) but at cost. It also bundles its own OpenSSL build that intentionally supports deprecated/insecure ciphers so it can detect servers still offering them — system OpenSSL won't negotiate those. For "does port X support TLS 1.3 + cipher Y?" openssl s_client is dramatically faster, but it can only test what your system OpenSSL supports.

For targeted scans (your "10 servers" use case), --targets host1:443,host2:8443 or --namespace-filter ns1,ns2 skips cluster-wide discovery entirely. Full cluster scans are for compliance audit; targeted scans complete in minutes.

Differences worth noting:

• tls-scanner correlates scans against cluster TLS profiles for compliance
• Produces JUnit for CI pipelines
• Doesn't require privileged DaemonSet (hostPID, CRI socket, SYS_ADMIN)

I think having a fast mode is worth a feature (a simple go dial could do to quickly test something), if it is done properly that gives a user more flexibility in scanning/reporting.

Open to contributions on these items so that the tool is more accessible.

[leelavg]

ack, I differ with some of the points, however just presenting them might only make my points strong but that's not a solution and I strongly want to include tls-scanner, I'm adding this to my todo and circle back whenever I've any contributions. thanks!