how to securely give access to the container to use private key stored in TPM

Question

For a single node Kubernetes cluster on a physical device that has TPM, how do we securely provide access to the container so that it can establish TLS connection using the private key in TPM ? I understand the option if we store them in secrets those can be exposed, but they are not secure as if you can get access to the device, you can get to the secrets. so if the device has TPM that can secure the private key but the container that needs to establish the cert needs to access the private key securely. In windows world this is easier as the certificate manager stores them using the TPM provider framework and the .net application can just reference the certificate for TLS connections. This doesn't seem to be easier in the linux or the container world. Any ideas on how this can be achieved in linux would be helpful!

Answer 1

the container that needs to establish the cert needs to access the private key securely.

Does it, though?

The all idea of a TPM (Trusted Platform Module) is to provide hardware-level security for cryptographic keys. That means, by design, TPM makes sure private keys are never exposed outside the TPM environment, even to the host operating system: the actual private key used for TLS connections is never directly accessible by any process, including those running in the container.

You can use a software in your container that can interact with the TPM on your host machine. That software should be able to communicate with the TPM.

Consider, for instance, tpm2-tools:

FROM ubuntu:latest
RUN apt-get update && apt-get install -y tpm2-tools
# Rest of your container setup

You then mount the TPM device into the container. In Kubernetes, you can do this by modifying your pod specification:

apiVersion: v1
kind: Pod
metadata:
  name: tpm-example
spec:
  containers:
  - name: tpm-container
    image: your-tpm-enabled-container
    volumeMounts:
    - mountPath: /dev/tpm0
      name: tpm
  volumes:
  - name: tpm
    hostPath:
      path: /dev/tpm0
      type: CharDevice

Yes, the container is given controlled access to the TPM device (e.g., /dev/tpm0) via a secure mounting point.
But that only means the container can request the TPM to perform operations like signing or key generation, but it cannot directly access the private key. The actual cryptographic operation (like signing) happens inside the TPM, adhering to the security principles of TPM.

+-----------------------------+
| Kubernetes Node with TPM    |
| +-------------------------+ |
| |      Container          | |
| | +---------------------+ | |
| | |  Application with   | | |
| | | TPM-enabled Software| | |
| | +---|--------------|--+ | |
| |     |              |    | |
| |     |              |    | |
| | TPM device mounted |    | |
| | into the container |    | |
| +-----|--------------+----+ |
|       |                     |
|  TPM <---- Private Key      |
+-----------------------------+

During a TLS handshake, the container's application (acting as a TLS client or server) needs to prove its identity, typically by signing a piece of data with its private key.
Instead of accessing the private key directly, the application requests the TPM to perform this signing operation.
The TPM receives the data, signs it internally, and returns the signature to the application.
That signature is then used in the TLS handshake process, authenticating the application without exposing the private key.

This assumes that the Kubernetes node hosting the TPM and container is secure. And the container's privileges should be minimized to reduce the attack surface.

---

I meant only to securely access for TLS connections, not direct access to private key.
So with the above setup, can the container perform TLS connections using a private key in the TPM?

To enable a container to perform TLS connections using a private key in the TPM without direct access to the key, you would typically use a combination of TPM-aware software and a proxy or intermediary service that interfaces between the container and the TPM.

The container needs software capable of interacting with the TPM. That might be a library or a daemon that understands TPM operations.

Since direct access to the TPM from the container might not be desirable or feasible, an intermediary service on the host can mediate this interaction.
That service communicates with the TPM to perform operations like signing or key generation and exposes these capabilities to the container, possibly through a local network service or API.

When the application in the container needs to establish a TLS connection, it communicates with the intermediary service for cryptographic operations.
The intermediary service requests the TPM to perform the necessary operations (like signing) and returns the results to the container application.

The container should have TLS libraries capable of integrating with this setup, allowing the application to use the cryptographic operations provided by the intermediary service for TLS handshakes.

As an example, consider using tpm2-tss-engine and nginx in a container, with tpm2-tss-engine serving as the intermediary for TLS operations.
In the nginx configuration, specify the use of the tpm2-tss-engine for SSL certificates.

Your Dockerfile would be:

FROM ubuntu:latest
RUN apt-get update && apt-get install -y nginx tpm2-tss-engine openssl
COPY nginx.conf /etc/nginx/nginx.conf
# Additional container setup

Your nginx.conf configuration (as seen in "nginx with TPM based SSL " by [Nonbei Alley](https://blog.salrashid.dev/about/, without Docker but with engine:tpm2tss)) would be:

http {
    server {
        listen              443 ssl;
        server_name         mysite.com;
        ssl_certificate     /etc/ssl/certs/mycert.pem; # Your SSL Certificate
        ssl_certificate_key "engine:tpm2tss:mykey.tpm"; # Key reference in TPM
        # Additional configuration
    }
}

(Note: tpm2-software/tpm2-tss-engine issue 39 on "Import existing keys into TPM for use with OpenSSL" is still pending)

Similar to the previous approach, mount the TPM device into the container in your Kubernetes pod configuration.
Make sure the TPM device is accessible from the host where the Kubernetes pod is running.

That would allow the container to perform TLS operations using a private key in the TPM, with the actual cryptographic operations being handled securely by the TPM, mediated through the tpm2-tss-engine.

---

The proxy approach would work for most, the one which would be challenging is when using a thirdparty sdk(.net core) that does the TLS connection(with AMQP) and not sure if it supports with the TPM configuration. will try this out.
And the proxy container, does it need elevated privileges with TPM ?

True, many SDKs may not have built-in support for directly interacting with a TPM. That is particularly true for high-level frameworks like .NET Core.
An intermediary service can act as a bridge between the SDK and the TPM. That service would handle TPM interactions and present a more standard interface (like an API or a local network service) to the SDK.

The intermediary service could potentially establish the TLS connection on behalf of the .NET application, using the private key in the TPM for authentication. The .NET application would then communicate with this proxy service over a secure local connection.

The proxy or intermediary service needs access to the TPM device. That typically requires the container to have access to the host's TPM device (e.g., via a mounted /dev/tpm0).

Having access to the TPM device might necessitate elevated privileges for the container. However, this should be minimized to what is strictly necessary for TPM interactions. Any container with elevated privileges and access to sensitive hardware like TPM must be securely configured and maintained.