Credentials encrypting not writing in the correct app

[lmnogues]

Hi,

I'm not sure if it's bug, an enhancement request or a rtfm request ^^'

We have a Modular input based on UCC generator which is used for several client. We have configuration app which provides account/inputs for those client.

Our issue is that the credentials replacement with ******is not working as we expect : it's writing the ****** in the modular input itself instead of overwriting the configuration app files.

The result is that the password are always in clear text in our configuration. In fact all edition of the config are written in the modular input instead of the config app.

How can we make sure the password credentials overwrite the proper files ?

[artemrys]

Hi, Is there any chance this is an add-on which I can download from Splunkbase so I can check it out?

[lmnogues]

sadly no, and it won't be released. It's a Input written for a specific integration.

I might be able to give more information thought... We have a pretty standard globalConfig.json; 3 tabs Account / Logging / Proxy 1 inputs with pretty standard parameters.

lib/requirements.txt only contains splunk-sdk & splunktaucclib

may be the only "non standard" action we've done, is to edit the 'input_declare*.py" to insert the lib folder instead of appending it : we add issues with the requests shipped by splunk, so by inserting the lib folder we manage to avoid the issue new_paths.insert(0, os.path.join(dirname(dirname(__file__)), "lib"))

Our password retrieval is as follow :

    decrypted_data=None
    # Retrieve the password from the storage/passwords endpoint 
    for storage_password in mod_input_.service.storage_passwords:
        if storage_password.username == account+"``splunk_cred_sep``1":
            decrypted_data=storage_password.content.clear_password
    if decrypted_data is None:
        raise ValueError(f"Configuration Error : encrypted_data not found for user {account}")

[artemrys]

@Jalkar I actually fixed the issue with the "import_declare_test.py" in the v5.25.0 which was released this week, please check it out!

I would suggest using CredentialManager to get the passwords (https://github.com/splunk/addonfactory-solutions-library-python/blob/e45f8124e5317c86c8c82df6cbffab561d38e2ee/solnlib/credentials.py#L51), it allows you to specify app and owner, so this way you can update the credentials of the another add-on. I am not sure what is mod_input in your code snippet, but I assume that it uses the context for the current add-on where you have a modular input instead of the context of your configuration add-on. Please let me know if that makes sense.

[lmnogues]

My concern is that if i'm right, the password replacement with "****" is not done in the 'run' of the modular input but on splunk startup I'll lookup into CredentialManager to check if this solves my issue :) and yes "mod_input" is the modular_input object

[lmnogues]

I confirm my saying above. The CredentialManager is not helping as the "**" replacement step is done by the gui access to the configuration page.

I've done the following test :

• create an empty splunk box (using docker-splunk)
• install the modular input
• create my 'account.conf' in the search app
• create the input in a secondary test_input app
• start splunk
• Going to the modular input:
• in the configuration tab we do not see any account (i've not updated my local.meta yet)
• in the input tab, we see the input
• looking at the logs we can see that the input is failing on run because there is no account available.
• looking at the conf via btool we can see the conf in clear text.
• update the sharing of the test_input app to make it global (so that the 'account.conf' data is shared)
• looking at the conf via btool, the "****" are present in the modular input app context, but the data is still in clear text in the test_input app.

From my testing, it seems the issue is with the creation of the 'rh_account.py' in which there is a SingleModel object created without app context. If you put any app it will use it as the target.

endpoint = SingleModel(
    'mod_input_x_account',
    model,
    config_name='account',app="launcher"
)

with the snippet above, my "*****" landed in the launcher app even though the config is in another app.

[lmnogues]

I believe you can reproduce the issue with this demo repo : https://github.com/Jalkar/demo_ucc_issue

[artemrys]

@Jalkar I think the behaviour that you see is correct from my perspective, you should not see objects from another apps by default.

[artemrys]

I know there are people who like to keep their configuration in one place (one specific add-on for configuration), do you mind sharing why do you prefer keeping configuration in the separate add-on?

[lmnogues]

I know there are people who like to keep their configuration in one place (one specific add-on for configuration), do you mind sharing why do you prefer keeping configuration in the separate add-on?

We keep the conf outside the app to ease deployment & maintenance We don't need to deploy all the python for a change of secret We can more easily reuse the addon for another client without the risk of sharing the wrong config

[hetangmodi-crest]

For the above use case mentioned, have you tried using deployment server to deploy your add-ons to multiple Splunk Enterprise forwarders?

Accessing secrets from different apps would be an issue in a scenario where a user has used the same name for credentials in 2+ add-ons, hence an add-on should be writing in its own namespace and reading from the same to avoid such issues.