Open PhilipSchmid opened 2 years ago
It looks like a good idea, but it may have some side effects (which I don't recall by heart).
@falcosecurity/deploy-kubernetes-maintainers and @falcosecurity/charts-maintainers wdyt? also cc @alacuku
I like the idea and I can't remember of any other use case (apart from syscalls) where root
is required, so +1 from me
Looks a good idea to me too. Moreover, what about enabling also to select specific capabilities, still avoiding uid 0?
We can write a helper that is evaluated when the syscall event source is disabled. Users can still overwrite the default behavior by setting the podSecurityContext
.
+1 from me!
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
Will implement this in the next days. Sorry for the delay.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten
/remove-lifecycle rotten
/help
@leogr: This request has been marked as needing help from a contributor.
Please ensure the request meets the requirements listed here.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help
command.
Sorry I'm not using Falco anymore and I therefore won't implement this any time soon. If anybody wants to implement it, please feel free to take it over 😉 .
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale /assign @alacuku
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale
/remove-lifecycle stale
Motivation
With the introduction of the new Falco plugin system and the new 2.X Helm charts, it's not always really required to run the Falco pod as root. Nevertheless, Falco still does this which could often violate security policies (PSP, OPA, etc.).
Feature
I think it would make sense to introduce a flag which allows one to configure (or simply override?) the used service user from root to something else. I think we could even by default set the user to
UID 1000
whenever the syscall event source is disabled. Of course, I would still add a values.yaml flag to override this default behavior in case some plugins still have the requirement to run as root.Alternatives
At the moment this could already be done via the following Helm values but there's probably a nicer way to do that automatically (as mentioned above, e.g. whenever the syscall event source is disabled):
Additional context
Please let me know what you think about that. If you agree, I could create a PR in the near future.
Thanks & regards, Philip