You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I understand that AWX is open source software provided for free and that I might not receive a timely response.
I am NOT reporting a (potential) security vulnerability. (These should be emailed to [email protected] instead.)
Bug Summary
When attempting to retrieve credentials using Ansible AWX 22.7.x from Conjur Enterprise 13, I consistently encounter a 401 error. After thorough investigation, I've identified that the root of the issue lies within the conjur_backend function, which executes two requests to Conjur in order to fetch the necessary credential information:
Initial authentication is performed through the endpoint api/authn/<account>/<username>/authenticate/. The response from this request includes a signature.
The actual credential retrieval takes place using the endpoint api/secrets/<account>/variable/<path_to_secret>/, where users provide the relevant variable or secret.
Upon closer inspection, it becomes clear that the authentication response (as described in point 1) differs between Conjur OSS and Conjur Enterprise. To illustrate these differences, I wrote a test script, and the subsequent output from the console is documented in the provided images (Image 1: Test Code, Image 2: Console Output).
Image 1:
Image 2:
The Conjur Enterprise API returns a response containing the keys signature, payload, and protected. In contrast, the Conjur OSS response presents the same keys, encoded in base64, though. The result is that the plain message from Conjur Enterprise should be encoded to base64 first, before added as a header to the second request (point 2).
An alternative approach involves including the header {"Accept-Encoding": "base64"} within the headers for the second request. This adjustment is performed within the awx/main/credential_plugins/conjur.py file, wherein the modification is as follows:
By incorporating this change, we ensure compatibility with both Conjur OSS and Conjur Enterprise instances, enhancing the credential retrieval process from AWX.
EDIT: Following further investigation into this issue, it appears that my initial solution of adding headers may not be effective. I attempted to rectify this within my local AWX environment, but unfortunately, the issue persisted.
A more viable approach could involve checking whether the authentication response is already in base64 format. This can be accomplished using the following steps:
Begin by importing the necessary modules:
importbase64importbinascii
Integrate the following function into your codebase:
Adjust the declaration of the lookup_kwargs as shown below. This modification ensures that the authentication token is properly encoded if it's not already in base64 format:
Zektono
changed the title
Conjur credential retrieval should have header "Accept-Encoding"
Conjur credential retrieval differs between Conjur OSS and Conjur Enterprise
Aug 24, 2023
I just tested the Conjur integration with AWX version 21.8.0 and I can confirm that this version is working well with Conjur Enterprise. This AWX version contains the conjur.py version witth base64 code in it.
Please confirm the following
[email protected]
instead.)Bug Summary
When attempting to retrieve credentials using Ansible AWX 22.7.x from Conjur Enterprise 13, I consistently encounter a 401 error. After thorough investigation, I've identified that the root of the issue lies within the
conjur_backend
function, which executes two requests to Conjur in order to fetch the necessary credential information:api/authn/<account>/<username>/authenticate/
. The response from this request includes a signature.api/secrets/<account>/variable/<path_to_secret>/
, where users provide the relevant variable or secret.Upon closer inspection, it becomes clear that the authentication response (as described in point 1) differs between Conjur OSS and Conjur Enterprise. To illustrate these differences, I wrote a test script, and the subsequent output from the console is documented in the provided images (Image 1: Test Code, Image 2: Console Output).
Image 1:
Image 2:
The Conjur Enterprise API returns a response containing the keys
signature
,payload
, andprotected
. In contrast, the Conjur OSS response presents the same keys, encoded in base64, though. The result is that the plain message from Conjur Enterprise should be encoded to base64 first, before added as a header to the second request (point 2).An alternative approach involves including the header{"Accept-Encoding": "base64"}
within the headers for the second request. This adjustment is performed within theawx/main/credential_plugins/conjur.py
file, wherein the modification is as follows:Original Code:
Modified Code:
By incorporating this change, we ensure compatibility with both Conjur OSS and Conjur Enterprise instances, enhancing the credential retrieval process from AWX.EDIT: Following further investigation into this issue, it appears that my initial solution of adding headers may not be effective. I attempted to rectify this within my local AWX environment, but unfortunately, the issue persisted.
A more viable approach could involve checking whether the authentication response is already in base64 format. This can be accomplished using the following steps:
lookup_kwargs
as shown below. This modification ensures that the authentication token is properly encoded if it's not already in base64 format:@infamousjoeg can you help with this? And do you agree with this change?
AWX version
22.7.1
Select the relevant components
Installation method
docker development environment
Modifications
yes
Ansible version
No response
Operating system
MacOS
Web browser
Chrome
Steps to reproduce
Expected results
The retrieval of a secret from OSS will work, but the retrieval of a secret from Enterprise will result in a 401 error.
Actual results
The retrieval of a secret from OSS works, and the retrieval of a secret from Enterprise results in a 401 error.
Additional information
I tested the suggested code change. That was the only change I did in AWX.
The text was updated successfully, but these errors were encountered: