Background

During a recent deployment at an organization using SELinux in enforcing mode, we encountered issues that required special configuration. The deployment required adding Kubernetes pod security context settings to address SELinux constraints (using seLinuxOptions with specific type and level values).

Requirements

1. Add SELinux configuration to Helm chart values:

   • Add SELinux options to values.yaml with sensible defaults (type: container_t, level: "s0")
   • Allow users to disable SELinux configuration by setting the value to null
   • Ensure the Pod template only includes SELinux options when they're not null

2. Create Kubernetes-specific SELinux configuration documentation:

   • Document the Helm chart SELinux configuration options
   • Provide examples of how to enable/disable SELinux options
   • Document the default configuration and its purpose

3. Improve error messaging:

   • Ensure error messages are descriptive when permission is denied
   • Clearly indicate what operation was attempted (e.g., loading eBPF program)
   • Add context that helps users identify SELinux as a potential cause

4. Add tests for SELinux configurations:

   • Test that the collector is denied with standard restricted policy (null SELinux options)
   • Test that the collector works with the default SELinux options
   • Document test results for reference

Acceptance Criteria

• SELinux configuration added to Helm chart values.yaml with sensible defaults
• Template logic to conditionally include SELinux options based on configuration
• Clear documentation added to the project's Helm chart configuration guide
• Successful test demonstrating that:
  • The collector is denied access when SELinux options are null
  • The collector works properly with the default SELinux options
• Error messages improved to clearly indicate what operation was denied

Notes

• The default configuration should work for most SELinux-enabled environments
• Documentation should explain how users can disable the SELinux settings if needed
• We should recommend keeping the default configuration even on systems without SELinux, as it doesn't cause issues
• We welcome contributions from the community for more fine-grained SELinux policies if needed