githedgehog / k8s-tpm-device-plugin Goto Github PK

Currently the helm chart creates a service account and mounts credentials. However, this is (at least at this point in time), not a requirement at all.

We should consider to remove it completely and remove a mount of a service account credential altogether.

This repo still needs CI integration using github actions which build and test, and also publish and release on tags.

Well, that's kind of a bummer. I simply used our company as the base name for the devices (githedgehog.com/tpmrm), but that's not really "correct" IMHO.

Input welcome on how that should be changed.

I find that the example specified in your README does not work on my particular version of kubernetes.

How to produce the problem

• install Kubernetes 1.26.04 on an Ubuntu 23.04 (lunar) substrate
• use the standard kubeadm based deployment running on top of docker.io
• deploy the helm chart for k8s-tpm-device-plugin as usual
• create the example pod (zero capabilities etc) with a pre-installed version of tpm2-tools
• confirm that the pod has zero capabilities assigned (capsh --print or check /proc/1/status inside the container)

root@tpm-device-test:/# cat /proc/1/status | grep CapPrm
CapPrm: 0000000000000000

• run tpm2_pcrread or some other tpm2 tool and confirm that it fails with an "access denied" error:

root@tpm-device-test:/# tpm2_pcrread
ERROR:tcti:src/tss2-tcti/tcti-device.c:452:Tss2_Tcti_Device_Init() Failed to open specified TCTI device file /dev/tpmrm0: Permission denied 
ERROR:tcti:src/tss2-tcti/tctildr-dl.c:154:tcti_from_file() Could not initialize TCTI file: libtss2-tcti-device.so.0 
ERROR:tcti:src/tss2-tcti/tcti-device.c:452:Tss2_Tcti_Device_Init() Failed to open specified TCTI device file /dev/tpm0: No such file or directory 
ERROR:tcti:src/tss2-tcti/tctildr-dl.c:154:tcti_from_file() Could not initialize TCTI file: libtss2-tcti-device.so.0 
WARNING:tcti:src/util/io.c:262:socket_connect() Failed to connect to host ::1, port 2321: errno 99: Cannot assign requested address 
ERROR:tcti:src/tss2-tcti/tcti-swtpm.c:614:Tss2_Tcti_Swtpm_Init() Cannot connect to swtpm TPM socket 
ERROR:tcti:src/tss2-tcti/tctildr-dl.c:154:tcti_from_file() Could not initialize TCTI file: libtss2-tcti-swtpm.so.0 
WARNING:tcti:src/util/io.c:262:socket_connect() Failed to connect to host ::1, port 2321: errno 99: Cannot assign requested address 
ERROR:tcti:src/tss2-tcti/tctildr-dl.c:154:tcti_from_file() Could not initialize TCTI file: libtss2-tcti-mssim.so.0 
ERROR:tcti:src/tss2-tcti/tctildr-dl.c:254:tctildr_get_default() No standard TCTI could be loaded 
ERROR:tcti:src/tss2-tcti/tctildr.c:428:Tss2_TctiLdr_Initialize_Ex() Failed to instantiate TCTI 
ERROR: Could not load tcti, got: "(null)"

Proposed fix

• Add one capability to the example pod.

    ...
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
        add: ["CAP_DAC_OVERRIDE"] <--------this will allow directory access for tpm2-tools

• Confirm that the started pod has the added capability:

root@tpm-device-test:/# cat /proc/1/status | grep CapPrm
CapPrm: 0000000000000002

• Test that tpm2_pcrread now works correctly.

WTF, no tests?! Who wrote this software.

Mea culpa, but the plugin was so easy/simple at this point that the integration testing on a Kubernetes cluster was all that was necessary so far.

This is really one of the core pieces missing where I'm not sure yet what or if it is necessary to do at all.

Kubernetes device plugins have a concept of device health. Currently the implementation reports every device simply as "Healthy".

There are things to consider on how to check the TPM device health:

• for the /dev/tpm0 device we could check if it is actually being used by the host and mark it as "Unhealthy" if it is
• consider running regular "health checks" on the TPM device which could show if the device is truly "Healthy" or not - I'm not sure though what would constitue a good health check here. It also might need elevated privileges for the device plugin container which begs the question if that tradeoff is worth it

Still something that needs to be discussed internally, but putting this out here already: we should consider moving this project under the keylime organization. That is pending Hedgehog internal approval as well as keylime orgs willingness to take it on of course.