[Feature] Wildcard matching for signing kernel modules in a specific folder

[yansun1996]

https://kmm.sigs.k8s.io/documentation/secure_boot/ described the process of how to automate the signing process of kernel modules, but there is a field called filesToSign, and it is saying we must provide full path to the kernel modules that we want to sign.

The problems are:

1. Given a specific kernel module, we may also need to sign the dependent kernel modules if the host node doesn't have those dependent kernel modules.
2. With different Linux kernels the dependency graph may differ a lot.

So I'm asking a feature, can we just provide a folder path or some kind of wildcard match template, so that the KMM image signing pod could auto detect the .ko files within the folder, or matched the template and sign all of them ?

[yevgeny-shnaidman]

@yansun1996 as long as we are talking about .ko file inside the container image, it is probably a good feature to add. Let us discuss it internally, and we will provide further feedback

[yansun1996]

yep @yevgeny-shnaidman , it would be better if the signimage pod could auto select .ko files given a folder, or given a wildcard match template

[yevgeny-shnaidman]

@ybettan seems like a useful feature to add. It will probably require adding a field to the Sign section of Module CRD and probably splitting the Dockefile.sign into 2 possible Dockerfiles (or any other solution, since Dockerfiles do not have the IF clause

[yansun1996]

yep, just make sure we have a way to sing all selected .ko files within a folder, or given a template matching path.

The Linux kernel could change and the users specific kmod dependency graph could change as well, if we just specify the specific file paths for the kernel modules, they could change with the new major version of Linux kernel then we have to change the kernel modules signing paths again and again. Supporting the requested feature would help.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale