Is there any way to mark config_context variables as safe

[etrombly]

At some point ansible started marking variables from external sources as __ansible_unsafe. I use templated values in my config contexts pretty extensively, so this makes netbox basically useless for inventory now. Is there any way to work around this so values are templated correctly?

For now I just pinned ansible to 11.11.0, they made the change in 12.0.0

[sc68cal]

Can you share a little more detail about this? Are you saying that your config contexts, themselves contain Jinja2 template placeholders? Can you share a config context for us to examine?

[sc68cal]

The configuration can't be rendered by netbox because I'm doing lookups to a vault server, the login token is hosted on the machine I'm running ansible from, I don't want the netbox server to be able to access the vault instance.

So, then you need to recognize that there are parts of your configuration that need to be rendered using the appropriate NetBox feature and then parts that you are going to have to use Ansible to fetch the secret and update the configuration with.

You were relying on Ansible executing Jinja2 that was embedded in resources fetched remotely. This was never really supposed to have been relied upon and the Ansible team has removed that behavior for good reason.

I would have to research but I don't even know if we have any ability to untaint something that has been marked as unsafe. Even if we were technically able, I'm not in favor of implementing that.

[sc68cal]

The only other thing I can think of doing is pulling down the config context, writing it to a file and then passing that file path to Ansible as the src for a template directive. Still you are leaving yourself open to remote code execution on the Ansible controller and would strongly recommend not doing this.

[etrombly]

So we've been using netbox as our single source of truth for configuration. If we want to know how something is configured we look there. Ansible then applies the configuration that is defined in netbox. I would prefer not having to tell my other admins to look in git for part of the config, then look in netbox for another part. At that point we may as well just get rid of netbox entirely and just go back to storing everything in git.

I understand the security implications. If someone with access to the netbox server replaced one of the variables with something like {{ lookup('ansible.builtin.pipe', 'rm -rf /*') }} then that command would be run on whatever host the task was executing on. But my netbox server is under my control, with proper authentication and security. If someone is able to access netbox and change the config context then my environment has already been exploited anyway. I understand that it may be a way for an attacker to extend their footprint in my network, but I think the end user should be allowed to evaluate their level of risk acceptance and make that decision on their own.

[sc68cal]

I understand your frustration but this change was required due to https://nvd.nist.gov/vuln/detail/CVE-2023-5764 and the mitigation that the Ansible core team decided upon, makes it where your method of managing this, is no longer possible the way you had previously used in the past. I have attempted to provide some solutions to help mitigate this change and allow you to proceed forward, but at the end of the day there's not much else I can offer you. Sorry.

[sc68cal]

@etrombly I want to give you an update, #1411 is tracking this now, thanks to @efazenda for bringing up how to mark things as safe for templating, so that this can now be possible. I think as long as we have some sort of way for the user to opt-in to the behavior, I am ok with merging code that enables it. I just want to keep a safe default of not marking it as safe for templating, to preserve the principal of least surprise

[etrombly]

great news. I appreciate it. I think having it an opt in makes sense.