feature: Add DVLS Ansible Module to create/update secrets

[PatrickEPG]

I've added a module to upload secrets to dvls.

When the a secret already exists, it will be updated. When the secret does not yet exist, a new entry will be created.
I also added some documentation.

This is my first Open-Source contribution so any feedback is very welcome.

[richerlariviere]

Hello Patrick,

I wanted to sincerely thank you for your contribution, especially since it's your first one. Our society needs more generous people like you, and I wanted to highlight your effort.

By the way, I wanted to clarify with you the mission of the Ansible module for DVLS. To facilitate the maintenance of our various integrations with DVLS, we have decided that these integrations should be used to consume DVLS in read-only mode (we're avoiding write and configuration operations). With read-write management comes inherent complexity, and since DVLS supports multiple entry types, it is unrealistic for us to support all these use cases across our different integrations. Considering that I cannot merge this PR unfortunately.

I'm still interested to know about your specific use-case though. What are the advantages of creating/updating DVLS secrets outside of DVLS UI? I'd really appreciate your feedback regarding that.

Have a nice day,
Richer

[PatrickEPG]

Hi Richer,
thank you for the information.

We want to fully automate the deployment of some of our software. So when we deploy the database, users/passwords will be created, which need to be stored somewhere.
Since these Credentials will be consumed by following deployments (software that uses the database) as well as Admins/Support Agents, we figured DVLS is the place to store them.

If I understand correctly, the PowerShell Module https://github.com/Devolutions/SecretManagement.DevolutionsServer allows the creation of secrets and the API allows it as well, which is what I used to implement. Is there a difference in using the PowerShell Module/API directly instead of utilizing Ansible?

Kind regards
Patrick

[richerlariviere]

Hey @PatrickEPG I think you'll be happy. I just had a talk with our CEO David and we decided to consider your use-case. We are now open to support simple entry types. We will review your PR shortly.

Stay tuned!

[DannyBedard]

Works like a charm good job! I requested some changes for the format and the documentation.

[DannyBedard]

Maybe write a usage with non-required options since there is many of them?

Also I'd write the possible options for type and subtype. As of today, we support only Credentials for type and for subtype we support

• "AccessCode"
• "ApiKey"
• "AzureServicePrincipal"
• "ConnectionString"
• "Passkey"
• "PrivateKey"
• "Default"

[DannyBedard]

Options such as secret_path, secret_type, secret_subtype and secret_description could be in the secret object

[PatrickEPG]

Good idea, this would open up the possibility to change the secret Object to a list, that way the module could support uploading multiple secrets in one run.
My initial though was to loop the module inside ansible.

I have an idea:
The variables are moved inside the secret Object and I change the secret Object to a list to support the upload of multiple secrets.
Additionally the return Object logic is changed to always return the name and the ID of the secret, that way if 2 Secrets are created and 1 is updated there will always be 3 Names/IDs returned which can be identified.

Do you think this is a better approach?

[DannyBedard]

I'd prefer to keep it simple for this release since it's the first implementation of this feature. The loop in Ansible should cover most cases, and if future use cases show a need for this (from you or others), we can adjust accordingly.

Returning the ID/name of the secrets is a good idea, since it can be useful for further operation in a playbook.