# Environment variables prefix with ANSIBLE\_, and AWX **URL:** \ **Category:** Project Discussions\ **Tags:** community-wg, awx, collections\ **Created:** [May 10, 2024, 4:57pm UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737 "2024-05-10T16:57:14Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [May 10, 2024, 4:57pm UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737/1 "2024-05-10T16:57:14Z")
There is a long-standing issue with policy clashes: AWX disallows environment variables starting with `ANSIBLE_` for anything that isn’t coming from ansible-core, while it was decided project wide in 2019 that **all** environment variables defined by plugins or modules for configuration should use the prefix `ANSIBLE_`. This makes it impossible to use certain plugin configurations especially from community collections with AWX. I’m linking to the original discussion here to avoid repeating everything: [Environment variables prefix with ANSIBLE\_, and AWX · Issue #88 · ansible-community/community-topics · GitHub](https://github.com/ansible-community/community-topics/issues/88) One proposal is to add an exception to **not** disallow environment variables starting with `ANSIBLE_COMMUNITY_`, and stick to these for community collections (and potentially other ones). This only works around this problem for community collections, but it’s at least a start 🤷 ---
**Author:** ![Denney-tech](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/denney-tech/32/1556_2.png) [@Denney-tech](https://forum.ansible.com/u/Denney-tech)\ **Post date:** [May 10, 2024, 7:02pm UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737/2 "2024-05-10T19:02:11Z")
So, this seems to apply specifically to the use of custom credentials in AWX. [awx/awx/main/fields.py at devel · ansible/awx (github.com)](https://github.com/ansible/awx/blob/devel/awx/main/fields.py#L853) I would think that plugin environment variables, as a best practice, should use `NAMESPACE_COLLECTION_` prefixes (`COMMUNTIY_GENERAL_`, `COMMUNITY_NETWORK_`, etc). Similar to how we treat role variables. This still presents a presents a problem for the ansible.\* collections, but then AWX could maintain credentials pertaining to ansible.\* collections directly so that custom credentials should never need to be created for them (thus skipping this validation step). Using `ANSIBLE_COMMUNITY_` would be problematic since _that_ is still prefixed with `ANSIBLE_` and therefore AWX would have to account weirdly for exceptions. But I’m no plugin developer, so don’t mind me. ---
**Author:** ![briantist](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/briantist/32/130_2.png) [@briantist](https://forum.ansible.com/u/briantist)\ **Post date:** [May 10, 2024, 7:40pm UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737/3 "2024-05-10T19:40:06Z")
I don’t think we should add a static allowlisted prefix like `ANSIBLE_COMMUNITY_`. As you said it doesn’t really solve for everything. I’m also not in favor of `NAMESPACE_COLLECTION_` prefixes (unless they are `ANSIBLE_NAMESPACE_COLLECTION_` which doesn’t solve the issue), because they don’t have a common prefix; even worse, it makes sense for namespaces to match existing products or companies in some cases, which could have their own defined environment variables that end up with the same prefix. I mentioned this in the original issue: > AWX may have a legitimate security concern, but they could help mitigate this issue by having an allow-list and/or block-list for specific variables that are allowed. I would be in favor of AWX allowing its users to specifically opt-in to allowing certain variables or prefixes; that enabled administrators to make their own choices about what to override. ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [May 10, 2024, 8:03pm UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737/4 "2024-05-10T20:03:49Z")
Using another prefix might also be a solution, like `ANSIBLECONTENT_`. Then you still have the common prefix `ANSIBLE` (without underscore), and everything starting with `ANSIBLE_` is private to ansible-core, and everything starting with `ANSIBLECONTENT_` is not. ---
**Author:** ![sivel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/sivel/32/1198_2.png) [@sivel](https://forum.ansible.com/u/sivel)\ **Post date:** [May 13, 2024, 5:01pm UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737/5 "2024-05-13T17:01:32Z")
fwiw, when we decided to use the `ANSIBLE_` prefix it predated any real use of collections, and I’d argue that indeed in a collection based world it’s wrong for anything not part of ansible-core. Any plugin in an external collection at this point using `ANSIBLE_` as a prefix should probably deprecate it. I’m not a fan of a generic prefix. I think I’d be ok with `___` but I’m not convinced we really need to concern ourselves with any form of enforcement. But with some collections living in the `ansible` namespace, we still have potential problems. Regardless, asking why AWX restricts the env vars seems like a question we should continue pulling at. ---
**Author:** ![Denney-tech](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/denney-tech/32/1556_2.png) [@Denney-tech](https://forum.ansible.com/u/Denney-tech)\ **Post date:** [May 13, 2024, 6:03pm UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737/6 "2024-05-13T18:03:03Z")
> [@sivel](#): > > Regardless, asking why AWX restricts the env vars seems like a question we should continue pulling at. Looks like @AlanCoding added this in [PR #2363](https://github.com/ansible/awx/pull/2363) because documentation claimed the prefix is reserved. [Issue #2359](https://github.com/ansible/awx/issues/2359) This appears to still be the case in the original issue’s linked [documentation.](https://docs.ansible.com/ansible-tower/latest/html/userguide/credential_types.html) ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [May 13, 2024, 6:22pm UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737/7 "2024-05-13T18:22:23Z")
> [@sivel](#): > > I’m not convinced we really need to concern ourselves with any form of enforcement While, at the same time, you’re enforcing that the `ANSIBLE_` prefix is only for ansible-core stuff? SCNR > [@sivel](#): > > when we decided to use the `ANSIBLE_` prefix it predated any real use of collections, and I’d argue that indeed in a collection based world it’s wrong for anything not part of ansible-core. In a collection based world and, additionally, where Ansible means [the Ansible community package](https://pypi.org/project/ansible/) for a lot of people, I suggest that core should move to `ANSIBLE_CORE_` prefix. At least in the long run. And then suggest to collections to use `__$SOMETHING`. Of course, this would mean some work for the core team and would take some time to implement. But what do you think about this? ---
**Author:** ![briantist](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/briantist/32/130_2.png) [@briantist](https://forum.ansible.com/u/briantist)\ **Post date:** [May 13, 2024, 6:41pm UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737/8 "2024-05-13T18:41:54Z")
> [@sivel](#): > > fwiw, when we decided to use the `ANSIBLE_` prefix it predated any real use of collections, and I’d argue that indeed in a collection based world it’s wrong for anything not part of ansible-core. We should be clear that when we talk about the `ANSIBLE_` prefix in this topic, it does not mean that it’s necessarily the entire prefix used in a collection. For example, all of my collection’s env vars use `ANSIBLE_HASHI_VAULT_`. What’s at issue is that AWX cannot/does not have any way to distinguish these since it looks only for `ANSIBLE_`. I don’t agree that it’s wrong for anything outside of core. The `ANSIBLE_` prefix alone should be more about the general product Ansible and not core itself. To that end, > [@mariolenz](#): > > I suggest that core should move to `ANSIBLE_CORE_` prefix. This isn’t such a bad idea, and would be a lot easier to implement than every collection having to change their stuff. AWX can then switch to restricting only `ANSIBLE_CORE_` prefix which seems to be its intention. Of course, there is no actual issue in core either, it’s really only AWX that has a problem, and we could sidestep anyone having to change any prefixes if AWX would allow its own users to selectively decide which vars/prefixes they want to allow to be overridden. > [@briantist](#): > > I mentioned this in the original issue: > > > AWX may have a legitimate security concern, but they could help mitigate this issue by having an allow-list and/or block-list for specific variables that are allowed. > > I would be in favor of AWX allowing its users to specifically opt-in to allowing certain variables or prefixes; that enabled administrators to make their own choices about what to override. ---
**Author:** ![sivel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/sivel/32/1198_2.png) [@sivel](https://forum.ansible.com/u/sivel)\ **Post date:** [May 13, 2024, 9:33pm UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737/9 "2024-05-13T21:33:20Z")
> [@mariolenz](#): > > I suggest that core should move to `ANSIBLE_CORE_` prefix I’m rather confident this won’t ever happen. ansible-core is the _real_ ansible. Unfortunately there were some politics that came into play and we ended up renaming the package, but in the end, ansible-core is the original and real ansible. ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [May 14, 2024, 3:47am UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737/10 "2024-05-14T03:47:32Z")
> [@sivel](#): > > ansible-core is the _real_ ansible. Well, and here we have a lot of disagreement. Ansible is _also_ the name of the whole ecosystem, which includes a lot of other things that have Ansible in name: ansbile-lint, Ansible collections, Ansible roles, the Ansible community, Ansible navigator, Ansible Automation Platform, Ansible creator, etc. And these are just things whose name _starts_ with Ansible, and thus have a similar reason to use environment variables starting with `ANSIBLE_`. ansible-core might contain the real `ansible` CLI tool, use the `ansible` Python module name, etc., but I don’t think it has a special claim on the `ANSIBLE_` prefix for environment variables. ---
**Author:** ![bcoca](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bcoca/32/9269_2.png) [@bcoca](https://forum.ansible.com/u/bcoca)\ **Post date:** [May 16, 2024, 2:55pm UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737/11 "2024-05-16T14:55:24Z")
ansible-config now has a `validate` option that checks all `ANSIBLE_` environment variables and CAN include installed plugins. Sadly this doesn’t fix the older versions, but going forward is a way to check these dynamically vs using a static list. ---
**Author:** ![briantist](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/briantist/32/130_2.png) [@briantist](https://forum.ansible.com/u/briantist)\ **Post date:** [May 17, 2024, 4:05pm UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737/12 "2024-05-17T16:05:21Z")
> [@felixfontein](#): > > Ansible is _also_ the name of the whole ecosystem, which includes a lot of other things that have Ansible in name could not have said it better ---
**Author:** ![samccann](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/samccann/32/18_2.png) [@samccann](https://forum.ansible.com/u/samccann)\ **Post date:** [May 21, 2024, 2:35pm UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737/13 "2024-05-21T14:35:41Z")
Will the real Ansible, pls stand up! (SCNR …mostly just wanted to use that acronym cuz I haven’t seen it before and had to google it) 🤣 So ignoring all the technical/political hurdles - what is the impact on end users if we change any of the existing environment variables? So if `ANSIBLE_HASHI_VAULT_` had to change to something like `ANSIBLECONTENT_HASHI_VAULT`…Is there some magic aliasing that happens for people using the older name or do they all have to change their environment variables when 'whatever change` happens? ---
**Author:** ![bcoca](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bcoca/32/9269_2.png) [@bcoca](https://forum.ansible.com/u/bcoca)\ **Post date:** [May 21, 2024, 3:00pm UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737/14 "2024-05-21T15:00:57Z")
Aside from ‘ansible’ having been overloaded to death, to the point I have to ask people ‘what do you mean by Ansible’ in almost every conversation. The `ANSIBLE_` prefix has already been extensively used, changing it now and making it backwards compatible is a monumental task no matter what your ‘ansible scope’ is. I would argue that creating ‘better tools’ going forward (like ansible-config doing the validation, based on installed plugins) is a better solution than start changing standards. Also, this is a good thing to point at before we create new standards, we should take our time to consider the ramifications, specially when adoption is extended beyond the intention. ANSIBLE\_ for environment and ansilbe\_ for internal vars were prefixes that were supposed to be exclusive to core, the move to collections changed that w/o anybody taking time to consider the implications of that change. ---
**Author:** ![briantist](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/briantist/32/130_2.png) [@briantist](https://forum.ansible.com/u/briantist)\ **Post date:** [May 21, 2024, 3:01pm UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737/15 "2024-05-21T15:01:05Z")
> [@samccann](#): > > Is there some magic aliasing that happens for people using the older name or do they all have to change their environment variables when 'whatever change` happens? I wouldn’t be able to remove the old ones except during a major release. I would add the new ones and try to deprecate the old ones (or frankly, I might never remove them, because this change doesn’t seem right to me, and it only affects AWX users). I already added `vars` entries which are also preceded with `ansible_hashi_vault_` and AWX does not have this hard-coded restriction on ansible vars, only env vars. > [@samccann](#): > > SCNR …mostly just wanted to use that acronym cuz I haven’t seen it before and had to google it I also hasn’t seen it before and just had to look it up 🙃 ---
**Author:** ![briantist](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/briantist/32/130_2.png) [@briantist](https://forum.ansible.com/u/briantist)\ **Post date:** [May 21, 2024, 3:05pm UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737/16 "2024-05-21T15:05:37Z")
> [@bcoca](#): > > were supposed to be exclusive to core, the move to collections changed that w/o anybody taking time to consider the implications of that change It’s hard to call it a change though when most of the content that was core then become _not_ core ---
**Author:** ![gundalow](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/gundalow/32/99_2.png) [@gundalow](https://forum.ansible.com/u/gundalow)\ **Post date:** [May 21, 2024, 3:46pm UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737/17 "2024-05-21T15:46:12Z")
Folks Lets keep the discussion forward looking. Let’s focus on defining the problems, current user experience and ways forward. There are only two hard things in Computer Science: cache invalidation and naming things, and out by one errors. ---
**Author:** ![Denney-tech](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/denney-tech/32/1556_2.png) [@Denney-tech](https://forum.ansible.com/u/Denney-tech)\ **Post date:** [May 21, 2024, 4:12pm UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737/18 "2024-05-21T16:12:52Z")
> [@briantist](#): > > It’s hard to call it a change though when most of the content that was core then become _not_ core This is actually an interesting way to frame this. Sure, at one point in time, `ANSIBLE_` was exclusive to the `ansible` binary/package, but now it is the inherited birthright of the collections born directly from `ansible` as part of Ansible’s legacy. `NAMESPACE_COLLECTION_` should be good practice, but `ANSIBLE_NAMESPACE_COLLECTION_` should be just as legal, i.e. `ANSIBLE_` shouldn’t be exclusive to `ansible-core` since it _hasn’t been_ since 2.9~2.10. > [@gundalow](#): > > Lets keep the discussion forward looking. Let’s focus on defining the problems, current user experience and ways forward. The main problem is AWX has blacklisted `ANSIBLE_`, _nearly 6 years ago before collections were introduced_, under the guise that it is exclusive to the ansible binary and in turn a security concern. Regardless of the politics of it, the `ANSIBLE_` prefix is not exclusive to core in practice (at least not in today’s ecosystem). If there are still security concerns, then there needs to be a way to address these concerns. If AWX can use `ansible-config` to programmatically blacklist an array of known environment vars, that would alleviate the problem. If not programmatically, then at least a static list could be generated. Then AWX only needs to blacklist environment vars specific to core. ---
**Author:** ![bcoca](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bcoca/32/9269_2.png) [@bcoca](https://forum.ansible.com/u/bcoca)\ **Post date:** [May 21, 2024, 4:14pm UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737/19 "2024-05-21T16:14:36Z")
I’m sorry, I seemed to not have stated it correctly, but that was my point. The move to collections also moved existing variables with those names into collections/3rd party/community and this was not something we considered at the time and how we arrived at the current state of having a ‘core convention’ expanded and adopted to every 3rd party plugin. Instead of making a change of standards at this point (very costly, no matter which/where the change is made), i’m proposing to adopt the validation I’ve just added to ansible-config (which CAN consider 3rd party ansible plugins) as a solution. ---
**Author:** ![bcoca](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bcoca/32/9269_2.png) [@bcoca](https://forum.ansible.com/u/bcoca)\ **Post date:** [May 21, 2024, 4:16pm UTC](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737/20 "2024-05-21T16:16:45Z")
> [@Denney-tech](#): > > If there are still security concerns, then there needs to be a way to address these concerns. If AWX can use `ansible-config` to programmatically blacklist an array of known environment vars, that would alleviate the problem. If not programmatically, then at least a static list could be generated. Then AWX only needs to blacklist environment vars specific to core. Right now validation just issues warnings/errors, but I can easily add a --json option to give you a ‘processing friendly’ list. But we already have a way to list all ‘usable’ variables by config from core and/or plugins in ansible-config, the new validation just points out ‘possible spelling errors’. [Next page](https://forum.ansible.com/t/environment-variables-prefix-with-ansible-and-awx/5737.md?page=2)