Description
In Kubernetes, fsGroup in a Pod’s securityContext is designed to ensure that mounted volumes are accessible by setting group ownership. However, this doesn’t apply to NFS-mounted volumes, leading to silent permission failures.
Despite being a long-standing issue, it's still frequently encountered. We'd like a reproducible test case and a rule-based method for detecting when this issue occurs in real-world clusters.
To complete this bounty, you must:
- Reproduce the Issue
- Provide a minimal, working example that shows how fsGroup fails to apply to an NFS volume.
The example should clearly demonstrate that:
- fsGroup is set.
- The Pod fails due to file permission issues when writing to the NFS mount.
- Provide a Detection Rule
A reliable detection rule, following the CRE format, that can be used by preq to flag affected applications.
Deliverables
- Reproducible test setup (helm charts, README, shell script, or equivalent).
- Test data in a test.log file
- A link to a working CRE in the (CRE playground)[https://play.prequel.dev]
/bounty $250
Rule
No response
Related issues or PRs
kubernetes/examples#260
References
No response
Redacted Example Data
No response
Description
In Kubernetes, fsGroup in a Pod’s securityContext is designed to ensure that mounted volumes are accessible by setting group ownership. However, this doesn’t apply to NFS-mounted volumes, leading to silent permission failures.
Despite being a long-standing issue, it's still frequently encountered. We'd like a reproducible test case and a rule-based method for detecting when this issue occurs in real-world clusters.
To complete this bounty, you must:
The example should clearly demonstrate that:
A reliable detection rule, following the CRE format, that can be used by preq to flag affected applications.
Deliverables
/bounty $250
Rule
No response
Related issues or PRs
kubernetes/examples#260
References
No response
Redacted Example Data
No response