Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

secretTemplate not usable without additional functions #412

Closed
anbrsap opened this issue Mar 28, 2024 · 1 comment · Fixed by #416
Closed

secretTemplate not usable without additional functions #412

anbrsap opened this issue Mar 28, 2024 · 1 comment · Fixed by #416

Comments

@anbrsap
Copy link

anbrsap commented Mar 28, 2024

Problem Description

With #398 support for custom secret templates for ServiceBindings has been added.

Compared to our proposal in #373 secret templates do not have any functions available other than those provided by the Go template engine itself.

Without additional functions:

  • (A) The generated output may be unexpected or invalid YAML.
  • (B) Data from the context cannot be transformed into the needed form.
  • (C) Due to (A) a security issue may arise.

Consequently, the secret template feature is not usable for us.

Examples for (A)

Goal: Set stringData.my_key to the string provided in credentials.attr1.

Below various template variants are shown that all provide unexpected or invalid results for certain input values, as shown for (only) one example input value.

A proper solution requires an additional quote function:

stringData:
  my_key: {{ credentials.attr1 | quote }}

Template variants:

  • Naive

    Template:

    stringData:
      my_key: {{ credentials.attr1 }}

    Example value of credentials.attr1 is ~ (string)

    Output:

    stringData:
      my_key: ~

    -> my_key is null instead of "~".

    Output with quote function would be correct:

    stringData:
      my_key: "~"
  • Use double quotes

    Template:

    stringData:
      my_key: "{{ credentials.attr1 }}"

    Example value of credentials.attr1 is a"b (string)

    Output:

    stringData:
      my_key: "a"b"

    -> Invalid YAML: Line 2: Unexpected characters near "b"".

    Output with quote function would be correct:

    stringData:
      my_key: "a\"b"
  • Use single quotes

    Template:

    stringData:
      my_key: '{{ credentials.attr1 }}'

    Value of credentials.attr1 is a'b (string)

    Output:

    stringData:
      my_key: 'a'b'

    -> Invalid YAML: Line 4: Unexpected characters near "b'".

    Output with quote function would be correct:

    stringData:
      my_key: "a'b"
  • Use block scalar

    Template:

    stringData:
      my_key: >
        {{ credentials.attr1 }}

    Value of credentials.attr1 is a\n b (multi-line string)

    Output:

    stringData:
      my_key: >
        a
       b

    -> Invalid YAML: Line 4: Unable to parse.

    Output with quote function would be correct:

    stringData:
      my_key: "a\n b"

Example for (B)

Goal: Set stringData.my_key to the value of credentials.attr1 serialized as JSON string.

A proper solution requires additional functions toJson and quote:

stringData:
  my_key: {{ credentials.attr1 | toJson | quote }}

Due to the lack of those function the goal cannot be achieved.

Example for (C)

Goal: The secret template should set ENV_VAR1 to the value of credentials.attr1. The secret data is passed as environment variables to the application.

Template:

stringData:
  ENV_VAR1: "{{ credentials.attr1 }}"

Note the incorrect way of quoting due to the lack of a quote function.

The service broker has been hacked and returns attr1 as a"\n FOO_CMD: "echo BOOM!.

Output:

stringData:
  ENV_VAR1: "a"
  FOO_CMD: "echo BOOM!"

-> The attacker injected a process environment variable FOO_CMD with a malicous shell command that the application then executes.

Proposal

In #373 we included Sprig, a library also included by Helm and therefore widely used and field-tested.

We request to add Sprig as we proposed it, i.e. make all non-critical functions available and omit only the critical ones (see #373).

We especially discourage you from implementing functions yourself, because:

  • don't reinvent the wheel
  • users would need to learn your functions and cannot apply their Helm template knowledge
  • you don't know which function users need
@kerenlahav kerenlahav linked a pull request Apr 1, 2024 that will close this issue
@kerenlahav
Copy link
Contributor

Included sprig.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants