-
Notifications
You must be signed in to change notification settings - Fork 290
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
exporter Chart v0.9.5 breaks daemonset when PSP is activated #494
Comments
Setting |
The best solution should be configuring the PSP as follows via values.yaml: podSecurityPolicy:
# Specifies whether a PSP, Role and RoleBinding should be created
create: true
# Annotations to add to the PSP, Role and RoleBinding
annotations:
seccomp.security.alpha.kubernetes.io/defaultProfileName: runtime/default
seccomp.security.alpha.kubernetes.io/allowedProfileNames: runtime/default With this annotations, the PSP will allow the seccomp profile set in the default security context introduced in PR #487 |
Hi @hardwarefresser, PodSecurityPolicy was deprecated in Kubernetes |
Totally agree |
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
Stale issues rot after 30d of inactivity. Mark the issue as fresh with Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle rotten |
Will close this as PSPs are now deprecated. |
Describe the bug
PR #487 introduces a security context in values.yaml for falco-exporter which includes a seccomp profile:
When the chart is deployed on an environment with PSP enabled, the PSP delivered with the Chart seems not to allow the Seccomp Profile to be set and therefore prevents the pod admission:
According to this comment, adding
seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
to the PSP annotations should solve the problem. I did a quick test and admission was not prevented anymore.However, as we want to use the seccomp profile
RuntimeDefault
, it would be better to addseccomp.security.alpha.kubernetes.io/allowedProfileNames: 'RuntimeDefault'
as PSP annotation. I will also try this and get back. But I would appreciate of someone could double check the whole issue.Expected behaviour
PSP should not prevent the pods with seccomp
Environment
Additional context
Issue #481
The text was updated successfully, but these errors were encountered: