Integrating with Ansible

Centrify Privileged Access Service integrates with Ansible using playbooks and roles. Ansible automation for Centrify PAS is done by using:

Note:   A minimum of Ansible AWX 18.0 is required to list Centrify Vault as a supported Credential.

How Ansible Works

Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs.

It has been designed for multi-tier deployments since day one. Ansible models your IT infrastructure by describing how all of your systems interrelate, rather than just managing one system at a time.

It uses no agents and no additional custom security infrastructure, so it's easy to deploy. Most importantly, it uses a very simple language (YAML, in the form of Ansible Playbooks) that enables you to describe your automation jobs in a way that is similar to plain English.

For more information, reference docs.ansible.com.

Efficient Architecture

Ansible connects to your nodes and pushes out small programs to them. These programs are called Ansible modules, and are written to be resource models of the desired system state. Ansible then executes these modules (over SSH by default), and removes them when finished.

Your library of modules can reside on any machine. No servers, daemons, or databases are required. Typically you'll work with your favorite terminal program, a text editor, and probably a version control system to keep track of content changes.

SSH Keys

Passwords are supported, but SSH keys with ssh-agent are one of the best ways to use Ansible. If you want to use Kerberos, that's good too; there are lots of options.

Note:   Root logins are not required. You can login as any user, and then su or sudo to any user.

Ansible's authorized_key module is a great way to control which machines can access which hosts. Other options, like Kerberos or identity management systems, can also be used.

Copy 
ssh-agent bash
ssh-add ~/.ssh/id_rsa

Manage Your Inventory in Simple Text Files

By default, Ansible represents what machines it manages using a very simple .ini file that puts all your managed machines in groups that you choose.

To add new machines, no additional SSL signing server is involved, so there's never a hassle in deciding why a particular machine didn’t get linked up due to obscure NTP or DNS issues.

If there's another root source in your infrastructure, Ansible can also plugin to that. For example, a drawing inventory, group, and variable information from sources like EC2, Rackspace, OpenStack, and more.

Here's an example of a plain text inventory file:

Copy 
[webservers]
www1.example.com
www2.example.com
[dbservers]
db0.example.com
db1.example.com

Once inventory hosts are listed, variables can be assigned to them in simple text files (in a subdirectory called group_vars/ or host_vars/) or directly in the inventory file.

Or, as previously mentioned, use a dynamic inventory to pull your inventory from data sources like EC2, Rackspace, or OpenStack.

Using Ansible For Ad Hoc Parallel Task Execution

Once you have an instance available, you can talk to it right away without any additional setup:

Copy 
ansible all -m ping
ansible foo.example.com -m yum -a "name=httpd state=installed"
ansible foo.example.com -a "/usr/sbin/reboot"

Note:   We have access to state-based resource modules as well as running raw commands. These modules are extremely easy to write, and Ansible ships with a fleet of them so most of your work is already done.

Note:   Ansible contains a giant toolbox of over 750 built-in modules.

Using Playbooks

Playbooks can finely orchestrate multiple slices of your infrastructure topology, giving you very detailed control over how many machines to tackle at a time.

Ansible's approach to orchestration is one of finely-tuned simplicity. Your automation code should make perfect sense to you years down the road and there should be very little to remember about special syntax or features.

Here's what a playbook looks like:

Note:    This example is just a teaser. See docs.ansible.com for the complete documentation and more in-depth playbook examples.

Copy 
---
- hosts: webservers
serial: 5 # update 5 machines at a time
roles:
- common
- webapp
- hosts: content_servers
roles:
- common
- content

An example app_config.yml might look like:

Copy 
---
- yum: name={{contact.item}} state=installed
with_items:
- app_server
- acme_software
- service: name=app_server state=running enabled=yes
- template: src=/opt/code/templates/foo.j2 dest=/etc/foo.conf
notify:
- restart app server

The Ansible documentation explores this in much greater depth. There’s a lot more that you can do, including:

  • Take machines in and out of load balancers and monitoring windows.
  • Have one server know the IP address of all the other servers, using facts gathered about those servers, and using them to dynamically build out configuration files.
  • Set variables, prompt for variables, and set default values for variables.
  • Use the result of one command to determine whether to run another command.

There are lots of advanced possibilities but it's easy to get started.

Most importantly, the language remains readable and transparent, and you never have to declare explicit ordering relationships or write code in a particular programming language.

Extend Ansible: Modules, Plugins and API

If you want to write your own extensions, Ansible modules can be written in any language that can return JSON. For example, Ruby, Python, bash, etc.

Inventory can also plug into any data-source by writing a program that speaks to that data-source and returns JSON. There are also various Python APIs for:

  • Extending Ansible connection types (SSH is not the only transport possible)
  • Extending Ansible call-backs (how Ansible logs, etc)
  • Adding server-side behaviors.

Create a Credential in Ansible AWX

  1. Login as an Administrator to the AWX Portal
  2. Navigate to Resources > Credentials and click on the Add button.
  3. Set the Name for the Credential profile. For example Centrify Vault.
  4. Set the Credential type to Centrify Vault Credential Provider Lookup.
  5. Enter your Centrify tenant URL. For example https://abc1234.my.centrify.net
  6. Enter the name of the Centrify Service User created earlier, For example ansible@mycompany.com where mycompany.com is the login suffix of the Service User.
  7. Enter the password of the Centrify Service User created earlier.
  8. Click on the Test button to validate the Credential profile.
  9. The test will prompt you for the following:
    1. Account name for the credential checkout from the Vault.
    2. Name of the system this account is registered on. For example, root on server1234.
  10. Save the Credential Profile after the test is complete.