You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 30, 2024. It is now read-only.
In the current situation kubeaudit just audit for the fact that any capability is dropped or not. It does not take into account any specific capability.
This feature will introduce a flag through which a user would be able to specify that which caps should be dropped necessarily. And kubeaudit will error if those caps are not dropped instead of just giving a warning.
I think my preferred solution would be if you could put all the information in a label, e.g. kubeaudit.cap.allow = sys_chroot and then kubeaudit would not bug you about it because it knows that the capability is actually needed and should be set.
This would be a great way not only for capabilities but for everything else. There might be containers that need a read-write filesystem or need to run as root. And labels would give us the opportunity to actually make sure we don't complain about things that are legitimately not up to the tightest security standards.
In the current situation kubeaudit just audit for the fact that any capability is dropped or not. It does not take into account any specific capability.
This feature will introduce a flag through which a user would be able to specify that which caps should be dropped necessarily. And kubeaudit will error if those caps are not dropped instead of just giving a warning.
What do you say @jonpulsifer @klautcomputing ?
The text was updated successfully, but these errors were encountered: