Peter Greenwood, PAM Practice Team Lead, SecureITsource, Inc.
secureITsourceLABS is the culmination of numerous initiatives, client use case demonstrations, and proprietary processes built by our team over time. We are laser focused on delivering best-of-breed identity and privileged identity solutions to our clients and to that end, we are always building. The role of privileged identity in the dynamic landscape of today’s cloud-centric enterprise is more important than ever because processes are often orchestrated by machines, not humans. secureITsourceLABS is heavily invested in automation, Continuous Integration & Continuous Delivery (CI/CD) pipelines, DevOps, Containerization and how these processes use secrets in the Software Development Life Cycle (SDLC) process.
We are seeing many of our clients, large and small, taking their application workloads to the cloud and/or taking on full scale DevOps projects. To realize the potential upside in automating the SDLC process, organizations must take steps to secure the code being run by these processes. It is common for code repositories to contain API and SSH keys, plaintext passwords, and other sensitive data that if left unsecured, could be the catalyst for a breach. In order to secure these highly automated environments, security products must become more flexible to address these use cases and still allow development teams to maintain the velocity they have become accustomed to.
Enter CyberArk Conjur, machine identity, and DevSecOps.
The term DevSecOps is not new but machine identity and the way in which Conjur approaches privileged access and secrets management is. “What is Conjur?” you may be wondering at this point. On May 11th of 2017 CyberArk acquired Conjur with the promise to revolutionize DevOps and drive greater business agility. (link) CyberArk is a well-established market leader in the Privileged Access Management space while Conjur is a young security-centric company with a fresh approach on securing secrets in highly automated ephemeral environments. CyberArk has been securing application identities for many years with their best-of-breed Enterprise Password Vault (EPV) and Application Identity Management (AIM) modules but AIM was designed to support mostly static monolithic applications that have made up the majority of the enterprise application architecture for decades. Conjur addresses the new challenges of today’s enterprise application landscape by delivering a secrets management solution that fits into the DevOps landscape in frictionless manner.
For the purpose of this article, I intend to show some what we think makes Conjur different, how Conjur can integrate with your DevOps pipelines, and touch on Conjur’s password provider Summon.
Security as Code
“Infrastructure as code” and “configuration as code” are terms that describe when proven SDLC best practices are applied to other areas of IT. It is essentially code managing code but it goes well beyond simply writing scripts or automating processes. The emergence of tools like Puppet, Chef, Ansible, Jenkins, Docker, Kubernetes etc. have ushered in a new way managing infrastructure and configuration. Security as code and DevSecOps describe processes when core security processes are integrated into the DevOps process in a manner that doesn’t slow the process. Security as code is a key tenet of Conjur. Security rules are written in files, checked into source control and loaded into the Conjur server. This allows you to treat security policy as you would any other source control asset, adding more transparency and collaboration to your organization’s security requirements. This tight integration into the DevOps workflow allows Conjur to handle traditional security measures like logging, auditing, credential rotation, access control, and SIEM integration without disrupting the process.
Simple Policy Declaration
Conjur uses a Role Based Access Control (RBAC) model to control both human and machine identity in the same fashion. Policy files are written in YAML which makes them easy to read and write by machines and humans alike. YAML files are language-agnostic which makes it highly extensible and easy to integrate with most DevOps tools currently in use. Conjur’s policy framework allows you to define your entire infrastructure in declarative files that can be safely checked into source control. This layer of convenience and transparency will make the security admins, developers, and auditors jobs much easier when complying with audit requests and troubleshooting. Furthermore, Conjur policy consists of only 9 elements; policy, user, group, host, layer, variable, web service, role grant, and permission grant. An entire organizational security policy can be translated and securely executed using just those 9 elements.
For instance, in the policy sample below; the “cloud-app” policy is owned by the security_admin group. It permits “kube_master” read and execute privileges on the variables “aws_access_key_id” and “aws_secret_access_key“. The variables are encrypted and stored within the Conjur appliance and fetched using the Conjur Provider, Summon. This solution provides end-to-end encryption without ever exposing the secrets value.
- !policy id: cloud-app owner: !group security_admin body: - &variables - !variable aws_access_key_id - !variable aws_secret_access_key - !permit role: !layer /kube_master privilege: [ read, execute ] resource: *variables
Host Factory Tokens
Perhaps the most compelling use case that Conjur solves is permitting robot identities access to secrets for the purpose of spawning new servers, VMs, and containers. Orchestration servers are quickly becoming a primary target for bad actors because those servers need access to secrets to perform their functions. Products such as Puppet, Chef, and Kubernetes are all able to create, decommission, and manage servers, containers, and services on demand and as needed with little or no human intervention. While this type of automation has great benefits, it is difficult to implement securely.
Username/Password combinations are checked into source control, SSH/API keys are passed as command line arguments, and those keys are not rotated.
The Conjur solution addresses these issues with what they call a Host Factory. Host Factory allows authorized users and services to create a new host and add it to the appropriate layer. A trust is created between the Host Factory service and the orchestration server to allow new hosts to be spawned and added to Conjur for management at the appropriate security layer. There are several layers and controls in place to make sure the token service is not compromised. The below diagram shows a use case for the host factory token service and how the token holder only has access to the needed secret, not all secrets managed under that particular layer.
Summon facilitates the passage of secrets from the secure Conjur server into application code fully encrypted end-to-end. It was developed by the Conjur team and then released to the open source community on Github. Summon allows you to also check your secrets into source control alongside your policy as a summon file which is also written in YAML. This allows a process like a Docker Run command that would normally contain an environment variable passed at the command line to be run with reference to a summon file instead. The summon file facilitates the retrieval and parsing of the secret, injects it into any process, and disposes of it once the process is done. Cool stuff! The requirements to use Summon are simple; any language/process which accepts a variable can effectively use Summon. Summon follows a simple contract with the process calling it, it is;
- They take one argument, the identifier of a secret (a string).
- If retrieval is successful, they return the value on stdout with exit code 0.
- If an error occurs, they return an error message on stderr and a non-0 exit code.
Conjur has two offerings available, Conjur Enterprise, and an open source Conjur CE. Conjur CE is the core of Conjur Enterprise making all efforts put into building policy and establishing roles with the CE version completely transferable to the EE version. Conjur CE is delivered as a container and all of the documentation necessary to build your own Conjur server and get started securing secrets in your environments is available on Github and Conjur.org. It is nice to see a major security vendor delivering an enterprise grade security product to the open source community in a meaningful way. The CyberArk/Conjur Github page also has dozens of projects, integrations, demonstrations, and really great content to get you out of the weeds quickly.
The secureITsourceLABS team have been putting Conjur through the paces in our AWS lab and we have been very pleased with its ability to deliver on the promise of a friction-less security workflow without slowing down automated processes. In the future, we look forward to delivering technical demos and guides to help make DevSecOps workflows a reality.