-
Notifications
You must be signed in to change notification settings - Fork 360
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
using non-privileged containers for kubearmor daemonset #781
Comments
Results of scans from kubescape & trivy kubescape scanningkubescape scanning
trivy scanningtrivy scanning
Note: Results can differ in your case. I'm using kind cluster in GitHub codespaces. |
Hey folks, came here from the LFX mentorship projects and I'd like to contribute to this. Any help on where to get started? |
[copying the update provided by @kranurag7 on kubearmor slack here...] Here is the update of what I have done till now.
What I'm doing now?
What I have not done till now?
|
AWS FTR (Foundational Tech Review) requires that privilege mode not be used by the deployment (issue #891). |
@kranurag7 , can we close this issue? I guess the cluster-role-binding could be separate issue?> |
Feature Request
Short Description
Privileged containers are usually frowned upon. Almost every static scanning engine will flag this as an issue. In lot of cases, orgs also deploy admission controllers that would not allow containers to be installed in priviledged mode.
Kubearmor currently uses privileged mode for its daemonset containers.
It is best to not use privileged mode, but to use specific capabilities for kubearmor.
Describe the solution you'd like
Use specific capabilities in place of privileged mode. Cilium recently added this mode as well.
Tasks
privilege: true
from the deployment and drop all caps and enable specific required capskube-system
namespaceThe text was updated successfully, but these errors were encountered: