cc @dashpole (listed in the KEP as the instrumentation reviewer) and @logicalhan (who had questions about cardinality in the implementing PR)

lgtm

made coherent with the current implementation and the audit tracking issue in kubernetes/kubernetes#103923

Existing and in the case where an ephemeral container tries to add CAP_SYS_PTRACE, the baseline policy will reject?

Not sure I parsed your question correctly, but:

• ephemeral containers themselves must pass the current enforce level
• adding/updating an ephemeral container is considered a relevant update which requires the whole pod (existing containers) to pass the current enforce level

I expect CAP_SYS_PTRACE to be a common request for debugging, and I was even considering making it the default if we decide to adopt debugging profiles (#2834). Does PTRACE enable a privilege escalation?

Since ephemeral containers cannot be removed, it sounds like it's possible for a pod to fail the current enforce level even if the ephemeral container is no longer running, blocking future updates that would otherwise be allowed at this level. Is that desirable?

I think it's fine for my intended use of breaking glass to debug a pod and then deleting the pod soon afterwards, but I don't think I've thought through all the scenarios yet.

Since ephemeral containers cannot be removed, it sounds like it's possible for a pod to fail the current enforce level even if the ephemeral container is no longer running, blocking future updates that would otherwise be allowed at this level. Is that desirable?

I think so? Some of the changes an escalated ephemeralContainer could make could persist even after the ephemeral container is no longer running. Presence of an ephemeral container in a pod that doesn't fit within the current enforce level seems like it should be rejected, even if it is not running.

There are basically 3 operations that would trigger a pod to be reevaluated, and potentially block the update:

1. Change the seccomp annotation - deprecated behavior that will be removed soon.
2. Updating the container image - goes against best practices
3. Adding an ephemeral container

So, if an exempt user adds a privileged ephemeral container, the pod enters a "violating" state, and non-exempt users can no longer perform any of those updates. This seems reasonable to me.

One way this could be handled under the current model is:

1. Exempt a special username (not one that can be authenticated directly) from policy enforcement,
   e.g. ops:privileged-debugger
2. Grant the special user permission to ONLY operate on the ephemeral containers subresource (it is
   critical that they cannot create or update pods directly).
3. Grant (real) users that should have privileged debug capability the ability to impersonate the
   exempt user.

I still think it's useful to document this workflow somewhere. This behavior would be a bit more intuitive if we had group exemptions (impersonate the breakglass group), but the workflow doesn't change that much as long as RBAC bindings are mostly granted to groups.

I expect CAP_SYS_PTRACE to be a common request for debugging, and I was even considering making it the default if we decide to adopt debugging profiles (#2834). Does PTRACE enable a privilege escalation?

Since ephemeral containers cannot be removed, it sounds like it's possible for a pod to fail the current enforce level even if the ephemeral container is no longer running, blocking future updates that would otherwise be allowed at this level. Is that desirable?

I think it's fine for my intended use of breaking glass to debug a pod and then deleting the pod soon afterwards, but I don't think I've thought through all the scenarios yet.