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]

Right but the problem is you are putting Jinja2 templating code inside these config contexts and relying on Ansible evaluating code from a remote source. It never was a good idea to have relied on this.

Isn't this supposed to be what https://netboxlabs.com/docs/netbox/features/configuration-rendering/ is for? That way the configuration gets rendered by the NetBox server with the values filled in, and then you don't have an issue with the data being marked as unsafe.

[etrombly]

The remote source is my netbox server that I fully control, it is 100% trusted. 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.

I totally understand the security implications and the reasoning for the change, but there needs to be an option to mark a 3rd party source as trusted. I'm not just going out to the internet and pulling down random jinja templates to evaluate.

[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.