Ansible

Integration with Ansible

SSMCM integrates with Ansible through its API, allowing you to run Ansible playbooks on AWS EC2 instances, Azure virtual machines, and so on. It also allows you to create infrastructure from scratch, configuring it at the same time according to the requirements of the organization.

At this time, you can run Ansible playbooks from SSMCM for the following types of objects:

• AWS EC2
• AWS RDS
• Azure VMs
• Azure SQL servers
• Azure SQL databases
• Google Cloud VMs

Discovery of job templates

SSMCM will get the list of Ansible templates periodically (every 15 minutes) and display them as available when running them on an instance. For these templates to be executable from SSMCM, they must be Configure with the following parameters enabled:

• Job type: Prompt on launch
• Inventory: Prompt on launch
• Credential: Prompt on launch
• Limit: Prompt on launch
• Extra variables: Prompt on launch
• Enable notifications pointing to the SSMCM URL of the corresponding environment

If any of these conditions are not met, the template will be displayed as disabled for the reason Not active:

In addition, depending on the type of template, it is important to check the option "Enable privilege escalation".

It is also advisable to check the box "Enable concurrent jobs", since otherwise, only one job of each template will be allowed to run at a time.

For a template to appear in the list of available templates for a given object, you must indicate from the template to which type of objects it applies; to do this, in the "Variables" section of the template, you must specify A configuration similar to the following, for example, for virtual machines:

job_types:
  - aws_ec2
  - azure_vm
  - gcloud_vm

For MySQL databases:

job_types:
  - aws_rds_mysql

Or for Microsoft SQL Server databases:

job_types:
  - aws_rds_mssql
  - azure_sql_database

Format of credentials

In order for Ansible to connect to the target computers, they must be added to its database, which is stored in encrypted form.

When launching a job from SSMCM, it is detected if the computer credentials exist in Ansible according to a Specifications described below. If they exist, information about them will be displayed when launching the job; in case Otherwise, information on the required credentials and how to create them will be indicated:

Tip

The name of the credential used during the execution of a template can be modified by adding a variable ansible_credentials.

Credentials associated with objects

For Ansible to connect to computers, SSH (Linux) or username/password credentials must first exist (Windows). Ansible's credential chest will be searched for a credential with the following named:

• If the object has a tag credential, this value will be used
• For AWS instances: aws-ACCOUNT_ID-SLUG_KEY_NAME; for example, for a named KeyCompass_KEY1 for the ID account 0123456789, A named credential would be sought aws-0123456789-compass-key1
• For AWS RDS: aws-ACCOUNT_ID-rds-default
• For Azure VM: azure-SUBSCRIPTION_ID-vm-default
• For Azure SQL Server and Database: azure-SUBSCRIPTION_ID-sql-default

Credentials not associated with objects (for infrastructure creation)

To enable Ansible to manage objects from cloud providers (for example, create AWS EC2 instances, machines Azure virtual, etc.), credentials to connect to those providers must exist in Ansible. In this case, The following naming pattern is used:

• For accounts of AWS: aws-ACCOUNT_ID
• For accounts of Azure: azure-SUBSCRIPTION_ID

Login User

Normally, the APIs to carry out the inventories of machines of the different suppliers, do not supply Default user information with which to connect to them. Therefore, the integration of SSMCM and Ansible, try to detect this user as follows:

• If the object contains a tag username, The value of that tag will be used as the connection user
• If the provider returns the connection user through its API, the API will be used.
• In other cases, we try to detect from the image from which the machine was created:
  • Canonical Ubuntu → ubuntu
  • http://www.openvpn.net/ → openvpnas
• For AWS EC2 instances, the user will be used ec2-user
• In any other case, the user will be used user

This information is displayed in a prompt when running a template:

Tip

The user used during the execution of a template can be modified by adding a variable ansible_user.

Jumping teams / bastions

To connect to computers that are not directly accessible from the Internet, SSMCM tries to detect, through your inventory, a way to reach those instances through jumping teams. Using these hop computers, accessible from the Internet, or at a minimum, from the instances where you are deployed the Ansible service, allows you to run playbooks on the machines on the network that are connected to that computer.

SSMCM attempts to detect jumping machines as follows:

• The VPC (or equivalent, depending on the provider) to which the instance to be treated belongs is detected
• An instance belonging to that VPC is searched for with the following requirements:
  • In its name contains "VPN" or "BST"
  • Has public IP

If such an instance is found, Ansible, through its integration with SSMCM, will attempt Connect to the target instance through the detected hop machine.

if no hop machine is detected the public ip of the target instance is used if you had it, and if not, the private IP; In the latter case, the connection will probably fail, since instances are typically not accessible from the Ansible service unless there is a connection VPN made explicitly from the network from which Ansible is served.

If the jumping equipment has been detected, by default intermediate credentials will be used to authenticate with this equipment; By default, the user will be used ansible, and the public key with which Ansible will connect must be installed. To facilitate this task, a playbook is provided that automatically configures a jumping team, as long as its initial credentials already exist in Ansible.

All this information is displayed as a warning at the time of running a playbook:

• Computers with public IP (without jumping equipment):

  

• Computers with private IP (no jumping equipment):

  

• Teams with jumping equipment:

  

Windows Computer Detection

Some providers (AWS) do not provide information about the operating system running an instance. Ansible needs know how to connect to computers, so for Windows computers, you must specify the WinRM protocol in the variables of the team. When no information is available about the type of operating system, inventory integration between Ansible and SSMCM try to detect it using the following checks:

• For AWS instances that have SSM enabled, you get the OS reported by SSM
• If the image from which the instance was created, contains "Windows", it is assumed that it is a Windows instance
• If the instance name contains "Windows", it is assumed to be a Windows instance

In any other case, it is assumed that it is a Linux machine.

Access to Windows computers

While Linux computers use SSH to access and manage machines, Windows Ansible uses the protocol PSRP. This is because the PSRP module in Ansible supports proxy, to access machines on internal (non-public) networks, while the WinRM module He can't stand it.

By default, the integration between SSMCM and Ansible generates an inventory defining that for Windows computers, Ansible must use the PSRP protocol over HTTP; although the HTTPS protocol is supported by PSRP, it is not enabled by default in a standard installation of Windows (in a future version you can configure the PSRP protocol by which Ansible connects through tags to use HTTPS if it has been configured on the computer).

In order for Ansible to access Windows machines, either directly through their public IP if they have one, or through their private IP through jump computers or bastions, ports 5985/TCP (PSRP/HTTP) and 5986/TCP (PSRP/HTTPS) must be allowed both at the level of security groups of the cloud provider, as through the Windows firewall; This last requirement can be done in two simple commands:

netsh advfirewall firewall add rule name="PSRP HTTP 5985" dir=in action=allow protocol=TCP localport=5985
netsh advfirewall firewall add rule name="PSRP HTTPS 5986" dir=in action=allow protocol=TCP localport=5986

Credentials on Windows machines

Keep in mind that although there are several Windows machines created with the same "Key", each one will have a different password, so you will have to create the corresponding credential in AWX for each machine and indicate it in the "credential" tag.