AdminSysGNULinux

Voir :

• https://en.euro-linux.com/docs/ansible-awx.php?p=credentials/extract_credentials
• https://github.com/fernet/spec/blob/master/Spec.md

Voir aussi :

• https://docs.oracle.com/en/learn/olam-migrate/#prepare-the-execution-plane-node

L'algo de chiffrement est aes-cbc Le secret principal est présent dans /etc/tower/SECRET_KEY, mais une clef dérivée est systématiquement utilisée.

Lors de l'export d'un Credential, le secret (mot de passe, clef privée..) n'est pas exportée pour des raisons de sécurité.

Voici comment le récupérer

sudo -u awx -i
 
#awx-manage shell_plus --ipython
awx-manage shell_plus

from awx.main.utils import decrypt_field
cred = Credential.objects.get(name="Nom_Credential")
 
# Avoir la liste des champs (ex: password)
cred.inputs
 
# Avoir le mdp déchiffré
#print(decrypt_field(cred, "password"))
cred.get_input('password')

psql -t -A -h pg1.db.acme.local -U user1 -d twrdb -p 5454

SELECT inputs FROM main_credential WHERE name = 'Nom_Credential';"

{"password": "$encrypted$UTF8$AESCBC$Z0FBQUFZQmtRT2t6Y3IwMl9yZXk3SUEwemdCVGxQZUZvZDQwbEw0MUgyYjdwd0JkdDlRUHZDUldnWVNTVjFuZ0ZfdGhxTWZndEJ2M050ZFpVdFFpVnVmaDF1dTViVHJCNVV3dkFYMU5abVVKeEZLRXlHVkUtUW89", "username": "user1@acme.local"}

La DB contient un champ nommé inputs dont le contenu est du JSON. A l’intérieur du JSON, nous avons un champs password dans notre exemple et un champ username A l’intérieur du champs password nous avons plusieurs champs séparé par le caractère $

13.1.3. Secret handling for automation use

Ansible Tower stores a variety of secrets in the database that are either used for automation or are a result of automation. These secrets include : all secret fields of all credential types (passwords, secret keys, authentication tokens, secret cloud credentials) secret tokens and passwords for external services defined in Ansible Tower settings “password” type survey fields entries

To encrypt secret fields, Tower uses AES in CBC mode with a 256-bit key for encryption, PKCS7 padding, and HMAC using SHA256 for authentication. The encryption/decryption process derives the AES-256 bit encryption key from the SECRET_KEY (described above), the field name of the model field and the database assigned auto-incremented record ID. Thus, if any attribute used in the key generation process changes, Tower fails to correctly decrypt the secret. Ansible Tower is designed such that the SECRET_KEY is never readable in playbooks Ansible Tower launches, that these secrets are never readable by Tower users, and no secret field values are ever made available via the Ansible Tower REST API. If a secret value is used in a playbook, we recommend using no_log on the task so that it is not accidentally logged.

https://docs.ansible.com/ansible-tower/latest/html/administration/secret_handling.html

Data is encrypted before it is saved to the database and is decrypted as is needed in Tower. The encryption/decryption process derives the AES-256 bit encryption key from <SECRET_KEY, field_name, primary_key> where field_name is the name of the Model field and primary_key is the database assigned auto-incremented record ID. Thus, if any attribute used in the key generation process changes, Tower fails to correctly decrypt the secret.

https://docs.ansible.com/ansible-tower/3.5.3/html/userguide/credentials.html

Added a command to generate a new SECRET_KEY and rekey the database

https://docs.ansible.com/ansible-tower/3.6.2/html/installandreference/release_notes.html

openssl enc -aes-256-cbc -pbkdf2 -pass pass:MYPASSWORD -p -in foo_clear -out foo_enc