Chapter 10. 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. Note Automation controller encrypts passwords and key information in the database and never makes secret information visible through the API. For further information, see the Automation controller Administration Guide . 10.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. Note 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. 10.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 Resources Credentials . Click Add . Enter the following information: The name for your new credential. Optional: a description for the new credential. Optional: The name of the organization with which the credential is associated. Note A credential with a set of permissions associated with one organization persists if the credential is reassigned to another organization. In the Credential Type field, 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 Save . 10.3. Adding new users and job templates to existing credentials Procedure From the navigation panel, select Resources Credentials . Select the credential that you want to assign to additional users. Click the Access tab. You can see users and teams associated with this credential and their roles. Choose a user and click Add . If no users exist, add them from the Users menu. For more information, see Users . Select Job Templates to display the job templates associated with this credential, and which jobs have run recently by using this credential. Choose a job template and click Add to assign the credential to additional job templates. For more information about creating new job templates, see the Job templates section. 10.4. Credential types Automation controller supports the following credential types: Amazon Web Services Ansible Galaxy/Automation Hub API 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 Thycotic DevOps Secrets Vault Thycotic Secret Server Vault VMware vCenter The credential types associated with 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 . 10.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. Note If the value of your tags in EC2 contain Booleans ( yes/no/true/false ), you must quote them. Warning 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 . 10.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") }}' 10.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 . 10.4.3. 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 . 10.4.4. 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. 10.4.5. 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 . 10.4.6. 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 . 10.4.7. 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 Working with Webhooks . 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. 10.4.8. 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 Working with Webhooks . 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. 10.4.9. 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 Browse 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. 10.4.9.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") }}' 10.4.10. 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 . 10.4.11. HashiCorp Vault Secret Lookup credential type This is considered part of the secret management capability. For more information, see HashiCorp Vault Secret Lookup . 10.4.12. HashiCorp Vault Signed SSH credential type This is considered part of the secret management capability. For more information, see HashiCorp Vault Signed SSH . 10.4.13. 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}}', }, 10.4.14. 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, where BECOME_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 to yes and is used with an empty selection, then it will default to sudo . 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. Note 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. Note 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. Warning Credentials that are used in scheduled jobs must not be configured as Prompt on launch . 10.4.14.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 }}' 10.4.15. Microsoft Azure Key Vault credential type This is considered part of the secret management capability. For more information, see Microsoft Azure Key Vault . 10.4.16. 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 10.4.16.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") }}' 10.4.17. Network credential type Note 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 using provider , credential type should be Network . For all other network connections ( httpapi , netconf , and network_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 from the Options field 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 . 10.4.18. 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") }}' 10.4.19. 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 Container and Instance Groups in the Automation controller Administration Guide . 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 and END 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 10.4.19.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=USD(oc get sa containergroup-service-account -o json | jq '.secrets[0].name' | tr -d '"') Get the token from the secret: oc get secret USD(echo USD{SA_SECRET}) -o json | jq '.data.token' | xargs | base64 --decode > containergroup-sa.token Get the CA cert: oc get secret USDSA_SECRET -o json | jq '.data["ca.crt"]' | xargs | base64 --decode > containergroup-ca.crt Use the contents of containergroup-sa.token and containergroup-ca.crt to provide the information for the OpenShift or Kubernetes API Bearer Token required for the container group. 10.4.20. OpenStack credential type Select this credential type to enable synchronization of cloud inventory with OpenStack. Provide 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) : Provide the project name associated with your domain. Optional: Domain name : Provide the FQDN to be used to connect to OpenStack. If you are interested in using OpenStack Cloud Credentials, see Use Cloud Credentials with a cloud inventory , which includes a sample playbook. 10.4.21. 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}}', } 10.4.21.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") }}' 10.4.22. 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. 10.4.23. 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) 10.4.23.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}}'}, }, ) 10.4.24. 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. Note 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. 10.4.25. Thycotic DevOps Secrets Vault credential type This is considered part of the secret management capability. For more information, see Thycotic DevOps Secrets Vault . 10.4.26. Thycotic secret server credential type This is considered part of the secret management capability. For more information, see Thycotic Secret Server . 10.4.27. 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. For more information on the Multi-Vault support, refer to the Multi-Vault Credentials section of the Automation controller Administration Guide . 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. Warning 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 . 10.4.28. 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. Note If the VMware guest tools are not running on the instance, VMware inventory synchronization does not return an IP address for that instance. 10.4.28.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") }}' 10.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

Commands:
AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SECURITY_TOKEN
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") }}'
GCE_EMAIL GCE_PROJECT GCE_CREDENTIALS_FILE_PATH
vars: gce: email: '{{ lookup("env", "GCE_EMAIL") }}' project: '{{ lookup("env", "GCE_PROJECT") }}' pem_file_path: '{{ lookup("env", "GCE_PEM_FILE_PATH") }}'
ManagedCredentialType( namespace='insights', . . . injectors={ 'extra_vars': { "scm_username": "{{username}}", "scm_password": "{{password}}", }, 'env': { 'INSIGHTS_USER': '{{username}}', 'INSIGHTS_PASSWORD': '{{password}}', },
vars: machine: username: '{{ ansible_user }}' password: '{{ ansible_password }}'
AZURE_CLIENT_ID AZURE_SECRET AZURE_SUBSCRIPTION_ID AZURE_TENANT AZURE_CLOUD_ENVIRONMENT
AZURE_AD_USER AZURE_PASSWORD AZURE_SUBSCRIPTION_ID
client_id secret subscription_id tenant azure_cloud_environment
ad_user password subscription_id
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") }}'
ANSIBLE_NET_USERNAME ANSIBLE_NET_PASSWORD
vars: network: username: '{{ lookup("env", "ANSIBLE_NET_USERNAME") }}' password: '{{ lookup("env", "ANSIBLE_NET_PASSWORD") }}'
--- 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 -f containergroup-sa.yml
export SA_SECRET=USD(oc get sa containergroup-service-account -o json | jq '.secrets[0].name' | tr -d '"')
get secret USD(echo USD{SA_SECRET}) -o json | jq '.data.token' | xargs | base64 --decode > containergroup-sa.token
get secret USDSA_SECRET -o json | jq '.data["ca.crt"]' | xargs | base64 --decode > containergroup-ca.crt
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}}', }
vars: controller: host: '{{ lookup("env", "CONTROLLER_HOST") }}' username: '{{ lookup("env", "CONTROLLER_USERNAME") }}' password: '{{ lookup("env", "CONTROLLER_PASSWORD") }}'
FOREMAN_INI_PATH
OVIRT_URL OVIRT_USERNAME OVIRT_PASSWORD
vars: ovirt: ovirt_url: '{{ lookup("env", "OVIRT_URL") }}' ovirt_username: '{{ lookup("env", "OVIRT_USERNAME") }}' ovirt_password: '{{ lookup("env", "OVIRT_PASSWORD") }}'
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}}'}, }, )
VMWARE_HOST VMWARE_USER VMWARE_PASSWORD VMWARE_VALIDATE_CERTS
vars: vmware: host: '{{ lookup("env", "VMWARE_HOST") }}' username: '{{ lookup("env", "VMWARE_USER") }}' password: '{{ lookup("env", "VMWARE_PASSWORD") }}'
- 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
- command: somecommand environment: USERNAME: '{{ lookup("env", "USERNAME") }}' PASSWORD: '{{ lookup("env", "PASSWORD") }}' delegate_to: somehost