For DevOps, automation is a core part of its DNA. Friction can stifle automation, eroding speed and agility, killing a DevOps project.
Security doesn’t make it any easier. It can be complicated, cumbersome, and replete with manual configurations, causing friction that results in DevOps avoiding it like the plague. However, that also leads to inadequate security controls around privileged identities, entitlements, systems, and data, putting your organization at risk of a data breach.
Security practitioners would love nothing more than for DevOps to pull out a chair and give security a seat at their table. But often security vendors are their own worst enemy.
When embracing the DevOps community, many vendors fall short in two main ways.
First, they impose their processes and technologies on DevOps, often mistakenly believing that security is the only thing that matters. So, they package up the important stuff – such as role-based access control and secrets management – and tell DevOps it needs to adapt. They position their product as an essential overarching umbrella versus embedding it into the CI/CD pipeline in a more natural way that preserves speed and agility. That introduces friction.
The second challenge is that most access control security solutions are long in the tooth, designed for data center workloads and human IT admin login. They don’t play nicely in DevOps’ agile world, plaguing it with lots of legacy manual interactions that slows everything down.
Let’s take a simple example.
A new project spins up in AWS and many engineers are cutting code to develop a business application running in a new VPC. The app consists of hundreds of microservices spread across dozens of Docker containers. When the application starts up, microservices need configuration data to tell them what to do and how to do it. They also need credentials to authenticate to other services.
The project has a vault to facilitate this situation that stores credentials and configuration data as secrets. RESTful APIs enable the microservices to log into the vault and obtain what they need. This function is especially critical when the application auto-scales in response to increased user demand. The new workloads need identical configuration data.
So, what’s wrong with this picture?
At issue is a lot of manual effort for both developers and operations teams. For every workload that needs to check out a credential or secret from the vault, the typical manual setup is:
- Per workload, Ops creates an OAuth2 client application and a service account in the vault that the workload can ultimately use to authenticate itself to the vault. Ops exports this as a BASE-64 token that the developer uses in their code.
- The developers incorporate service accounts and tokens into their applications or local configuration files.
- Ops assigns roles to the service accounts to permit them to check out specific credentials and secrets from the vault.
- Ops configures scopes for the OAuth2 clients, to constrain which vault APIs the various workloads can access.
- The developers obtain OAuth2 code and incorporate it into their code, enabling the workload to talk OAuth2 to the vault. They can then get a bearer token to access vaulted secrets and obtain other tokens to talk to other services.
Then it’s rinse and repeat for each workload. That might be a few dozen, hundreds, or even thousands of workloads. It’s this degree of friction that contributes to DevOps relegating PAM to the sidelines.
In a recent blog we discussed how Centrify Delegated Machine Credentials reduces this kind of friction, fitting nicely with DevOps’ tools to deploy virtual instances and containers without forcing changes. Instead of a service account per workload, we have a service account per machine, and the machine can delegate its credential for use by the workloads running on it. For DevOps, everything is automated, eliminating the friction, even in auto-scale environments. For Sec, this infrastructure-as-code approach reduces the attack surface, eliminating the need for thousands of potential exposure points while increasing agility.
To further these automation efforts, we’ve added support for three popular environments: Ansible, PowerShell, and Python. These new capabilities help developers and operations teams overcome the challenges outlined above, using familiar tools.
Ansible Roles for Centrify Client Management on UNIX and Linux
Available from our GitHub repo, Centrify provides a new set of Ansible roles you can use from the Ansible CLI or Ansible Tower to manage Centrify Agents. Playbook variables allow you to granularly control Centrify Agent deployment, configure Centrify Agent features, and enroll Centrify Agents in Active Directory or a Centrify Platform tenant.
Ansible Tower Module for Auth and Secrets Management
Available as part of the AWX community project and Ansible Tower, this new Ansible Tower plugin module allows customers to retrieve credentials from the Centrify Privileged Access Service vault when running tasks against systems enrolled in your Centrify Platform tenant.
PowerShell SDK for the Centrify Platform
Available from our GitHub Repo, this SDK is a PowerShell module for the Centrify Platform. The module provides wrapper functions for the Centrify Platform APIs as PowerShell cmdlets you can use from scripts or an interactive PowerShell session. You can install the PowerShell module on a Windows Server or Workstation running PowerShell 5.0 or above.
Python SDK for the Centrify Agent for *NIX
For projects that leverage Centrify’s Authentication Service Agent for *NIX, Centrify offers two new Python modules that you can import as libraries into your Python scripts. Of value mainly for your Ops team, they help automate administrative and maintenance tasks such as querying for Centrify Agent status, querying for Centrify Zone user information, and flushing the Agent cache.
Get your DevOps teams to embrace role-based access controls and secrets management by taking friction out of the picture. Learn more about Centrify’s solutions for DevOps on our website, and check out our GitHub repo (https://github.com/centrify) to find many example scripts to automate your Centrify experience and further reduce friction for DevOps.
This is written by the individual author in his/her personal capacity, and the opinions, views and/or thoughts expressed herein are solely the author’s own. They are not intended to and may not necessarily reflect the official policy or position, or the opinions or views of ThycoticCentrify or its affiliates, employees, or any other group or individual.