choosing secrets management solution

Developer’s Guide to Selecting a Secrets Management Solution

The role of the developer has changed a great deal in recent years. Application architectures now include microservices, distributed systems, and container-based deployments. These changes, along with the shift to using a DevOps model for development, have altered the ways in which developers need to approach their application design as well as their operations management and their system security.

In this article, we will explain what secrets management is and how to go about selecting the best solution for your development teams. We’ll start by examining which problems a secrets management solution can solve and also why you need a secrets management solution in place. Then, we’ll wrap up by showing you how to find a solution that meets the technical requirements of your team.

 

What is Secrets Management and Why Do You Need It?

A secret is any piece of digital information that needs to have restricted access. Secrets can include SSH keys, credentials to access secure resources (such as databases and APIs), cryptographic keys, and access tokens, just to name a few. Developers might need access to these secrets, but more often than not, it’s non-human users that need access to them.

When we talk about non-human users, we’re referring to services and applications that need access to secure resources. There are different ways for these “users” to attain security credentials, but as the underlying hosts of these services become more ephemeral, managing access becomes an increasingly difficult problem to solve.

Conceptually, it’s easy to understand why a centralized and integrated secrets management system would be beneficial. It’s also crucial to understand that choosing an inadequate solution, or not implementing one at all, puts your organization at risk of being infiltrated by malicious entities. Even if your specific systems contain very little valuable data, a hacker could use them as a springboard to access other systems within your organization.

 

Assessing Development Needs

Let’s consider what your development and operations teams will need when it comes to secrets management. You must have a way to securely store and distribute secrets to users based on their needs and their access rights. As application designs move from monolithic to microservice-based architectures, the ability to automate the authentication and distribution of credentials grows from important to imperative.

It is also essential to consider the impact of secret lifecycle management. Regularly rotating secrets is a critical component of a comprehensive security plan, and you’ll want the process of replacing and distributing secrets to be seamless.

While not explicitly related to secrets management, I’ve observed that teams are more willing to adopt solutions that provide demonstrable value and have a short learning curve. Solutions that are easy to understand and simple to implement have a much higher chance of success in engineering organizations.

 

Additional Security Features

Before we start looking at potential solutions, let’s consider some additional features that your secrets management solution should include. The first question is whether you have a centralized or a decentralized system. A centralized system offers greater control and consistency at an organizational level. If you can integrate your secrets management with your existing corporate systems, you’ll be able to set up rules for adding and removing access. Selecting a system that facilitates role-based access control (RBAC) also simplifies system administration and ensures that each user receives only the access they require based on their role.

In addition to centralized control, it’s essential that all secrets are encrypted when not in use. The transmission of secrets should only take place using secure and encrypted protocols. Finally, the system should support secret lifecycle management, including the immediate revocation of secrets if they become compromised.

 

Conjur: Designed with Your Development Team in Mind

By leveraging the experience and knowledge gained from years of industry leadership, CyberArk created Conjur as an open source offering that meets and exceeds all of the requirements listed above. Designed as a secrets and machine identity management system for modern infrastructure, Conjur is available as a Docker container, which makes it almost effortless to introduce to your existing environment.

Affiliated tools like Secretless Broker and Summon integrate with your application and handle tasks like authentication and secret retrieval in a secure and proven manner. This approach allows you to focus on building features instead of worrying about managing secrets and authentication.

If you’d like to learn more about Secretless Broker, Conjur, and other open-source projects, you can join the conversation on the CyberArk Commons Community. The community is dedicated to developers, engineers, cybersecurity researchers, and other technically-minded people. To discuss Kubernetes, Secretless Broker, Conjur, or CyberArk Threat Research, join me on the CyberArk Commons discussion forum.