Uploaded image for project: 'OpenShift Pipelines'
  1. OpenShift Pipelines
  2. SRVKP-6620

Enable "securityContext" to be set by end user in Openshift-Pipelines

XMLWordPrintable

    • False
    • None
    • False

      < High-Level description of the feature ie: Executive Summary >

      Goals

      What are the nature and description of the request?

      We are using RedHat ACS and got notified, that the eventlistener has some security violations. We would like to implement the RedHat recommended improvements, but this does not work out of the box. So, this feature is for letting the users configure the settings under securityContext, so that they can fix it themselves.

      The eventlistener should be configured by default with a read-only root file system and drop all the capabilities

      Why does the customer need this? (List the business requirements here)

      The Eventlistener does generate security violations with the default configuration, and is not fixable. This has a security impact.

      How would the customer like to achieve this? (List the functional requirements here)

      In order to fix the security violations, the eventlistener should be configured by default with a read-only root file system and drop all the capabilities, or otherwise let the users configure the settings under securityContext, so that the can fix it themselves.

       

       

      Requirements

      Requirements Notes IS MVP
           
        • (Optional) Use Cases

      < What are we making, for who, and why/what problem are we solving?>

      Out of scope

      <Defines what is not included in this story>

      Dependencies

      < Link or at least explain any known dependencies. >

      Background, and strategic fit

      < What does the person writing code, testing, documenting need to know? >

      Assumptions

      < Are there assumptions being made regarding prerequisites and dependencies?>

      < Are there assumptions about hardware, software or people resources?>

      Customer Considerations

      < Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>

      Documentation Considerations

      < What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >

      What does success look like?

      < Does this feature have doc impact? Possible values are: New Content, Updates to existing content, Release Note, or No Doc Impact?>

      QE Contact

      < Are there assumptions being made regarding prerequisites and dependencies?>

      < Are there assumptions about hardware, software or people resources?>

      Impact

      < If the feature is ordered with other work, state the impact of this feature on the other work>

      Related Architecture/Technical Documents

      <links>

      Done Checklist

      • Acceptance criteria are met
      • Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
      • User Journey automation is delivered
      • Support and SRE teams are provided with enough skills to support the feature in production environment

              Unassigned Unassigned
              rhn-support-gio Ginilekshmi A O
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: