Managing Enterprise Automation with Red Hat Ansible Automation Platform
Create a machine credential for inventory hosts to allow automation controller to run jobs on those inventory hosts.
Credentials are the automation controller objects used to authenticate to remote systems. They provide secrets, such as passwords and SSH keys, or other supporting information needed to successfully access or use a remote resource.
The automation controller maintains secure storage for the secrets in these credential objects. Credential passwords and keys are encrypted before they are saved to the automation controller database, and cannot be retrieved in clear text from the automation controller user interface. Although users and teams can be assigned privileges to use credentials, the secrets are not exposed to them. This means that when a user changes teams or leaves the organization, the credentials and systems do not need to be rekeyed. When a credential is needed by automation controller, it decrypts the data internally and passes it to SSH or other program directly.
Important
After you have entered sensitive authentication data into a credential and encrypted, it can no longer be retrieved in decrypted form through the automation controller web UI.
The automation controller can manage several different types of credentials, including:
- Ansible Galaxy/Automation Hub API Token
Create this type of resource so that automation controller can download Ansible Content Collections and roles from Ansible Galaxy, automation hub, and private automation hub.
After creating the credential, you must enable the credential for an organization. During this process, you can specify a precedence by ordering the credentials.
- Container Registry
Create this type of credential if you need to authenticate before you can pull down a container image from a container registry, such as
\registry.redhat.ioor a private automation hub.- GitHub Personal Access Token
GitHub no longer supports password-based authentication to synchronize projects with the HTTPS protocol. To continue using HTTPS (rather than SSH), create and use a GitHub personal access token (PAT), and then create an automation controller credential that uses the personal access token.
- Machine
Automation controller can use this credential type to access and make changes to the managed hosts. Later sections discuss the machine credential in more detail.
- Network
Create this type of credential to use Ansible network modules to manage networking equipment. This credential specifies a username and either a password or the content of the user’s SSH private key.
- Source Control
Create this type of credential to synchronize project resources from a remote repository. Specify a username and either a password or the user’s SSH private key.
- Vault
Create this type of credential to decrypt files that have been encrypted with Ansible Vault.
Several types of inventory credentials are available to update dynamic inventory information from one of the automation controller’s built-in dynamic inventory sources. Separate credential types exist for each inventory source in question: Amazon Web Services, VMware vCenter, Red Hat Satellite 6, Google Compute Engine, Microsoft Azure Resource Manager, OpenStack, and so on.
Note
Automation controller administrators can create custom credential types that can be used like the built-in credential types, specified using a YAML definition. Find more information about how to create a new credential type in the References at the end of this section.
This section focuses on how to set up machine credentials that provide appropriate login and privilege escalation information for use with hosts in an inventory. Some other types of credentials are discussed in more detail elsewhere in this course.
You can manage credentials through the → page in the automation controller web UI.
Any user can create a credential, and is considered the owner of credentials that they create. If a credential is not assigned to an organization, it is a private credential. This means that only the user that owns the credential, and users with the automation controller System Administrator user type can use it, and only those users and users with the automation controller System Auditor user type can see it.
On the other hand, if the credential is assigned to an organization, then it is an organization credential. Only the automation controller System Administrator users and users with the Admin role on an organization can create credentials assigned to an organization. Users and teams in the organization can be granted roles on a credential assigned to the organization to use or manage the credential.
In summary, the main distinctions between private credentials and organization credentials are:
Any user can create a private credential, but only automation controller
System Administratorusers and users with theAdminrole on an organization can create an organization credential.If a credential belongs to an organization, users and teams can be granted roles on it, and it can be shared. Private credentials not assigned to an organization can only be used by the owner and the automation controller
System Administratorusers. Other users and teams cannot be granted roles.
Important
The automation controller Admin user can assign an organization to an existing private credential, converting a private credential into an organization credential.
The following procedure details how to create machine credentials.
Log in to the automation controller web UI as a user with the appropriate role assignment. If you are creating a private credential, there are no specific role requirements. If you are creating an organization credential, log in as a user with the
Adminrole for the organization.Click → .
Click to create a new credential.
Enter a name and description for the new credential in the and fields, respectively.
If you have organization
Adminprivileges, you can click the search icon to select the organization to which you assign this credential in order to make it an organization credential. If you do not haveAdminprivileges in an organization and you attempt to select it, automation controller displays the message "You do not have permission to perform this action", and you cannot save the credential.If you do not have
Adminprivileges, do not select any organization. This creates a private credential.For machine credentials, additional fields appear in the section:
These fields can contain the information needed to authenticate to and escalate privileges on the machines that use this credential. Many of them are mapped to settings, which might be in an ansible.cfg file:
is the username used to log in to the managed hosts (
remote_userinansible.cfg).is the SSH password to use for this user. Leave this blank if you use SSH private key authentication.
The field contains an SSH private key that you use to log in as on the managed hosts. It is easier to cut and paste the text from the file rather than to manually type it in. If you are administering automation controller from a Firefox web browser running under GNOME 3 or higher, you can drag and drop the private key file from the application window in the desktop environment into this field in your web browser window.
When you save the credential, the automation controller encrypts it. The or field reads
$encrypted$instead of displaying the credential.You can use the field when the key in is encrypted by SSH for additional protection. The field accepts a passphrase that can decrypt the key. Otherwise, this field can be blank.
is a drop-down menu that specifies what type of privilege escalation (
become_method), if any, that is needed for playbooks run on the machines accessed by this credential.For
sudoprivilege escalation, is the privileged user that Ansible should use on the managed host (become_user). is thesudopassword to use. This can be blank if no password is needed.Click to create the new machine credential.
When you create a machine credential, you can edit it, if needed. The following procedure details how to modify a machine credential.
Log in as a user with the appropriate role assignment. If editing a private credential, then log in as the user who created the credential. If editing an organization credential, then log in as a user with
Adminrole on the organization credential.Click → .
Click the name of the credential to edit.
On the credential editor screen, make the necessary changes to the desired credential properties.
Click .
As discussed earlier, private credentials (credentials that are not assigned to an organization) are only accessible to their creators or to users that have the System Administrator or System Auditor user type. Other users cannot be assigned roles on private credentials.
To assign roles to credentials, the credential must have an organization. Users and teams in that organization can then share that credential through role assignments.
The following is the list of available credential roles.
| Credential role | Description |
|---|---|
Admin
| Grants users full permissions on a credential. These permissions include deleting and modifying the credential, as well as the ability to use the credential in a job template. |
Use
| Grants users the ability to use a credential in a job template. How to use a credential in a job template is discussed later in this course. |
Read
| Grants users the ability to view the details of a credential. Does not allow these users to decrypt the secrets which belong to that credential through the web UI. |
When you create an organization credential, it is only accessible by the owner and users with either the Admin or Auditor role in the organization in which you created it. You must configure additional access, if desired.
You cannot assign additional roles to the credential until you save it, after which you can set them by editing the credential.
Use the following procedure to grant permissions to an existing organization credential:
Log in as a user with
Adminrole on the organization in which the credential was created.Click → and then click the name of the credential to edit.
On the credential editor page, on the tab, click to add permissions.
Click either or , and then click to select the users or teams to be assigned roles.
Click to display the list of available roles to apply.
Click .
Important
Permissions for credentials can also be added through either the user or team management pages.
To help you understand ways in which credentials are used, the following sections describe some common credential scenarios.
One common scenario for the use of automation controller credentials is the delegation of task execution from administrators to Tier 1 support staff.
For example, suppose that the support staff needs to be delegated the ability to run a playbook ensuring a web application has been restarted to restore service when outages occur outside of business hours. The support staff’s credential uses a shared account, support, and a passphrase-protected private key for SSH authentication to managed hosts. The support account needs to escalate privileges using sudo, with a sudo password, in order to run the playbook.
Because the credential is shared by the support staff’s team, an organization credential resource should be created to store the username, SSH private key, and SSH key passphrase needed to authenticate SSH sessions to the managed hosts. The credential also stores the privilege escalation method, username, and sudo password information. Once created, the credential can be used by the support staff to launch jobs on the managed hosts without needing to know the SSH key passphrase or sudo password.
Another scenario is to use credentials to store username authentication information while still prompting interactively for a sensitive password when the credential is used.
Suppose that a database administrator wants to run a playbook managed in automation controller to execute tasks on a database server that houses sensitive data for the company finances. Due to the highly sensitive nature of the data, the company’s financial compliance regulations forbid the storage of the account’s password.
You can still use a machine credential to configure the database administrator’s authentication to the database server. Because the credential is not to be shared, you can use a private credential to store the SSH and configure it by selecting the checkbox for . This prompts the user for the account’s password when a job uses the credential.
Important
Automation controller has a feature that allows playbooks to be run automatically on a schedule, much like a cron job in Linux. Credentials configured to prompt interactively for password information at runtime cannot be used with scheduled jobs, because automation controller cannot provide that information without user interaction.
