• Zach Biles

Ansible/AWX Custom Credential Types

Sometimes in Ansible you need to support legacy devices, or API’s that require hard coded passwords or API strings in your playbooks. One way around this is to use custom credential objects in AWX/Tower. This can keep your playbooks generic for storage in your version control system, and shareable, while keeping your credentials safe.


If your job doesn’t need to be scheduled and will be run manually, you could always use a “survey” or “extra_vars” (insecure) in your job template inside AWX, but if you need to schedule them, the answer is custom credential types. Normally you can use the built-in credential types, but in some instances they don’t fit, or your playbook is doing something non-standard. All you are really doing is creating a yaml file that specifies the variable names and structure of the credential object. The basic structure of the input configuration is as follows:

fields:
    - type: <field type>
      id: <variable name>
      label: <label name>
    - type: <field type>
      id: <variable name>
      label: <label name>
    etc etc...

You create all the “fields” that you want your custom credential to contain, and what type of data they will contain (string, boolean). The label is just what you see when you go to actually create a new credential object based on this template, so just a description of the field.


Once you have created your input configuration, you will need to create the injector configuration. This is where you will specify the mapping between the vars in your playbook, and the id’s in your input configuration. These custom credentials are injected as extra_vars into your playbook, so they have the highest precedence, and will override any other variables of the same name in your playbook. When pasting/typing these in, make sure to use spaces, not tabs for indentation, and leave a blank line at the end. I’ve found AWX will usually bark at you if you do either of these things, and it’s a pretty vague error. The injector configuration is as follows. Notice the jinja2 formatting on the variable contents, otherwise they will get parsed as strings when they are injected into your playbook.

extra_vars:
    var1:{{id_1}}’
    var2:{{id_2}}’
    etc...

Here’s a look at it with some examples to make it easier to visualize:

#input configuration (credential structure/blueprint)
fields:
    - type: string
      id: my_user
      label: username
    - type: string
      id: my_pass
      label: password
      
# injector configuration (mapping values)
extra_vars:
  my_user:{{my_user}}’
  mypass:{{my_pass}}

Once you save this configuration, you can create the new credential object and assign it to your template:



The good thing about using custom credentials instead of just placing your credentials in plain-text in the extra_vars section of your template is that AWX/Tower treats custom credentials as exactly that, credentials. So it hides this from the template output for better security.

Recent Posts

See All

Useful Ansible Ad-Hoc Commands

Ansible doesn’t always have to be crazy complex playbooks doing super cool stuff. Sometimes, it’s really useful to get some output from al your devices like versioning, VLANs, IP addresses, etc... Her

Ansible Inventory Scripts

# TIL It appears that you are required to use a .ini file with inventory scripts in Ansible. If you try and use static variables in the script, it will appear to work when running the raw Python or wh

LINKS
ABOUT

info@sisulink.com

Inside TechTank

3709 1st Ave

Hibbing, MN 55746, USA

SOCIAL
  • sisuLink on Facebook!

© 2020 sisuLink.