In v1.25, we plan to graduate the SeccompDefault feature of Kubernetes to beta, which means that is would be enabled by default. By using this feature, the container runtimes would choose the RuntimeDefault profile rather than running unconfined by default.

Part of enabling this feature would be a migration strategy of existing workloads. Right now there is no indication available for end users to understand that a blocked syscall is the reason that their application does not work with RuntimeDefault. It is mostly guessed by evaluating the logs of the container for something like "permission denied".

User Story

As an end user, I'd like to know that my workload stopped because of a blocked syscall when using the RuntimeDefault seccomp profile, so that I can add the syscall to a custom profile based on RuntimeDefault.