[ansible/artifactory] Add mTLS support

[shurikg]

PR Checklist

[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

• Title of the PR starts with installer/product name (e.g. [ansible/artifactory])
• CHANGELOG.md updated
• Variables and other changes are documented in the README.md

What this PR does / why we need it:
Support configuration of mTLS for artifacts version 7.77 and above.

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #

Special notes for your reviewer:

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[shurikg]

I have read the CLA Document and I hereby sign the CLA

[srinivasgowda097]

@shurikg Thanks for the PR ! We would like you to do some changes to this PR so that it’s generic . Here you have implemented for mtls however we looking at any accessConfig as a variable so that it can be customized !refer to systemYaml as a variable under vars.yaml as an example
If you have any better suggestions , let’s us know

[shurikg]

@shurikg Thanks for the PR ! We would like you to do some changes to this PR so that it’s generic . Here you have implemented for mtls however we looking at any accessConfig as a variable so that it can be customized !refer to systemYaml as a variable under vars.yaml as an example If you have any better suggestions , let’s us know

The JFrog manages the access.config.latest.yml file differently from all other configuration files. This file is generated automatically after the start of service. To update it we need to use a patch file which will be deleted after the service restart.

To save the ansible idempotence concept, and mark the tasks as changed only when it's changed (it's crucial for our automation) I didn't find a way to implement mtls in the same way as you do for system.yaml file.

This is why I did it this way (focusing on the missing MTLs part for us).

If you have another idea on how we can manage the access file, but continue with the ansible idempotence concept, I will be glad to know.

[chukka]

@shurikg Thanks for the PR ! We would like you to do some changes to this PR so that it’s generic . Here you have implemented for mtls however we looking at any accessConfig as a variable so that it can be customized !refer to systemYaml as a variable under vars.yaml as an example If you have any better suggestions , let’s us know

The JFrog manages the access.config.latest.yml file differently from all other configuration files. This file is generated automatically after the start of service. To update it we need to use a patch file which will be deleted after the service restart.

To save the ansible idempotence concept, and mark the tasks as changed only when it's changed (it's crucial for our automation) I didn't find a way to implement mtls in the same way as you do for system.yaml file.

This is why I did it this way (focusing on the missing MTLs part for us).

If you have another idea on how we can manage the access file, but continue with the ansible idempotence concept, I will be glad to know.

We understand the idempotence concept , if you are looking

1. For patching accessConfig , Ideally please refer to our helm charts , we load access.config.patch.yml as secret . is it possible for you update the current PR with a generic solution of accessConfigPatch as variable and you can add your mtls as custom content (as an example in readme ) so that it will be generic solution for most customers and you can still retain the configuration in your code base . On a whole, we want this to be added in readme for mtls rather than default code base .

please refer to here as example

2. For complete bootstrapping of accessConfig, you can refer here under Access Configuration File and here

we are happy to assist if you have any further questions

Thanks