Secrets Management Overview For Developers & DevOps

Secrets management is a critical problem for developers, especially for teams adopting DevOps practices.

Until recently, it was the IT department who was responsible for the security of applications and passwords. They were the ones who typically delegated privileges to individuals. But in today’s DevOps world, developers are both writing and deploying applications, and those applications need access to secrets and credentials.

To deploy an application in a container, a developer needs to provide access to secrets. Each of the different containers and platforms that support application deployment, whether Jenkins, Kubernetes, or another, must have access to secrets to do their job, and this need expands the landscape for attack by bad actors.

Developers are, generally, not security experts. They want to write applications, not manage security. They don’t want to assume the risk or develop the complex skills required to manage secrets within their applications. Moreover, with many developers working on an application, access to secrets needs to be coordinated, creating more points of vulnerability and increasing the possibility of errors.

Let’s take a look at the challenges that secrets management presents for developers, and see how CyberArk Conjur manages this problem centrally across different platforms—thus freeing developers to focus on their applications while, at the same time, reducing the risks inherent in secrets management.

The Challenges

Organizations contend with the tension between maintaining security and providing necessary access. To avoid having users enter credentials multiple times, security levels or roles are assigned.

At some point, however, we have to deal with how to protect the master password or key needed to assign all those security levels. This master key is called “secret zero.” Knowing secret zero provides access to everything. A breach of secret zero renders all other security worthless.

The diverse components involved in deployment create a different set of problems. Container-based solutions such as Docker, Kubernetes, and OpenShift all have built secrets management capabilities into their products. The same is true for cloud solutions like AWS, Azure, and Google Cloud.

These platform-specific solutions can foster the creation of security islands: “A tool or platform that comes built-in with its security components (that manage secrets, access control, audit, compliance, etc.) but that does not facilitate interoperability with other tools or aggregation of security policies, management, and audit data.”

The problem is that each of these islands is managed individually. Without centralized audit or control features, it’s difficult to ensure consistency of policies and enforcement. As the scale of deployment increases, so does the difficulty of centralized management.

Furthermore, “human security islands” can develop, where each team chooses its own security tools to manage its environment, creating a shadow IT function.

Any weak point creates vulnerability for the entire architecture. Any increase in the number of components managing secrets increases the attack surface for bad actors and weakens the overall system.

Conjur Open Source For Secrets Management

Most methods used to protect secrets have at least one master secret, “one key that rules them all,” making it possible for bad actors who discover it to move freely through the organization’s infrastructure.

It’s difficult to secure something without using secrets, but CyberArk Conjur uses strong, multifactor authentication to establish the identity of the container presenting the secret. And it does this without requiring that developers install or manage additional modules, which would create yet another secret zero.

In fact, a single secret is no longer adequate to access everything.

Also, by removing the secrets management from the application code, Conjur removes the task of managing security from application developers, freeing them to focus on feature development.

Conjur provides an automated solution to these challenges that can be integrated into your existing architecture. Conjur is an open-source, programmatic interface that provides methods for secure identification, control, and auditing of nonhuman access across tools, platforms, and cloud environments.

Conjur solves the problems of secret zero and security islands by providing a single consistent interface and backend. It uses secrets management best practices, including strong authentication, role-based access control (RBAC), credential rotation, management, and audit.

The Conjur container authenticator certifies clients and issues strong identity credentials to containerized applications. Conjur can integrate with containers running on platforms such as Cloud Foundry Pivotal, Docker, Kubernetes, OpenShift, and more. It works with the container orchestration systems your applications are already using to authenticate the machines requesting the secrets by using multifactor identification.

To validate access, Conjur uses a variety of attributes available only to trusted containers, such as IP address, securely random UUID, and cryptographic keys. Any one of these by itself doesn’t allow validation, so a stolen credential is of no use to an attacker, since the machine can’t be authenticated.

For more details on how Conjur implements multifactor authentication and authorization see our blog post Don’t Get Pwned by Secret Zero.

Putting Conjur to Work

Development teams work with a wide variety of platforms, and Conjur has the ability to centralize security for virtually all of them, easily.

Suppose your development team builds its applications via Jenkins and deploys to Azure using a combination of Azure App Service instances, Azure Functions, and Kubernetes containers via Azure Kubernetes Services (AKS). Let’s take a look at integrating Conjur secrets management into this real-world scenario.

To use Jenkins with Conjur, you first install and configure the Conjur credentials plugin on your Jenkins host. On the Conjur side, you load the Conjur policies that define the following:

• One or multiple Jenkins hosts. For example, you might define separate hosts for each Jenkins pipeline.
• Privileges for those hosts to authenticate Conjur.
• Conjur variables that hold secret values. The secrets are loaded and managed by Conjur, and when appropriate, the policy can define their automatic rotation.
• Privileges for Jenkins hosts to access the variables

When all configurations are in place, Jenkins pipelines and projects simply reference a Conjur variable using a configured Jenkins ID. For more information, see the Conjur Jenkins documentation.

To integrate with Azure, Conjur provides a secure method of authenticating requests using underlying Microsoft attributes called the Azure Authenticator. Conjur allows for a collection of resources to be identified as one Conjur identity, or for individual workloads to be uniquely identified.

The method for accomplishing this is based on Microsoft Azure Active Directory (Azure AD) authentication, which provides developers with a familiar pattern. The Azure Authenticator is used instead of API key-based authentication. The Authenticator eliminates the Azure security island and provides a higher level of security, while also eliminating the secret zero problem. For more information, see the Conjur Azure Authenticator documentation.

The Kubernetes containers can get the secrets they need from Conjur via the Kubernetes Authenticator (which also works with OpenShift). There are two parts to the integration:

• A Conjur plugin (authn-k8s) exposes additional endpoints in Conjur that authenticate Kubernetes resources.
• The authenticator client, either the Kubernetes Authenticator Client or the CyberArk Secrets Provider for Kubernetes, runs in the application’s pod and facilitates communication with the authn-k8s plugin.

The integration uses certificate-based mutual TLS to authenticate the application and provide a Conjur access token to the application pod. This access token can then be used by the application to retrieve secrets from Conjur.

Conjur access policies must include:

• Variables to store Conjur’s CA and Cert Key
• A webservice that represents the Kubernetes integration
• A host that identifies the application used to authenticate
• Permit statements that whitelist host identities to the webservice.

Conjur includes the tools necessary to connect most combinations of development and deployment, container, and cloud platforms. For more information on integrations, see the Conjur Integrations documentation.

Next Steps

Conjur answers the challenges of secrets management by eliminating secret zero and security island issues and reducing the attack area of distributed systems, by centralizing and hardening the security around secrets via multifactor authentication. It removes the burden of secrets management from developers, saving time and reducing the chance of costly errors.

Conjur provides the integration with many of the modern development tools you’re using to support complex development and deployment environments, including Ansible, Azure, AWS, Cloud Foundry, Docker, Jenkins, Kubernetes, OpenShift, Pivotal, Puppet, and Terraform.

For more information visit: https://developer.cyberark.com/.

Try Conjur for yourself and discover how easy it is to use it in your application. Get started today by installing Conjur.

As always, look for my on CyberArk Commons if you have questions about this post or want to chat.