krata
krata copied to clipboard
krata is an isolation engine built for securing workloads
Presently the IDM bus is brokered by kratad on dom0. We should move it into a helper domain.
Presently IDM messages lack a qualified namespace for invoked methods/responses. We should move our responses to something that can be qualified, for example `krata.dev/metrics` instead of `metrics`.
Building on #75, we should move the image packing/unpacking to the proposed helper domain infrastructure to remove it from dom0.
Presently, krata uses scratch space on the dom0 environment to do things like unpack and repack images. We should migrate these operations to dedicated helper domains to derisk them. The...
For workloads which do not require a TTY, we should have the guestinit set up stdin/stdout/stderr multiplexing over IDM and use that instead of `/dev/console`. This allows `/dev/console` to be...
In order to capture debug logs from containers, we should have the guestinit bind a unix socket at `/dev/log`, where it will receive syslog messages, and relay those over the...
In order to allow for more expressive security policies, Flask-style (as seen in SELinux/TrustedBSD/Solaris) security labels should be applicable to guests, including default-inherited ones set by the hypervisor.
Add support to krata for exporting metrics via opentelemetry.
It is intended in the future that guests are able to send IDM messages to each other along the IDM bus. We should document (and obviously write code to enforce)...
We especially want to encode that guests are disallowed from making requests from the host for obvious security reasons. This does not mean that guests might not make some kinds...