set securityContext's from values

[dmaes]

I actually needed #90 , but since it hasn't had any activity since over a year, and is making multiple changes (that IMHO should be split into different PR's) at once, I've created this simple change that gives users the flexibility to overwrite the securityContext definitions, while at the same time not breaking any existing deployments.

[github-actions]

@dmaes: There are no 'kind' label on this PR. You need a 'kind' label to generate the release automatically.

• /kind feature
• /kind enhancement
• /kind fix
• /kind chore
• /kind dependencies

Details

I am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the forked project rr404/oss-governance-bot repository.

[github-actions]

@dmaes: There are no area labels on this PR. You can add as many areas as you see fit.

• /area agent
• /area local-api
• /area cscli
• /area security
• /area configuration

Details

I am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the forked project rr404/oss-governance-bot repository.

[dmaes]

/kind enhancement
/area configuration

[fwmarcel]

I am also interested in this PR.

[dajeffers]

It'd also be nice to add pod level security context for parameters like fsGroup, otherwise one can run into problems when running the container as non-root:

cp: can't create directory '/etc/crowdsec_data/collections': Permission denied

[dmaes]

@dajeffers, I added pod security context's as well

[BriceMichalski]

Hello team, 👋

First of all, thank you so much for the amazing work on CrowdSec and maintaining these Helm charts! It's a fantastic security tool.

I wanted to check if there is any update on this PR? It has been open for a while now, and it addresses a critical deployment blocker for those of us running CrowdSec in strict environments with SELinux enabled.

Currently, the inability to override securityContext and podSecurityContext directly from the values.yaml prevents us from applying targeted SELinux profiles (e.g., custom profiles generated via udica).

What makes this even more critical is that the current chart doesn't even allow setting privileged: true as a temporary (albeit dirty) fallback. Because of this complete lockdown, users are left with no choice but to:
• Maintain local forks of the entire chart.
• Rely on heavy infrastructure workarounds like Kustomize post-rendering.

Merging this PR would finally unblock these environments and allow us to properly secure the agent using the principle of least privilege.

Is there anything blocking the merge right now ?

cc @dmaes @sabban @blotus @mmetc

[blotus]

Hey,

Sorry for the delay, totally forgot about this PR.

Merged, and I'll try to release a new version in the next few days.

[BriceMichalski]

Thanks a lot!