While valuable, secrets management also can be difficult for DevOps teams to employ. Here’s what you need to know

Business is all about speed. Companies want to innovate and deliver functionality faster to remain competitive. This explains the increasing popularity of DevOps as a go-to model for rapid application delivery. A recent Gartner report indicated that DevOps adoption is a growing alternative to traditional waterfall and agile development methodologies, but also pointed to key challenges with security and compliance.

For example, the report noted that DevOps practices encourage automation to achieve scale, but that security is traditionally manual, gate-driven and heavy on processes. In addition, the majority of developers have zero knowledge of secure coding, even many who are well-versed in agile and DevOps.

But there is another critical component of data security for DevOps teams: secrets management. In DevOps, “secrets” are typically authentication credentials used in applications and services. This may include usernames and passwords, either system-to-system or database; API tokens; SSH keys; encryption keys; and so on. Secrets are the keys to your data and, when handled casually, can open the doors to a serious data breach or intellectual property theft.

Secrets Management Presents Challenges

Developers often inadvertently leave behind sensitive pieces of code embedded in applications, files and code repositories. One real-world example is the way in which some developers use GitHub, a hugely popular source-code management system and the largest source-code repository in the world. Most developers seem to use GitHub casually, leading to increased risk of insider threats and hacking incidents. In one such incident in 2016, hackers penetrated Uber’s source code repository via GitHub, accessing intellectual property, AWS credentials and the personal data of more than 7 million Uber drivers and 50 million customers.

There are three main reasons why secrets management is challenging for DevOps teams:

1. Secret sprawl. Increased adoption of the cloud-native development model and the emergence of multi-cloud infrastructures has led to a proliferation and decentralization of secrets. If left to their own devices, these secrets can sprawl over time, leading to data breaches and privacy concerns.

2. A disparate set of tools. Many DevOps teams use different sets of tools for different phases of the development process and often struggle to have a centralized system that can integrate with all these tools and systems. Cloud-native secrets management tools are limited to the specific cloud provider and may not be effective in a multi-cloud scenario. An effective secrets management strategy should be able to integrate and work with every tool in the DevOps workflow and across cloud providers.

3. DevOps blind spots. Most enterprises are unaware of where their secrets are located, who has access to them or whether the secrets have been changed. This lack of understanding of the functioning of the DevOps pipeline often increases the risk of an internal data breach.

Today, most enterprises use containers to package and deploy applications. Gartner estimates that by 2022 nearly 75% of organizations will be running containerized applications in production. Oftentimes, in a container-driven environment, the groups responsible for developing applications are distinct from the groups in charge of deploying applications. Furthermore, database administrators by and large have (or should have) access to the keys, tokens and secrets.

In this setting, a major challenge is how to enable application development and deployment in the presence of this segregation without compromising secrets. If a developer has a piece of code inside a container that requires access to a secret key, then this secret value can be hard-coded into the code itself or included as part of the container image. But both of these options have detrimental security implications because they expose secret values to all those who can view the source code or deployment parameters, thereby violating the principle of least privilege.

Instead, secrets can be securely passed to the containerized code during actual runtime. Using a utility based on a container-orchestration system such as Kubernetes allows the secure transmission of secrets at runtime, meaning the secrets don’t need to be exposed while building or deploying the application. Rather, the utility can monitor the environment in real-time and inject secrets at runtime only when they are required.

3 Things to Look for

Regardless of the tools used in a development pipeline, protecting credentials and API keys from compromise is critical. Simply put, secrets must exist outside of the source code. When considering a secrets management solution, there are three things to look for:

• A flexible deployment model, whether on-premises, natively in the cloud or any hybrid/multi-cloud combination.
• A solution secured in a way that goes beyond a simple key-value store.
• The ability to connect to other applications and services through open standards such as OAuth, OpenID (SAML), LDAP, Trustworthy JWT and PKI.

A secrets management strategy that takes these factors into account maximizes an organization’s opportunities for success. And with the DevOps model as prevalent as it now is, it’s absolutely vital for teams to do so to significantly reduce the likelihood of breaches and ultimately improve business agility.