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 faced a behavior not so clear to me, not sure if it depends on procedural nature of Ansible or on 'hashivault_db_secret_engine_config' module or hashicorp vault database secret engine logics. I depict simplified steps sequence below:
A task to configure dbms for vault integration (vaultuser/vaultpuserwd and permissions)
A task using module hashivault_db_secret_engine_config for main config of a vault database secret engine, with integration with dbms configured on step (1.)
vaultuser dbms/vault credentials rotation (based on update flag)
after the Fix of issue #381hashivault_db_secret_engine_config does not anymore change without code modifications. This is right and avoid dbms credencials inconsistency after step (3.). Right!
The problem arises because of argument present in hashivault_db_secret_engine_config, that is more dynamic then other ones (the list of allowed_roles). If I add another step:
Add new vault database secret engine roles and so add these new roles in allowed_roles, on next pipeline cycle it will run step (2.) the task will run hashivault_db_secret_engine_config that correctly set new allowed_roles list and that CHANGES ALSO PASSWORD reverting to the original one and so making inconsistent dbms/vault connection (as this will change password on vault config but not on dbms).
What do you think about that ? Not sure if this is something to solve by:
Hashivault hashivault_db_secret_engine_config that by checking the connection to database backend, woult keep consistency between dbms and vault password (as rotate just do)
Hashicorp Vault database secrete engine, that as far as i know actually not natively support this consistency
My code in ansible, also if such solution appears suboptimal as dbms management code can be in all another code (role/playbook) then vault management code so very innatural and difficult to manage and to maintain atomicity
Sure a solution could be setting allowed_roles: "*" but so we would lose a useful security configuration.
The text was updated successfully, but these errors were encountered:
I think that line can be tied to this pheraps: #385 but root_rotation_statements does not deal directly with credentials rotation as that is another task. root_rotation_statements in hashivault_db_secret_engine_config allow only to customize the rotation statements if not standard for same dbms versions, etc. it will conatains the querie/statements rotation will call if not empty.
I'm thinking about a force: true|false flag to allow configuraiton change forced based on external events (like database vault user credentials changes)
I faced a behavior not so clear to me, not sure if it depends on procedural nature of Ansible or on 'hashivault_db_secret_engine_config' module or hashicorp vault database secret engine logics. I depict simplified steps sequence below:
hashivault_db_secret_engine_config
for main config of a vault database secret engine, with integration with dbms configured on step (1.)after the Fix of issue #381
hashivault_db_secret_engine_config
does not anymore change without code modifications. This is right and avoid dbms credencials inconsistency after step (3.). Right!The problem arises because of argument present in
hashivault_db_secret_engine_config
, that is more dynamic then other ones (the list ofallowed_roles
). If I add another step:allowed_roles
, on next pipeline cycle it will run step (2.) the task will runhashivault_db_secret_engine_config
that correctly set new allowed_roles list and that CHANGES ALSO PASSWORD reverting to the original one and so making inconsistent dbms/vault connection (as this will change password on vault config but not on dbms).What do you think about that ? Not sure if this is something to solve by:
hashivault_db_secret_engine_config
that by checking the connection to database backend, woult keep consistency between dbms and vault password (as rotate just do)Sure a solution could be setting allowed_roles: "*" but so we would lose a useful security configuration.
The text was updated successfully, but these errors were encountered: