Este conteúdo não está disponível no idioma selecionado.
Chapter 22. Managing user credentials
Credentials authenticate the automation controller user when launching jobs against machines, synchronizing with inventory sources, and importing project content from a version control system.
You can grant users and teams the ability to use these credentials, without exposing the credential to the user. If a user moves to a different team or leaves the organization, you do not have to re-key all of your systems just because that credential was available in automation controller.
Automation controller encrypts passwords and key information in the database and never makes secret information visible through the API. For further information, see Configuring automation execution.
22.1. How credentials work
Automation controller uses SSH to connect to remote hosts. To pass the key from automation controller to SSH, the key must be decrypted before it can be written to a named pipe. Automation controller uses that pipe to send the key to SSH, so that the key is never written to disk. If passwords are used, automation controller handles them by responding directly to the password prompt and decrypting the password before writing it to the prompt.
It is possible to create duplicate credentials with the same name and without an organization. However, it is not possible to create two duplicate credentials in the same organization.
Example
- Create two machine credentials with the same name but without an organization.
-
Use the module
ansible.controller.export
to export the credentials. -
Use the module
ansible.controller.import
in a different automation execution node. - Check the imported credentials.
When you export two duplicate credentials and then import them in a different node, only one credential is imported.
22.2. Creating new credentials
Credentials added to a team are made available to all members of the team. You can also add credentials to individual users.
As part of the initial setup, two credentials are available for your use: Demo Credential and Ansible Galaxy. Use the Ansible Galaxy credential as a template. You can copy this credential, but not edit it. Add more credentials as needed.
Procedure
-
From the navigation panel, select
. - On the Credentials page, click .
Enter the following information:
- Name: the name for your new credential.
- (Optional) Description: a description for the new credential.
- Optional Organization: The name of the organization with which the credential is associated. The default is Default.
- Credential type: enter or select the credential type you want to create.
Enter the appropriate details depending on the type of credential selected, as described in Credential types.
- Click .
22.3. Adding new users and job templates to existing credentials
Procedure
-
From the navigation panel, select
. - Select the credential that you want to assign to additional users.
- Click the User Access tab. You can see users and teams associated with this credential and their roles. If no users exist, add them from the Users menu. For more information, see Users.
- Click .
- Select the user(s) that you want to give access to the credential and click .
- From the Select roles to apply page, select the roles you want to add to the User.
- Click .
Review your selections and click
to add the roles or click to make changes.The Add roles window displays stating whether the action was successful.
If the action is not successful, a warning displays.
- Click .
- The User Access page displays the summary information.
- Select the Job templates tab to select a job template to which you want to assign this credential.
Chose a job template or select Create job template from the Create template list to assign the credential to additional job templates.
For more information about creating new job templates, see the Job templates section.
22.4. Credential types
Automation controller supports the following credential types:
- Amazon Web Services
- Ansible Galaxy/Automation Hub API Token
- AWS Secrets Manager Lookup
- Bitbucket Data Center HTTP Access Token
- Centrify Vault Credential Provider Lookup
- Container Registry
- CyberArk Central Credential Provider Lookup
- CyberArk Conjur Secrets Manager Lookup
- GitHub Personal Access Token
- GitLab Personal Access Token
- Google Compute Engine
- GPG Public Key
- HashiCorp Vault Secret Lookup
- HashiCorp Vault Signed SSH
- Insights
- Machine
- Microsoft Azure Key Vault
- Microsoft Azure Resource Manager
- Network
- OpenShift or Kubernetes API Bearer Token
- OpenStack
- Red Hat Ansible Automation Platform
- Red Hat Satellite 6
- Red Hat Virtualization
- Source Control
- Terraform Backend Configuration
- Thycotic DevOps Secrets Vault
- Thycotic Secret Server
- Vault
- VMware vCenter
The credential types associated with AWS Secrets Manager, Centrify, CyberArk, HashiCorp Vault, Microsoft Azure Key Vault, and Thycotic are part of the credential plugins capability that enables an external system to lookup your secrets information.
For more information, see Secrets Management System.
22.4.1. Amazon Web Services credential type
Select this credential to enable synchronization of cloud inventory with Amazon Web Services.
Automation controller uses the following environment variables for AWS credentials:
AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SECURITY_TOKEN
These are fields prompted in the user interface.
Amazon Web Services credentials consist of the AWS Access Key and Secret Key.
Automation controller provides support for EC2 STS tokens, also known as Identity and Access Management (IAM) STS credentials. Security Token Service (STS) is a web service that enables you to request temporary, limited-privilege credentials for AWS IAM users.
If the value of your tags in EC2 contain Booleans (yes/no/true/false
), you must quote them.
To use implicit IAM role credentials, do not attach AWS cloud credentials in automation controller when relying on IAM roles to access the AWS API.
Attaching your AWS cloud credential to your job template forces the use of your AWS credentials, not your IAM role credentials.
Additional resources
For more information about the IAM/EC2 STS Token, see Temporary security credentials in IAM.
22.4.1.1. Access Amazon EC2 credentials in an Ansible Playbook
You can get AWS credential parameters from a job runtime environment:
vars: aws: access_key: '{{ lookup("env", "AWS_ACCESS_KEY_ID") }}' secret_key: '{{ lookup("env", "AWS_SECRET_ACCESS_KEY") }}' security_token: '{{ lookup("env", "AWS_SECURITY_TOKEN") }}'
22.4.2. Ansible Galaxy/Automation Hub API token credential type
Select this credential to access Ansible Galaxy or use a collection published on an instance of private automation hub.
Entering the Galaxy server URL on this screen.
Populate the Galaxy Server URL field with the contents of the Server URL field at Red Hat Hybrid Cloud Console. Populate the Auth Server URL field with the contents of the SSO URL field at Red Hat Hybrid Cloud Console.
Additional resources
For more information, see Using Collections with automation hub.
22.4.3. AWS secrets manager lookup
This is considered part of the secret management capability. For more information, see AWS Secrets Manager Lookup
22.4.4. BitBucket data center HTTP access token
Bitbucket Data Center is a self-hosted Git repository for collaboration and management. Select this credential type to enable you to use HTTP access tokens in place of passwords for Git over HTTPS.
For further information, see HTTP access tokens in the Bitbucket Data Center documentation..
22.4.5. Centrify Vault Credential Provider Lookup credential type
This is considered part of the secret management capability. For more information, see Centrify Vault Credential Provider Lookup.
22.4.6. Container Registry credential type
Select this credential to enable automation controller to access a collection of container images. For more information, see What is a container registry?.
You must specify a name. The Authentication URL field is pre-populated with a default value. You can change the value by specifying the authentication endpoint for a different container registry.
22.4.7. CyberArk Central Credential Provider Lookup credential type
This is considered part of the secret management capability.
For more information, see CyberArk Central Credential Provider (CCP) Lookup.
22.4.8. CyberArk Conjur Secrets Manager Lookup credential type
This is considered part of the secret management capability.
For more information, see CyberArk Conjur Secrets Manager Lookup.
22.4.9. GitHub Personal Access Token credential type
Select this credential to enable you to access GitHub by using a Personal Access Token (PAT), which you can get through GitHub.
For more information, see Setting up a GitHub webhook.
GitHub PAT credentials require a value in the Token field, which is provided in your GitHub profile settings.
Use this credential to establish an API connection to GitHub for use in webhook listener jobs, to post status updates.
22.4.10. GitLab Personal Access Token credential type
Select this credential to enable you to access GitLab by using a Personal Access Token (PAT), which you can get through GitLab.
For more information, see Setting up a GitLab webhook.
GitLab PAT credentials require a value in the Token field, which is provided in your GitLab profile settings.
Use this credential to establish an API connection to GitLab for use in webhook listener jobs, to post status updates.
22.4.11. Google Compute Engine credential type
Select this credential to enable synchronization of a cloud inventory with Google Compute Engine (GCE).
Automation controller uses the following environment variables for GCE credentials:
GCE_EMAIL GCE_PROJECT GCE_CREDENTIALS_FILE_PATH
These are fields prompted in the user interface:
GCE credentials require the following information:
- Service Account Email Address: The email address assigned to the Google Compute Engine service account.
- Optional: Project: Provide the GCE assigned identification or the unique project ID that you provided at project creation time.
- Optional: Service Account JSON File: Upload a GCE service account file. Click to browse for the file that has the special account information that can be used by services and applications running on your GCE instance to interact with other Google Cloud Platform APIs. This grants permissions to the service account and virtual machine instances.
- RSA Private Key: The PEM file associated with the service account email.
22.4.11.1. Access Google Compute Engine credentials in an Ansible Playbook
You can get GCE credential parameters from a job runtime environment:
vars: gce: email: '{{ lookup("env", "GCE_EMAIL") }}' project: '{{ lookup("env", "GCE_PROJECT") }}' pem_file_path: '{{ lookup("env", "GCE_PEM_FILE_PATH") }}'
22.4.12. GPG Public Key credential type
Select this credential type to enable automation controller to verify the integrity of the project when synchronizing from source control.
For more information about how to generate a valid keypair, use the CLI tool to sign content, and how to add the public key to the controller, see Project Signing and Verification.
22.4.13. HashiCorp Vault Secret Lookup credential type
This is considered part of the secret management capability.
For more information, see HashiCorp Vault Secret Lookup.
22.4.14. HashiCorp Vault Signed SSH credential type
This is considered part of the secret management capability.
For more information, see HashiCorp Vault Signed SSH.
22.4.15. Insights credential type
Select this credential type to enable synchronization of cloud inventory with Red Hat Insights.
Insights credentials are the Insights Username and Password, which are the user’s Red Hat Customer Portal Account username and password.
The extra_vars
and env
injectors for Insights are as follows:
ManagedCredentialType( namespace='insights', .... .... .... injectors={ 'extra_vars': { "scm_username": "{{username}}", "scm_password": "{{password}}", }, 'env': { 'INSIGHTS_USER': '{{username}}', 'INSIGHTS_PASSWORD': '{{password}}', },
22.4.16. Machine credential type
Machine credentials enable automation controller to call Ansible on hosts under your management. You can specify the SSH username, optionally give a password, an SSH key, a key password, or have automation controller prompt the user for their password at deployment time. They define SSH and user-level privilege escalation access for playbooks, and are used when submitting jobs to run playbooks on a remote host.
The following network connections use Machine as the credential type: httpapi
, netconf
, and network_cli
Machine and SSH credentials do not use environment variables. They pass the username through the ansible -u
flag, and interactively write the SSH password when the underlying SSH client prompts for it.
Machine credentials require the following inputs:
- Username: The username to use for SSH authentication.
- Password: The password to use for SSH authentication. This password is stored encrypted in the database, if entered. Alternatively, you can configure automation controller to ask the user for the password at launch time by selecting Prompt on launch. In these cases, a dialog opens when the job is launched, promoting the user to enter the password and password confirmation.
- SSH Private Key: Copy or drag-and-drop the SSH private key for the machine credential.
- Private Key Passphrase: If the SSH Private Key used is protected by a password, you can configure a Key Passphrase for the private key. This password is stored encrypted in the database, if entered. You can also configure automation controller to ask the user for the key passphrase at launch time by selecting Prompt on launch. In these cases, a dialog opens when the job is launched, prompting the user to enter the key passphrase and key passphrase confirmation.
Privilege Escalation Method: Specifies the type of escalation privilege to assign to specific users. This is the same as specifying the
--become-method=BECOME_METHOD
parameter, whereBECOME_METHOD
is any of the existing methods, or a custom method you have written. Begin entering the name of the method, and the appropriate name auto-populates.-
empty selection: If a task or play has
become
set toyes
and is used with an empty selection, then it will default tosudo
. - sudo: Performs single commands with superuser (root user) privileges.
- su: Switches to the superuser (root user) account (or to other user accounts).
- pbrun: Requests that an application or command be run in a controlled account and provides for advanced root privilege delegation and keylogging.
- pfexec: Executes commands with predefined process attributes, such as specific user or group IDs.
- dzdo: An enhanced version of sudo that uses RBAC information in Centrify’s Active Directory service. For more information, see Centrify’s site on DZDO.
- pmrun: Requests that an application is run in a controlled account. See Privilege Manager for Unix 6.0.
- runas: Enables you to run as the current user.
- enable: Switches to elevated permissions on a network device.
- doas: Enables your remote/login user to run commands as another user through the doas ("Do as user") utility.
- ksu: Enables your remote/login user to run commands as another user through Kerberos access.
-
machinectl: Enables you to manage containers through the
systemd
machine manager. - sesu: Enables your remote/login user to run commands as another user through the CA Privileged Access Manager.
-
empty selection: If a task or play has
Custom become
plugins are available from Ansible 2.8+. For more information, see Understanding Privilege Escalation and the list of Become plugins
- Privilege Escalation Username: You see this field only if you selected an option for privilege escalation. Enter the username to use with escalation privileges on the remote system.
- Privilege Escalation Password: You see this field only if you selected an option for privilege escalation. Enter the password to use to authenticate the user through the selected privilege escalation type on the remote system. This password is stored encrypted in the database. You can also configure automation controller to ask the user for the password at launch time by selecting Prompt on launch. In these cases, a dialog opens when the job is launched, promoting the user to enter the password and password confirmation.
You must use sudo password must in combination with SSH passwords or SSH Private Keys, because automation controller must first establish an authenticated SSH connection with the host before invoking sudo
to change to the sudo user.
Credentials that are used in scheduled jobs must not be configured as Prompt on launch.
22.4.16.1. Access machine credentials in an ansible playbook
You can get username and password from Ansible facts:
vars: machine: username: '{{ ansible_user }}' password: '{{ ansible_password }}'
22.4.17. Microsoft Azure Key Vault credential type
This is considered part of the secret management capability.
For more information, see Microsoft Azure Key Vault.
22.4.18. Microsoft Azure Resource Manager credential type
Select this credential type to enable synchronization of cloud inventory with Microsoft Azure Resource Manager.
Microsoft Azure Resource Manager credentials require the following inputs:
- Subscription ID: The Subscription UUID for the Microsoft Azure account.
- Username: The username to use to connect to the Microsoft Azure account.
- Password: The password to use to connect to the Microsoft Azure account.
- Client ID: The Client ID for the Microsoft Azure account.
- Client Secret: The Client Secret for the Microsoft Azure account.
- Tenant ID: The Tenant ID for the Microsoft Azure account.
- Azure Cloud Environment: The variable associated with Azure cloud or Azure stack environments.
These fields are equal to the variables in the API.
To pass service principal credentials, define the following variables:
AZURE_CLIENT_ID AZURE_SECRET AZURE_SUBSCRIPTION_ID AZURE_TENANT AZURE_CLOUD_ENVIRONMENT
To pass an Active Directory username and password pair, define the following variables:
AZURE_AD_USER AZURE_PASSWORD AZURE_SUBSCRIPTION_ID
You can also pass credentials as parameters to a task within a playbook. The order of precedence is parameters, then environment variables, and finally a file found in your home directory.
To pass credentials as parameters to a task, use the following parameters for service principal credentials:
client_id secret subscription_id tenant azure_cloud_environment
Alternatively, pass the following parameters for Active Directory username/password:
ad_user password subscription_id
22.4.18.1. Access Microsoft Azure resource manager credentials in an ansible playbook
You can get Microsoft Azure credential parameters from a job runtime environment:
vars: azure: client_id: '{{ lookup("env", "AZURE_CLIENT_ID") }}' secret: '{{ lookup("env", "AZURE_SECRET") }}' tenant: '{{ lookup("env", "AZURE_TENANT") }}' subscription_id: '{{ lookup("env", "AZURE_SUBSCRIPTION_ID") }}'
22.4.19. Network credential type
Select the Network credential type if you are using a local connection with provider to use Ansible networking modules to connect to and manage networking devices.
When connecting to network devices, the credential type must match the connection type:
-
For
local
connections usingprovider
, credential type should be Network. -
For all other network connections (
httpapi
,netconf
, andnetwork_cli
), the credential type should be Machine.
For more information about connection types available for network devices, see Multiple Communication Protocols.
Automation controller uses the following environment variables for Network credentials:
ANSIBLE_NET_USERNAME ANSIBLE_NET_PASSWORD
Provide the following information for network credentials:
- Username: The username to use in conjunction with the network device.
- Password: The password to use in conjunction with the network device.
- SSH Private Key: Copy or drag-and-drop the actual SSH Private Key to be used to authenticate the user to the network through SSH.
- Private Key Passphrase: The passphrase for the private key to authenticate the user to the network through SSH.
Authorize: Select this to control whether or not to enter privileged mode.
- If Authorize is checked, enter a password in the Authorize Password field to access privileged mode.
For more information, see Porting Ansible Network Playbooks with New Connection Plugins.
22.4.20. Access network credentials in an ansible playbook
You can get the username and password parameters from a job runtime environment:
vars: network: username: '{{ lookup("env", "ANSIBLE_NET_USERNAME") }}' password: '{{ lookup("env", "ANSIBLE_NET_PASSWORD") }}'
22.4.21. OpenShift or Kubernetes API Bearer Token credential type
Select this credential type to create instance groups that point to a Kubernetes or OpenShift container.
For more information, see Instance and container groups.
Provide the following information for container credentials:
- OpenShift or Kubernetes API Endpoint (required): The endpoint used to connect to an OpenShift or Kubernetes container.
- API authentication bearer token (required): The token used to authenticate the connection.
- Optional: Verify SSL: You can check this option to verify the server’s SSL/TLS certificate is valid and trusted. Environments that use internal or private Certificate Authority (CA) must leave this option unchecked to disable verification.
-
Certificate Authority data: Include the
BEGIN CERTIFICATE
andEND CERTIFICATE
lines when pasting the certificate, if provided.
A container group is a type of instance group that has an associated credential that enables connection to an OpenShift cluster. To set up a container group, you must have the following items:
- A namespace you can start into. Although every cluster has a default namespace, you can use a specific namespace.
- A service account that has the roles that enable it to start and manage pods in this namespace.
If you use execution environments in a private registry, and have a container registry credential associated with them in automation controller, the service account also requires the roles to get, create, and delete secrets in the namespace.
If you do not want to give these roles to the service account, you can pre-create the
ImagePullSecrets
and specify them on the pod spec for the container group. In this case, the execution environment must not have a Container Registry credential associated, or automation controller attempts to create the secret for you in the namespace.- A token associated with that service account (OpenShift or Kubernetes Bearer Token)
- A CA certificate associated with the cluster
22.4.21.1. Creating a service account in an Openshift cluster
Creating a service account in an Openshift or Kubernetes cluster to be used to run jobs in a container group through automation controller. After you create the service account, its credentials are provided to automation controller in the form of an Openshift or Kubernetes API bearer token credential.
After you create a service account, use the information in the new service account to configure automation controller.
Procedure
To create a service account, download and use the sample service account,
containergroup sa
, and change it as needed to obtain the credentials:--- apiVersion: v1 kind: ServiceAccount metadata: name: containergroup-service-account namespace: containergroup-namespace --- kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: role-containergroup-service-account namespace: containergroup-namespace rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] - apiGroups: [""] resources: ["pods/log"] verbs: ["get"] - apiGroups: [""] resources: ["pods/attach"] verbs: ["get", "list", "watch", "create"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: role-containergroup-service-account-binding namespace: containergroup-namespace subjects: - kind: ServiceAccount name: containergroup-service-account namespace: containergroup-namespace roleRef: kind: Role name: role-containergroup-service-account apiGroup: rbac.authorization.k8s.io
Apply the configuration from
containergroup-sa.yml
:oc apply -f containergroup-sa.yml
Get the secret name associated with the service account:
export SA_SECRET=$(oc get sa containergroup-service-account -o json | jq '.secrets[0].name' | tr -d '"')
Get the token from the secret:
oc get secret $(echo ${SA_SECRET}) -o json | jq '.data.token' | xargs | base64 --decode > containergroup-sa.token
Get the CA cert:
oc get secret $SA_SECRET -o json | jq '.data["ca.crt"]' | xargs | base64 --decode > containergroup-ca.crt
-
Use the contents of
containergroup-sa.token
andcontainergroup-ca.crt
to provide the information for the OpenShift or Kubernetes API Bearer Token required for the container group.
22.4.22. OpenStack credential type
Select this credential type to enable synchronization of cloud inventory with OpenStack.
Enter the following information for OpenStack credentials:
- Username: The username to use to connect to OpenStack.
- Password (API Key): The password or API key to use to connect to OpenStack.
- Host (Authentication URL): The host to be used for authentication.
- Project (Tenant Name): The Tenant name or Tenant ID used for OpenStack. This value is usually the same as the username.
- Optional: Project (Domain Name): Give the project name associated with your domain.
- Optional: Domain Name: Give the FQDN to be used to connect to OpenStack.
- Optional: Region Name: Give the region name. For some cloud providers, like OVH, the region must be specified.
If you are interested in using OpenStack Cloud Credentials, see Use Cloud Credentials with a cloud inventory, which includes a sample playbook.
22.4.23. Red Hat Ansible Automation Platform credential type
Select this credential to access another automation controller instance.
Ansible Automation Platform credentials require the following inputs:
- Red Hat Ansible Automation Platform: The base URL or IP address of the other instance to connect to.
- Username: The username to use to connect to it.
- Password: The password to use to connect to it.
- Oauth Token: If username and password are not used, provide an OAuth token to use to authenticate.
The env
injectors for Ansible Automation Platform are as follows:
ManagedCredentialType( namespace='controller', .... .... .... injectors={ 'env': { 'TOWER_HOST': '{{host}}', 'TOWER_USERNAME': '{{username}}', 'TOWER_PASSWORD': '{{password}}', 'TOWER_VERIFY_SSL': '{{verify_ssl}}', 'TOWER_OAUTH_TOKEN': '{{oauth_token}}', 'CONTROLLER_HOST': '{{host}}', 'CONTROLLER_USERNAME': '{{username}}', 'CONTROLLER_PASSWORD': '{{password}}', 'CONTROLLER_VERIFY_SSL': '{{verify_ssl}}', 'CONTROLLER_OAUTH_TOKEN': '{{oauth_token}}', }
22.4.23.1. Access automation controller credentials in an Ansible Playbook
You can get the host, username, and password parameters from a job runtime environment:
vars: controller: host: '{{ lookup("env", "CONTROLLER_HOST") }}' username: '{{ lookup("env", "CONTROLLER_USERNAME") }}' password: '{{ lookup("env", "CONTROLLER_PASSWORD") }}'
22.4.24. Red Hat Satellite 6 credential type
Select this credential type to enable synchronization of cloud inventory with Red Hat Satellite 6.
Automation controller writes a Satellite configuration file based on fields prompted in the user interface. The absolute path to the file is set in the following environment variable:
FOREMAN_INI_PATH
Satellite credentials have the following required inputs:
- Satellite 6 URL: The Satellite 6 URL or IP address to connect to.
- Username: The username to use to connect to Satellite 6.
- Password: The password to use to connect to Satellite 6.
22.4.25. Red Hat Virtualization credential type
Select this credential to enable automation controller to access Ansible’s oVirt4.py
dynamic inventory plugin, which is managed by Red Hat Virtualization.
Automation controller uses the following environment variables for Red Hat Virtualization credentials. These are fields in the user interface:
OVIRT_URL OVIRT_USERNAME OVIRT_PASSWORD
Provide the following information for Red Hat Virtualization credentials:
-
Host (Authentication URL): The host URL or IP address to connect to. To sync with the inventory, the credential URL needs to include the
ovirt-engine/api
path. -
Username: The username to use to connect to oVirt4. This must include the domain profile to succeed, for example
username@ovirt.host.com
. - Password: The password to use to connect to it.
-
Optional: CA File: Provide an absolute path to the oVirt certificate file (it might end in
.pem
,.cer
and.crt
extensions, but preferably.pem
for consistency)
22.4.25.1. Access virtualization credentials in an Ansible Playbook
You can get the Red Hat Virtualization credential parameter from a job runtime environment:
vars: ovirt: ovirt_url: '{{ lookup("env", "OVIRT_URL") }}' ovirt_username: '{{ lookup("env", "OVIRT_USERNAME") }}' ovirt_password: '{{ lookup("env", "OVIRT_PASSWORD") }}'
The file
and env
injectors for Red Hat Virtualization are as follows:
ManagedCredentialType( namespace='rhv', .... .... .... injectors={ # The duplication here is intentional; the ovirt4 inventory plugin # writes a .ini file for authentication, while the ansible modules for # ovirt4 use a separate authentication process that support # environment variables; by injecting both, we support both 'file': { 'template': '\n'.join( [ '[ovirt]', 'ovirt_url={{host}}', 'ovirt_username={{username}}', 'ovirt_password={{password}}', '{% if ca_file %}ovirt_ca_file={{ca_file}}{% endif %}', ] ) }, 'env': {'OVIRT_INI_PATH': '{{tower.filename}}', 'OVIRT_URL': '{{host}}', 'OVIRT_USERNAME': '{{username}}', 'OVIRT_PASSWORD': '{{password}}'}, }, )
22.4.26. Source Control credential type
Source Control credentials are used with projects to clone and update local source code repositories from a remote revision control system such as Git or Subversion.
Source Control credentials require the following inputs:
- Username: The username to use in conjunction with the source control system.
- Password: The password to use in conjunction with the source control system.
- SCM Private Key: Copy or drag-and-drop the actual SSH Private Key to be used to authenticate the user to the source control system through SSH.
- Private Key Passphrase: If the SSH Private Key used is protected by a passphrase, you can configure a Key Passphrase for the private key.
You cannot configure Source Control credentials as Prompt on launch.
If you are using a GitHub account for a Source Control credential and you have Two Factor Authentication (2FA) enabled on your account, you must use your Personal Access Token in the password field rather than your account password.
22.4.27. Terraform backend configuration
Terraform is a HashiCorp tool used to automate various infrastructure tasks. Select this credential type to enable synchronization with the Terraform inventory source.
The Terraform credential requires the Backend configuration attribute which must contain the data from a Terraform backend block. You can paste, drag a file, browse to upload a file, or click the icon to populate the field from an external Secret Management System.
Terraform backend configuration requires the following inputs:
- Name
- Credential type: Select Terraform backend configuration.
- Optional: Organization
- Optional: Description
Backend configuration: Drag a file here or browse to upload.
Example configuration for an S3 backend:
bucket = "my-terraform-state-bucket" key = "path/to/terraform-state-file" region = "us-east-1" access_key = "my-aws-access-key" secret_key = "my-aws-secret-access-key"
- Optional: Google Cloud Platform account credentials
22.4.28. Thycotic DevOps Secrets Vault credential type
This is considered part of the secret management capability.
For more information, see Thycotic DevOps Secrets Vault.
22.4.29. Thycotic secret server credential type
This is considered part of the secret management capability.
For more information, see Thycotic Secret Server.
22.4.30. Ansible Vault credential type
Select this credential type to enable synchronization of inventory with Ansible Vault.
Vault credentials require the Vault Password and an optional Vault Identifier if applying multi-Vault credentialing.
You can configure automation controller to ask the user for the password at launch time by selecting Prompt on launch.
When you select Prompt on launch, a dialog opens when the job is launched, prompting the user to enter the password.
Credentials that are used in scheduled jobs must not be configured as Prompt on launch.
For more information about Ansible Vault, see Protecting sensitive data with Ansible vault.
22.4.31. VMware vCenter credential type
Select this credential type to enable synchronization of inventory with VMware vCenter.
Automation controller uses the following environment variables for VMware vCenter credentials:
VMWARE_HOST VMWARE_USER VMWARE_PASSWORD VMWARE_VALIDATE_CERTS
These are fields prompted in the user interface.
VMware credentials require the following inputs:
- vCenter Host: The vCenter hostname or IP address to connect to.
- Username: The username to use to connect to vCenter.
- Password: The password to use to connect to vCenter.
If the VMware guest tools are not running on the instance, VMware inventory synchronization does not return an IP address for that instance.
22.4.31.1. Access VMware vCenter credentials in an ansible playbook
You can get VMware vCenter credential parameters from a job runtime environment:
vars: vmware: host: '{{ lookup("env", "VMWARE_HOST") }}' username: '{{ lookup("env", "VMWARE_USER") }}' password: '{{ lookup("env", "VMWARE_PASSWORD") }}'
22.5. Use automation controller credentials in a playbook
The following playbook is an example of how to use automation controller credentials in your playbook.
- hosts: all vars: machine: username: '{{ ansible_user }}' password: '{{ ansible_password }}' controller: host: '{{ lookup("env", "CONTROLLER_HOST") }}' username: '{{ lookup("env", "CONTROLLER_USERNAME") }}' password: '{{ lookup("env", "CONTROLLER_PASSWORD") }}' network: username: '{{ lookup("env", "ANSIBLE_NET_USERNAME") }}' password: '{{ lookup("env", "ANSIBLE_NET_PASSWORD") }}' aws: access_key: '{{ lookup("env", "AWS_ACCESS_KEY_ID") }}' secret_key: '{{ lookup("env", "AWS_SECRET_ACCESS_KEY") }}' security_token: '{{ lookup("env", "AWS_SECURITY_TOKEN") }}' vmware: host: '{{ lookup("env", "VMWARE_HOST") }}' username: '{{ lookup("env", "VMWARE_USER") }}' password: '{{ lookup("env", "VMWARE_PASSWORD") }}' gce: email: '{{ lookup("env", "GCE_EMAIL") }}' project: '{{ lookup("env", "GCE_PROJECT") }}' azure: client_id: '{{ lookup("env", "AZURE_CLIENT_ID") }}' secret: '{{ lookup("env", "AZURE_SECRET") }}' tenant: '{{ lookup("env", "AZURE_TENANT") }}' subscription_id: '{{ lookup("env", "AZURE_SUBSCRIPTION_ID") }}' tasks: - debug: var: machine - debug: var: controller - debug: var: network - debug: var: aws - debug: var: vmware - debug: var: gce - shell: 'cat {{ gce.pem_file_path }}' delegate_to: localhost - debug: var: azure
Use 'delegate_to' and any lookup variable
- command: somecommand environment: USERNAME: '{{ lookup("env", "USERNAME") }}' PASSWORD: '{{ lookup("env", "PASSWORD") }}' delegate_to: somehost