Strategy for TLS certs/keys in recursive Aurae daemon

[krisnova]

The only thing we need to start auraed in a recursive pod is the PKI material.

There are some trade offs for having the container read from the host from a security perspective.

What is our strategy for getting the cert material into the pod?

• Mount a volume into the pod from /etc/aurae/pki?
• Copy the cert material at runtime during RunPodSandbox() with whatever material is on disk?
• Automatically generate new cert material and keys for each pod from the server CA?

Maybe a better question is do we want to enforce strong identity at the Pod level? If so we likely want each Pod to bring their own Server cert and keys signed by the root CA.

CC @taniwha3 who is our resident TLS expert.

taniwha3: e.g. if something is providing network services, it should have a known identity that binds it to that role

[krisnova]

Logs from recursive auraed running with Youki + musl in #308

2023-01-28T19:04:26.285113Z ERROR auraed: Err(Aurae requires a signed TLS certificate to run as a server, but failed to 
                    load: '/etc/aurae/pki/_signed.server.crt'. Please see https://aurae.io/certs/ for information on best 
                    practices to quickly generate one.

Caused by:
    No such file or directory (os error 2))

[krisnova]

Following up on #308, the examples/pod*.ts file can be used to trigger this error against the main branch.

[JeroenSoeters]

I'm actually running into this exact same issue with the VMs. We need a strategy for provisioning certificates for auraed instances running as PID 1 on VMs.