Feature Overview

This feature proposes a strategic shift in how Red Hat Advanced Cluster Management (RHACM) Policy-based Governance handles sprig functions within its templating engine. Instead of maintaining a finite, tightly controlled list of allowed functions, the approach will change to enabling all functions by default and using a deny-list to explicitly disable those that pose security risks or are otherwise inappropriate. This will expand the capabilities for policy authors while maintaining a strong security posture.

Goals

This Section: Provide high-level goal statement, providing user context
and expected user outcome(s) for this feature

• Significantly expand the number of available sprig functions for policy authors, providing greater flexibility for complex templates.
• Shift the maintenance strategy from an allow-list to a deny-list to simplify the process of adding new functions.
• Perform a comprehensive security review of all available sprig functions to identify and disable those that could lead to vulnerabilities or information leakage.
• Establish a clear, documented process for managing the deny-list in future releases.

Requirements

This Section: A list of specific needs or objectives that a Feature must
deliver to satisfy the Feature.. Some requirements will be flagged as MVP.
If an MVP gets shifted, the feature shifts. If a non MVP requirement slips,
it does not shift the feature.

(Optional) Use Cases

This Section:

• Main success scenarios - high-level user stories
  • As a policy author, I can use a wider range of sprig functions for string manipulation, list processing, and mathematical operations to create more dynamic and flexible policies.
  • As a security administrator, I am confident that the templating engine will not allow policies to execute functions that could compromise the system, even with the expanded list.

• Alternate flow/scenarios - high-level user stories
  • ...

Questions to answer

• Do we expose the deny-list to the user to configure additional functions to block?

Out of Scope

• The feature does not involve an exhaustive redesign of the entire templating engine, but rather focuses on a change in the function management strategy.
• The implementation does not include all sprig functions by default; it is a shift to a deny-list strategy after a security review. Functions that are deemed fundamentally unsafe or inappropriate will be on the initial deny-list.

Background, and strategic fit

This Section: What does the person writing code, testing, documenting
need to know? What context can be provided to frame this feature?

The Policy-based Governance feature is a core component of RHACM, with templating via ConfigurationPolicy being a critical user feature. The current strategy of maintaining a restrictive allow-list has led to repeated requests from users for new functions, creating a bottleneck and limiting the expressiveness of policies. A deny-list approach is a common security mechanism that allows through all elements except those explicitly mentioned. This new strategy will streamline the development process and empower users while proactively addressing security concerns. For example, functions that access the host system like env or expandenv could pose an information leakage risk and should be considered for the deny-list. Similarly, cryptographic functions could be inappropriate for policy templates. This change aligns with the broader goal of making RHACM more flexible and powerful for advanced users.

Assumptions

• A thorough security review can identify all potentially dangerous or inappropriate functions within the sprig library.
• The overhead of managing a deny-list will be less than the current process of individually approving and adding functions to an allow-list.
• The core templating engine can be configured to selectively disable a specific list of functions.

Customer Considerations

• Customers will get immediate access to a wider set of functions, reducing the need to submit feature requests for every new template need.
• This change simplifies the policy authoring experience and allows for more advanced use cases.
• The documentation of the deny-list will be crucial for managing customer expectations and ensuring they understand why certain functions are not available.

Documentation Considerations

Questions to be addressed:

• What educational or reference material (docs) is required to support this
  product feature? For users/admins? Other functions (security officers, etc)?
  • A comprehensive reference for policy authors on all available and denylisted functions.
• Does this feature have a doc impact?
  • Yes, we will need to adjust the topic related to the support sprig functions
• New Content, Updates to existing content, Release Note, or No Doc Impact
  • Updates to existing content
• If unsure and no Technical Writer is available, please contact Content
  Strategy.
  • N/A
• What concepts do customers need to understand to be successful in
  [action]?
  • The new deny-list strategy.
  • The purpose of common sprig functions like string, list, and math functions.

• How do we expect customers will use the feature? For what purpose(s)?
  • To create more complex and dynamic policies that can handle various data formats and logic.
• What reference material might a customer want/need to complete [action]?
  • Should include references / links to the sprig function library documentation
  • Our documentation should include the above link and then the list of deny-listed functions and their reason.
• Is there source material that can be used as reference for the Technical
  Writer in writing the content? If yes, please link if available.
  • See existing sprig function documentation
• What is the doc impact (New Content, Updates to existing content, or
  Release Note)?
  • Updates to existing content: A rewrite of the Policy Templating documentation to reflect the new strategy and denied functions.
  • Release Note: A release note announcing the major expansion of available templating functions.