fix #58: Honor pod labels for identifiying a component by jcantrill · Pull Request #59 · openshift/tls-scanner

jcantrill · 2026-05-08T15:43:51Z

This PR:

fixes Scanner does identify 'component' using the existing order of precedence #58 by honoring a pod's labels when determining the component
fixes the inconsistency between the component scanresult and componen-filter arg

jcantrill · 2026-05-08T15:50:43Z

The produced output when setting component filter to 'cluster-logging-operator,eventrouter,log-file-metric-exporter,vector'. It matched the pod being tested and produced results but the component name still looks off

{
  "timestamp": "2026-05-08T15:34:06Z",
  "total_ips": 1,
  "scanned_ips": 1,
  "ip_results": [
    {
      "ip": "10.129.0.44",
      "status": "scanned",
      "open_ports": [
        8443
      ],
      "port_results": [
        {
          "port": 8443,
          "protocol": "tcp",
          "state": "open",
          "service": "ssl/tls",
          "tls_versions": [
            "TLSv1.3"
          ],
          "tls_ciphers": [
            "TLS_AES_256_GCM_SHA384",
            "TLS_CHACHA20_POLY1305_SHA256",
            "TLS_AES_128_GCM_SHA256"
          ],
          "tls_key_exchange": {
            "forward_secrecy": {
              "supported": true,
              "ecdhe": [
                "TLS_AES_256_GCM_SHA384",
                "TLS_CHACHA20_POLY1305_SHA256",
                "TLS_AES_128_GCM_SHA256"
              ],
              "kems": [
                "X25519MLKEM768"
              ]
            }
          },
          "status": "OK",
          "reason": "TLS scan successful",
          "api_server_tls_config_compliance": {
            "configured_profile": "Default",
            "version": true,
            "ciphers": true
          },
          "tls13_supported": true,
          "mlkem_supported": true,
          "mlkem_kems": [
            "X25519MLKEM768"
          ],
          "all_kems": [
            "X25519MLKEM768"
          ],
          "tls_readiness": {
            "tls13_offered": true,
            "tls12_only": false,
            "pqc_capable": true,
            "mlkem_kems": [
              "X25519MLKEM768"
            ],
            "all_kems": [
              "X25519MLKEM768"
            ],
            "notes": "Endpoint offers TLS 1.3 and ML-KEM — ready for Modern profile"
          }
        }
      ],
      "openshift_component": {
        "component": "origin-cluster-logging-operator:log8967_tls_scanner",
        "source_location": "internal-registry",
        "maintainer_component": "user",
        "is_bundle": false
      },
      "pod": {
        "Name": "cluster-logging-operator-84b79df75f-55t5f",
        "Namespace": "openshift-logging",
        "Image": "image-registry.openshift-image-registry.svc:5000/openshift/origin-cluster-logging-operator:log8967_tls_scanner",
        "IPs": [
          "10.129.0.44"
        ],
        "Containers": [
          "cluster-logging-operator"
        ]
      }
    }
  ],
  "tls_security_config": {
    "api_server": {
      "type": "Default",
      "min_tls_version": "VersionTLS12",
      "ciphers": [
        "TLS_AES_128_GCM_SHA256",
        "TLS_AES_256_GCM_SHA384",
        "TLS_CHACHA20_POLY1305_SHA256",
        "ECDHE-ECDSA-AES128-GCM-SHA256",
        "ECDHE-RSA-AES128-GCM-SHA256",
        "ECDHE-ECDSA-AES256-GCM-SHA384",
        "ECDHE-RSA-AES256-GCM-SHA384",
        "ECDHE-ECDSA-CHACHA20-POLY1305",
        "ECDHE-RSA-CHACHA20-POLY1305"
      ]
    }
  }
}

jcantrill · 2026-05-08T17:33:36Z

/retest

jcantrill · 2026-05-08T19:27:48Z

Added another commit to resolve component name discrepency which produced:

{
  "timestamp": "2026-05-08T19:23:35Z",
  "total_ips": 3,
  "scanned_ips": 3,
  "ip_results": [
    {
      "ip": "10.129.0.48",
      "status": "scanned",
      "open_ports": [
        8443
      ],
      "port_results": [
        {
          "port": 8443,
          "protocol": "tcp",
          "state": "open",
          "service": "ssl/tls",
          "tls_versions": [
            "TLSv1.3"
          ],
          "tls_ciphers": [
            "TLS_AES_256_GCM_SHA384",
            "TLS_CHACHA20_POLY1305_SHA256",
            "TLS_AES_128_GCM_SHA256"
          ],
          "tls_key_exchange": {
            "forward_secrecy": {
              "supported": true,
              "ecdhe": [
                "TLS_AES_256_GCM_SHA384",
                "TLS_CHACHA20_POLY1305_SHA256",
                "TLS_AES_128_GCM_SHA256"
              ],
              "kems": [
                "X25519MLKEM768"
              ]
            }
          },
          "status": "OK",
          "reason": "TLS scan successful",
          "api_server_tls_config_compliance": {
            "configured_profile": "Default",
            "version": true,
            "ciphers": true
          },
          "tls13_supported": true,
          "mlkem_supported": true,
          "mlkem_kems": [
            "X25519MLKEM768"
          ],
          "all_kems": [
            "X25519MLKEM768"
          ],
          "tls_readiness": {
            "tls13_offered": true,
            "tls12_only": false,
            "pqc_capable": true,
            "mlkem_kems": [
              "X25519MLKEM768"
            ],
            "all_kems": [
              "X25519MLKEM768"
            ],
            "notes": "Endpoint offers TLS 1.3 and ML-KEM — ready for Modern profile"
          }
        }
      ],
      "openshift_component": {
        "component": "cluster-logging-operator",
        "source_location": "internal-registry",
        "maintainer_component": "user",
        "is_bundle": false
      },
      "pod": {
        "Name": "cluster-logging-operator-7b89dd4967-frzh4",
        "Namespace": "openshift-logging",
        "Image": "image-registry.openshift-image-registry.svc:5000/openshift/origin-cluster-logging-operator:log8967_tls_scanner",
        "IPs": [
          "10.129.0.48"
        ],
        "Containers": [
          "cluster-logging-operator"
        ]
      }
    },
    {
      "ip": "10.129.0.53",
      "status": "scanned",
      "open_ports": [
        2112
      ],
      "port_results": [
        {
          "port": 2112,
          "protocol": "tcp",
          "state": "open",
          "service": "ssl/tls",
          "tls_versions": [
            "TLSv1.2",
            "TLSv1.3"
          ],
          "tls_ciphers": [
            "ECDHE-RSA-AES256-GCM-SHA384",
            "ECDHE-RSA-CHACHA20-POLY1305",
            "ECDHE-RSA-AES128-GCM-SHA256",
            "TLS_AES_256_GCM_SHA384",
            "TLS_CHACHA20_POLY1305_SHA256",
            "TLS_AES_128_GCM_SHA256"
          ],
          "tls_key_exchange": {
            "forward_secrecy": {
              "supported": true,
              "ecdhe": [
                "TLS_AES_256_GCM_SHA384",
                "TLS_CHACHA20_POLY1305_SHA256",
                "ECDHE-RSA-AES256-GCM-SHA384",
                "ECDHE-RSA-CHACHA20-POLY1305",
                "TLS_AES_128_GCM_SHA256",
                "ECDHE-RSA-AES128-GCM-SHA256"
              ],
              "kems": [
                "X25519MLKEM768"
              ]
            }
          },
          "status": "OK",
          "reason": "TLS scan successful",
          "api_server_tls_config_compliance": {
            "configured_profile": "Default",
            "version": true,
            "ciphers": true
          },
          "tls13_supported": true,
          "mlkem_supported": true,
          "mlkem_kems": [
            "X25519MLKEM768"
          ],
          "all_kems": [
            "X25519MLKEM768"
          ],
          "tls_readiness": {
            "tls13_offered": true,
            "tls12_only": false,
            "pqc_capable": true,
            "mlkem_kems": [
              "X25519MLKEM768"
            ],
            "all_kems": [
              "X25519MLKEM768"
            ],
            "notes": "Endpoint offers TLS 1.3 and ML-KEM — ready for Modern profile"
          }
        }
      ],
      "openshift_component": {
        "component": "logfilesmetricexporter",
        "source_location": "quay.io",
        "maintainer_component": "redhat",
        "is_bundle": false
      },
      "pod": {
        "Name": "logfilesmetricexporter-tzlr8",
        "Namespace": "openshift-logging",
        "Image": "quay.io/openshift-logging/log-file-metric-exporter:latest",
        "IPs": [
          "10.129.0.53"
        ],
        "Containers": [
          "logfilesmetricexporter"
        ]
      }
    },
    {
      "ip": "10.128.0.105",
      "status": "scanned",
      "open_ports": [
        2112
      ],
      "port_results": [
        {
          "port": 2112,
          "protocol": "tcp",
          "state": "open",
          "service": "ssl/tls",
          "tls_versions": [
            "TLSv1.2",
            "TLSv1.3"
          ],
          "tls_ciphers": [
            "ECDHE-RSA-AES256-GCM-SHA384",
            "ECDHE-RSA-CHACHA20-POLY1305",
            "ECDHE-RSA-AES128-GCM-SHA256",
            "TLS_AES_256_GCM_SHA384",
            "TLS_CHACHA20_POLY1305_SHA256",
            "TLS_AES_128_GCM_SHA256"
          ],
          "tls_key_exchange": {
            "forward_secrecy": {
              "supported": true,
              "ecdhe": [
                "TLS_AES_256_GCM_SHA384",
                "TLS_CHACHA20_POLY1305_SHA256",
                "ECDHE-RSA-AES256-GCM-SHA384",
                "ECDHE-RSA-CHACHA20-POLY1305",
                "TLS_AES_128_GCM_SHA256",
                "ECDHE-RSA-AES128-GCM-SHA256"
              ],
              "kems": [
                "X25519MLKEM768"
              ]
            }
          },
          "status": "OK",
          "reason": "TLS scan successful",
          "api_server_tls_config_compliance": {
            "configured_profile": "Default",
            "version": true,
            "ciphers": true
          },
          "tls13_supported": true,
          "mlkem_supported": true,
          "mlkem_kems": [
            "X25519MLKEM768"
          ],
          "all_kems": [
            "X25519MLKEM768"
          ],
          "tls_readiness": {
            "tls13_offered": true,
            "tls12_only": false,
            "pqc_capable": true,
            "mlkem_kems": [
              "X25519MLKEM768"
            ],
            "all_kems": [
              "X25519MLKEM768"
            ],
            "notes": "Endpoint offers TLS 1.3 and ML-KEM — ready for Modern profile"
          }
        }
      ],
      "openshift_component": {
        "component": "logfilesmetricexporter",
        "source_location": "quay.io",
        "maintainer_component": "redhat",
        "is_bundle": false
      },
      "pod": {
        "Name": "logfilesmetricexporter-xp6kq",
        "Namespace": "openshift-logging",
        "Image": "quay.io/openshift-logging/log-file-metric-exporter:latest",
        "IPs": [
          "10.128.0.105"
        ],
        "Containers": [
          "logfilesmetricexporter"
        ]
      }
    }
  ],
  "tls_security_config": {
    "api_server": {
      "type": "Default",
      "min_tls_version": "VersionTLS12",
      "ciphers": [
        "TLS_AES_128_GCM_SHA256",
        "TLS_AES_256_GCM_SHA384",
        "TLS_CHACHA20_POLY1305_SHA256",
        "ECDHE-ECDSA-AES128-GCM-SHA256",
        "ECDHE-RSA-AES128-GCM-SHA256",
        "ECDHE-ECDSA-AES256-GCM-SHA384",
        "ECDHE-RSA-AES256-GCM-SHA384",
        "ECDHE-ECDSA-CHACHA20-POLY1305",
        "ECDHE-RSA-CHACHA20-POLY1305"
      ]
    }
  }
}

smith-xyz · 2026-05-14T15:49:29Z

/rebase

openshift-ci · 2026-05-14T16:12:41Z

@jcantrill: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/default-tls	`af27cf2`	link	false	`/test default-tls`

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

jcantrill · 2026-05-16T02:22:58Z

/retest

smith-xyz

I like the pipeline added here, I think maybe we can reorganize it some and ensure that we're not short circuiting any potential labelling.

To me I'm thinking maybe it should be image first, label override second vs labels first, image fallback.

smith-xyz · 2026-05-18T13:11:15Z

-			slog.Warn("could not get component for image", "image", pod.Image, "error", err)
+		// Extract component from pod labels (or fall back to image parsing)
+		var componentName string
+		if pod.Pod != nil && len(pod.Pod.Spec.Containers) > 0 {


This unconditionally overrides the image-derived component name, but extractComponentFromPod can fall back to container.Name which may be less informative than the image name (e.g. "logfilesmetricexporter" vs "log-file-metric-exporter"). Maybe this should only override when a label actually matches?

I'm not certain what the "correct" logic should be but assuming the image name has first priority is not accurate. This assumes the name of the image will always be the component name. As an example, the CLO image at one time (or maybe still is) "cluster-logging-operator-rhel-9-image". The more correct solution, IMO would be if we had some way of pulling a Label from the compiled image given we already add a label for most production images

This unconditionally overrides the image-derived component name

I do not believe this is relevant. The crux of the issue this PR fixes is component name consistency for scanned workloads. The intent is to match the discovered workloads to scan results and ensure the client knows what to expect. This was the mismatch I discovered where I was expecting some result and received none.

but extractComponentFromPod can fall back to container.Name which may be less informative than the image name (e.g. "logfilesmetricexporter" vs "log-file-metric-exporter"). Maybe this should only override when a label actually matches?

Maybe but this is debatable. The switch says it is for the following:

-component-filter <names> - Filter pods by component name (comma-separated, used with -all-pods)

The component name is what the person running the scanner is expecting. It probably depends who is the target audience. I'm using it in the cluster logging operator project and I have many images that need to be scanned. The component name is important to me for running it; not the interpreted image name as the component.

Whatever the logic "should be" needs to provide a consistent component and we should document what the order of precedence is

Ahh I see what you're saying, okay maybe we can just make this the de factor answer then. Could you add a doc comment on extractComponentFromPod noting the resolution order (app label > component label > app.kubernetes.io/name > container name > image name)? That way users of -component-filter know what to expect.

this lgtm though so can get it merged after that

jcantrill · 2026-05-18T19:07:57Z

/label tide/merge-method-squash

openshift-ci · 2026-05-18T19:07:57Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: jcantrill
Once this PR has been reviewed and has the lgtm label, please ask for approval from smith-xyz. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

openshift-ci Bot requested review from richardsonnick and smith-xyz May 8, 2026 15:44

openshift-ci Bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 14, 2026

jcantrill added 2 commits May 14, 2026 12:03

fix openshift#58: Honor pod labels for identifiying a component

ef53c7a

fix inconsistency between component-filter values and scanreport

884a9c2

jcantrill force-pushed the issue58 branch from 4b8aa6e to 884a9c2 Compare May 14, 2026 16:04

openshift-ci Bot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 14, 2026

fix compile after rebase

d25004d

smith-xyz requested changes May 18, 2026

View reviewed changes

openshift-ci Bot assigned smith-xyz May 18, 2026

jcantrill mentioned this pull request May 18, 2026

LOG-8967: Add TLS Scanner e2e test openshift/cluster-logging-operator#3269

Open

fix code reviews

e5f7690

openshift-ci Bot added the tide/merge-method-squash Denotes a PR that should be squashed by tide when it merges. label May 18, 2026

smith-xyz mentioned this pull request May 19, 2026

fix: dedup and assemble scan job results based on pod namespace and name too #65

Merged

Conversation

jcantrill commented May 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jcantrill commented May 8, 2026

Uh oh!

jcantrill commented May 8, 2026

Uh oh!

jcantrill commented May 8, 2026

Uh oh!

smith-xyz commented May 14, 2026

Uh oh!

openshift-ci Bot commented May 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jcantrill commented May 16, 2026

Uh oh!

smith-xyz left a comment

Choose a reason for hiding this comment

Uh oh!

smith-xyz May 18, 2026

Choose a reason for hiding this comment

Uh oh!

jcantrill May 18, 2026

Choose a reason for hiding this comment

Uh oh!

smith-xyz May 18, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jcantrill commented May 18, 2026

Uh oh!

openshift-ci Bot commented May 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

jcantrill commented May 8, 2026 •

edited

Loading

openshift-ci Bot commented May 14, 2026 •

edited

Loading