Uploaded image for project: 'OpenShift Request For Enhancement'
  1. OpenShift Request For Enhancement
  2. RFE-7159

Add support for generic ephemeral volumes configuration in SecuredCluster CR for RHACS sensor

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Unresolved
    • Icon: Blocker Blocker
    • None
    • None
    • rhacs, rhacs-operator
    • None
    • Future Sustainability
    • None
    • True
    • Hide

      None

      Show
      None
    • None
    • None
    • None

      Description:

      Currently, the RHACS sensor pod uses emptyDir for ephemeral storage, which can lead to high storage utilization on nodes (observed at 184MB). Customers need the ability to configure generic ephemeral volumes through the SecuredCluster custom resource when using GitOps deployment methods, rather than directly modifying pod or deployment configurations.

      In customer words:

      We have a Rule alerting if a container uses a lot ephemeral storage.

      --- "Pod "sensor-5f4d" in namespace "XXX" has a ephemeral storage usage of 184 MB.  Please reduce usage or use generic ephemeral volume instead." ---

      We would like to be able to configure a generic ephemeral volume instead of an emptydir for the acs-sensor.

      Goal Summary:

      Enable customers to configure generic ephemeral volumes for RHACS sensors through the SecuredCluster CR, providing better storage management and resource utilization in GitOps environments.

      Goals and expected user outcomes:

      Primary users: Platform Engineers and Security Teams managing RHACS through GitOps

      Expected outcomes:

      • Ability to configure generic ephemeral volumes through SecuredCluster CR
      • Better control over sensor storage allocation
      • Reduced node storage pressure
      • Improved compatibility with GitOps workflows
      • Consistent storage management across cluster fleet

      Acceptance Criteria:

      1. Technical Requirements:

      • Add support for generic ephemeral volume configuration in SecuredCluster CR
      • Maintain backward compatibility with existing deployments
      • Support standard storage class configurations
      • Enable storage resource limits and requests specification

      2. Functional Requirements:

      • Allow specification of volume size
      • Support storage class selection
      • Enable access mode configuration
      • Preserve existing sensor functionality

      3. Non-functional Requirements:

      • Security: Maintain existing security context and permissions
      • Performance: No degradation in sensor performance
      • Reliability: Ensure stable storage operations
      • Maintainability: Clear documentation and upgrade path
      • Scalability: Support for multi-cluster deployments
      • Usability: Simple configuration syntax in SecuredCluster CR

      Success Criteria or KPIs measured:

      1. Technical Metrics:

      • Zero regression in sensor functionality
      • Successful deployment across different storage classes
      • Proper cleanup of resources when pods are terminated

      2. Operational Metrics:

      • Reduced number of storage-related alerts
      • Decreased node storage pressure
      • Improved storage utilization efficiency

      3. User Experience Metrics:

      • Successful GitOps deployments using new configuration
      • Reduced manual intervention in storage management
      • Positive feedback from GitOps users

      ref: [-https://issues.redhat.com/browse/ROX-28013-]

      slack: https://redhat-internal.slack.com/archives/C028JE84N59/p1737560324111829

              saledort@redhat.com Sabina Aledort
              rhn-support-vyoganan Vivek Yoganand A (Inactive)
              None
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                None
                None