Support for composite variables in Workflow Surveys

[stahloss]

ISSUE TYPE

• Add support for composite variables in Workflow Surveys

SUMMARY

It would be really nice to create composite variables when calling Workflows from other Workflows. In the example below, OMGEVING is a variable defined in the parent Workflow, that should be usable in variable values of child flows. This is a feature that is supported by Azure DevOps and proves to be very convenient in several use cases.

[wenottingham]

See the ALLOW_JINJA_IN_EXTRA_VARS setting; there are some complexities to allowing templating here as you need to avoid security issues.

At a practical level, you'd need to interpret and template these variables in a place that is currently unaware of their content at all. It's a larger change than it looks.

[eliranw]

I work in a very large enterprise company, and we also need a solution for this problem. We tried adding Jinja templating in the extra_vars section of the workflow, and the workflow couldn't parse them as well. Our only solution was to add another text field in the workflow's survey, and manually input another variable, or add logic into the playbooks themselves - both solutions which obviously aren't so user or developer friendly

[rfedida]

It's super important feature to have user friendly workflows

[stahloss]

@wenottingham Maybe Jinja is overkill for this.

We just need to be able to reference other variables that are defined in parent Workflows. In Azure DevOps you do this as follows $(SomeVariable)-$(SomeOtherVariable).

[stahloss]

I tried to set always for ALLOW_JINJA_IN_EXTRA_VARS to see if it can be used in Workflows, but got the following error while running a Job containing Jinja in extra vars. Setting it back to template resolves the error.

Traceback (most recent call last): File "/var/lib/awx/venv/awx/lib/python3.6/site-packages/awx/main/tasks.py", line 1382, in run self.build_extra_vars_file(self.instance, private_data_dir) File "/var/lib/awx/venv/awx/lib/python3.6/site-packages/awx/main/tasks.py", line 1809, in build_extra_vars_file if job.job_template and settings.ALLOW_JINJA_IN_EXTRA_VARS == 'template': File "/var/lib/awx/venv/awx/lib/python3.6/site-packages/awx/conf/settings.py", line 500, in __getattr_without_cache__ return getattr(self._wrapped, name) File "/var/lib/awx/venv/awx/lib/python3.6/site-packages/awx/conf/settings.py", line 413, in __getattr__ value = self._get_local(name) File "/var/lib/awx/venv/awx/lib/python3.6/site-packages/awx/conf/settings.py", line 345, in _get_local field = self.registry.get_setting_field(name) File "/var/lib/awx/venv/awx/lib/python3.6/site-packages/awx/conf/registry.py", line 134, in get_setting_field field_instance = field_class(**field_kwargs) File "/var/lib/awx/venv/awx/lib/python3.6/site-packages/rest_framework/fields.py", line 1442, in __init__ super().__init__(**kwargs) File "/var/lib/awx/venv/awx/lib/python3.6/site-packages/rest_framework/fields.py", line 333, in __init__ assert not (read_only and required), NOT_READ_ONLY_REQUIRED AssertionError: May not set both `read_only` and `required` 

Seems simply changing the variable doesn't work.

[wenottingham]

Sorry, more clearly:

The reason I brought up that setting is that the reason it exists is because allowing jinja templating based on user-supplied data can lead to arbitrary python code execution. You probably don't want that, and whatever you'd do for templating variables will at least need to do as much as what that setting does for jinja templates in other areas of AWX.

[stahloss]

Sorry, more clearly:

The reason I brought up that setting is that the reason it exists is because allowing jinja templating based on user-supplied data can lead to arbitrary python code execution. You probably don't want that, and whatever you'd do for templating variables will at least need to do as much as what that setting does for jinja templates in other areas of AWX.

The only thing that needed to be clarified in my view was whether or not the 'always' setting of ALLOW_JINJA_IN_EXTRA_VARS allowed me to use Jinja everywhere, including Workflow templates extra vars and maybe even Surveys. But seems that answer is 'no', because setting 'always' breaks the application.

Arbitrary code execution is not something you want, but can't it be sanitized, like it is with the use of Jinja within Job template extra vars?

We can continue at the moment, because we're able to use Jinja in Job Templates, but it would be nice to be able to use it everywhere it makes sense.

[WimpyMan]

This is an issue that we are facing as well.