Ansible and PCI DSS Compliance

Archives Ansible Project
1

Hi,

We have a Cardholder Data Environment which is in scope for PCI compliance, and we intend to manage the environment using Ansible.

I’ve read a few articles which suggest that using Ansible is a Good Thing for PCI compliance, as it keeps the environment consistent and prevents deviations from the desired state etc. However, section 8.5 of the (version 3.2) PCI DSS guidelines requires that:

  • Generic user IDs are disabled or removed.

  • Shared user IDs do not exist for system administration and other critical functions.

  • Shared and generic user IDs are not used to administer any system components.

This conflicts with the way we (and I expect many other organisations) would normally use Ansible (i.e. with its own user account for ssh access to every managed host, with privileged access via sudo) since this provides generic administrative access to anyone who can su to the ansible user.

I’ve been trying to think of various ways to satisfy the PCI requirement, but I haven’t managed to find anything that works yet.

Some things I’ve considered:

  • Disallow TTY allocation, so users can’t log in to managed hosts after switching to the ansible user.
  • Set a login shell to /bin/nologin or /bin/false on managed hosts.

Clearly Ansible requires an interactive login in order to function correctly.

Another approach might be to remove the ansible user altogether, and ensure individual user accounts have sufficient privileges to run ansible playbooks. This might be a viable solution, but I was also wondering if any other Ansible users have managed to find A Better Way, or approach things from a different angle?

Thanks,

Simon.

2

My reading of the PCI DSS requirements are that these accounts refer to user accounts rather than process accounts. I have disabled access to the ansible account(s) via password and ensured that only sshkey access is granted. This means that the sshkey is king and must not be stolen of course. You could also try restricting the ansible account(s) to access servers only from specific hosts (i.e. your ansible servers) to make life a little harder for anyone who manages to get their hands on the keys.

My last place went through exactly this dilema when rolling out HPSA to govern user access. All ssh access had to be blocked, but we made the case for the ansible account(s) to IT Security and they were happy with the lock-down we gave the accounts.

3

Thanks Duncan. That’s pretty much the way we have our setup at the moment. There’s an ssh key, and a sudo su command, and another ssh key passphrase to get past before anyone can run any playbooks. So I think that satisfies the two-factor authentication requirement for CDEs.

The problem I can see though, is that by necessity a handful of people are able to switch to the ansible user. Once they do that, they can hop onto any other machine as that user and do Terrible Things - and if all those people happened to be logged in to the ansible host at the same time, it would be difficult to identify with any certainty who had done what. And since the ansible host also manages itself, it would be reasonably easy to erase any audit logs on that machine as well, just for good measure.

I’m pretty sure this would fail a PCI audit.

4

Hi Simon,

I was wondering how did you deal with this in the end?
We are currently facing a similar issue and I would be very interested in any idea on how to square the circle

5

Hi Emanuele,

As per the PCI DSS guidelines, our common ansible account was definitely considered a ‘generic account’ for administration purposes, so we had to remove the account’s admin rights and its ability to log in to the ansible-managed hosts. Now we only use that generic account to pull the latest ansible code (from its dedicated git repository). So…

  • Each admin user can use sudo to switch to that non-privileged ansible account in order to run the git pull script to update the ansible code base.
  • Each admin is a member of the ansible group, so the ansible playbooks are readable.
  • Each admin has appropriate ssh access (via a passphrase-protected ssh key) and privileges (password-protected sudo) on the managed hosts.
  • Playbooks can now only be executed from an admin’s personal account.

So each step of the process is logged and auditable, and the playbooks run as a specific user.

So in order to make any changes, each user must have an ssh key, a passphrase and a password, so we’re confident that this satisfies the MFA and auditability requirements for a secure environment.

Hope that helps,

Simon.