Restricting Kata Agent API
Building block for confidential containers with Kata
The latest release ( 2.3.0) of Kata containers runtime added support to dynamically configure the kata-agent behaviour using a configuration file. This is an important building block towards the eventual use of Kata containers as a confidential container runtime leveraging VM Trusted Execution Environments (TEE).
Check out https://github.com/confidential-containers for more details on confidential-containers with Kubernetes
The kata-agent communicates with the host using gRPC API, via a vsock channel. The container runtime running on the host sends commands to the kata-agent running inside the VM using this mechanism.
Now, in a confidential computing scenario using VM TEE, the host software stack is not part of the VM TCB and consequently, the interface between the host and VM needs to be hardened, keeping in mind the threat model and usability.
This is where restricting the kata-agent API comes into the picture.
In the current implementation, a configuration file is added to the VM root filesystem (eg. initrd image). This ensures that the configuration file is part of verified TCB measurement in the confidential computing scenario.
Special shoutout to Samuel for implementing this functionality. Check out the details in the following PR — https://github.com/kata-containers/kata-containers/pull/2517
Here is a short demo showing the feature in action:
If you want to try out this feature in your existing Kata environment please read along.
Steps
Ensure you are using 2.3.0 or later release of Kata containers runtime.
Build Kata VM rootfs
The steps are taken from the official documentation which is available here.
mkdir -p ${GOPATH}/src/github.com
cd ${GOPATH}/src/github.com
git clone https://github.com/kata-containers/kata-containersexport ROOTFS_DIR=${GOPATH}/src/github.com/kata-containers/kata-containers/tools/osbuilder/rootfs-builder/rootfsexport distro="ubuntu"rm -fr $ROOTFS_DIRcd $GOPATH/src/github.com/kata-containers/kata-containers/tools/osbuilder/rootfs-builderscript -fec 'sudo -E GOPATH=$GOPATH USE_DOCKER=true AGENT_INIT=yes SKOPEO_UMOCI=yes SECCOMP=yes -r ${ROOTFS_DIR} ${distro}'
Add kata-agent API configuration in the rootfs
cd $ROOTFS_DIRcat <<EOF >> etc/config.toml
# Agent API configuration# Following endpoints are blocked and not part of the allowed list.# "ExecProcessRequest"
# "ReseedRandomDevRequest"allowed = [
"AddARPNeighborsRequest",
"AddSwapRequest",
"CloseStdinRequest",
"CopyFileRequest",
"CreateContainerRequest",
"CreateSandboxRequest",
"DestroySandboxRequest",
"GetMetricsRequest",
"GetOOMEventRequest",
"GuestDetailsRequest",
"ListInterfacesRequest",
"ListRoutesRequest",
"MemHotplugByProbeRequest",
"OnlineCPUMemRequest",
"PauseContainerRequest",
"PullImageRequest",
"ReadStreamRequest",
"RemoveContainerRequest",
"ResumeContainerRequest",
"SetGuestDateTimeRequest",
"SignalProcessRequest",
"StartContainerRequest",
"StartTracingRequest",
"StatsContainerRequest",
"StopTracingRequest",
"TtyWinResizeRequest",
"UpdateContainerRequest",
"UpdateInterfaceRequest",
"UpdateRoutesRequest",
"WaitProcessRequest",
"WriteStreamRequest"
]
EOF
Create initrd
cd $GOPATH/src/github.com/kata-containers/kata-containers/tools/osbuilder/initrd-builderscript -fec 'sudo -E AGENT_INIT=yes USE_DOCKER=true ./initrd_builder.sh ${ROOTFS_DIR}'
An initrd named kata-containers-initrd.img will be created.
Modify Kata configuration file
Add the agent.config_file param in the kernel_params option.
kernel_params = "<other-kernel-params> agent.config_file=/etc/config.toml "Also, ensure you update the initrd option to point to the newly built image under the hypervisorsection.
[hypervisor.qemu]
...
initrd = "<path-to-newly-built-kata-containers-initrd.img>"
...That’s it. You can now deploy a Kata POD and try to exec a shell. It’ll be denied.
In subsequent posts, I’ll touch upon container image encryption and decryption, attestation approaches, and other related topics.
