Hybrid App Secrets Management

Secrets Management for Hybrid Applications

Keeping secrets safe is quite an important aspect of managing an application. One that is often ignored until it’s too late. Almost all applications use secrets; right from legacy client-server monoliths to modern cloud-native applications that are microservice-based. Secrets refer to anything that grants access or authorization. With monoliths, in particular, authentication is pretty straightforward and relatively cheap with tried and tested security models. Not so for microservices and hybrid microservice architecture.

Hybrid microservice architecture refers to a setup where a part of your application is monolithic and the other part is microservice-based. This is becoming quite a popular approach as it feels “safer”; you don’t have to rebuild the entire monolith. You don’t have to manage a lot of microservices or worry about RPC, asynchrony or working across a dozen different code bases. The problem with this approach, however, is that security features like secrets management and IAM need to be carried out across both legacy IT, and microservice-based architecture.

Legacy key management

Managing secrets for monoliths isn’t a new concept and organizations have been managing secrets, multi-factor authentication, cryptographic keys and certificates for years, with the help of hardware encryption systems like HSM and TPM. There are also a number of key management products for legacy applications that manage secrets, encryption, and authentication. While these products do serve a purpose when it comes to monoliths, integration with microservices causes a number of security concerns.

The problem here is two-fold; the more obvious issue being legacy IT’s heavy dependence on physical or hardware-based protection that has absolutely no place in the context of cloud-native applications and microservice architecture. The other problem is that legacy key management solutions were built to manage secrets for human users and not machines, where service-to-service communication can often include thousands of machine-based identities that need to be managed with secrets.

Secret sprawl

One common factor between secrets in monoliths, and secrets in microservices, is the fact that they’re everywhere. In monolithic applications, secrets don’t just exist in application code and config files, but also in the form of environment variables, machine images, and database tables. Similarly, with microservices, each microservice module typically includes its own database and credentials, and as your system scales, so do your secrets, causing something that’s referred to as secret proliferation or secret sprawl.

This sprawl comes from the traditional “distributed” approach where each individual can access their own credentials, and secrets are confined to their operators. This manual approach not only lacks separation of access, but also a central repository to revoke or rotate secrets. Using this approach with microservices further complicates things; in addition to managing secrets for multiple developers, microservices require more specific credentials like passwords for clouds, repositories, and machine-users.

Centralized secrets management

Centralized secrets management is the first step to successfully tackling the problem of secret sprawl. When you centralize your secrets in one place like in a centralized repository, not only do you not have to worry about secrets lying all over the place, you also get access to additional capabilities. These include reliable API access to secrets, revocation, and rotation of secrets, as well as multi-level role-based access and full audit capabilities.

These auditing capabilities are critical in terms of visibility into secret usage and seeing exactly who accessed what and when. With centralized secrets management, you now have a single control plane for all your secrets, as well as a single point to protect and a single point for recovery and log information. Centralized secrets also make it a lot easier to manage, build governance and create more fine-grained access controls for more specific role-based access.

Hybrid secrets

Hybrid microservice architecture brings with it a couple of unique complexities like the fact that legacy key management has to now integrate and run alongside cloud-native solutions for secrets management. Not only does this create a duplication issue, but it is a considerable strain on resources, as well. Similarly, with monoliths that already have security modules in place for authentication, adding centralized access management could significantly increase the overall resource footprint and negatively impact performance.

The solution here is a more overall or “holistic approach” in the form of modern secrets management platforms that support integration with hybrid microservice applications. This means we need a platform that’s not only agnostic to hardware, but also to the cloud, resulting in the ability to manage secrets in a broader and unbiased manner. Additionally, we also need consistent and simultaneous management of both human and non-human credentials. CyberArk Conjur, Docker Secrets and HashiCorp Vault are good options for modern secret management platforms.

Dynamic secrets

Best practice dictates using temporary secrets that grant specific “role-based” access to secrets on a need-to-know basis so that if any particular password or key is compromised it can be revoked without affecting the credentials of the entire system. These are also referred to as dynamic secrets and are supported by a number of secrets management platforms like the ones mentioned earlier. Similar to containers, dynamic secrets are time-bound, ephemeral and only exist while they’re being read.

In conclusion, the hybrid application has become quite a popular approach since it’s a lot easier to first build a monolith and then slowly move on to microservice architecture. Organizations like Wunder Capital even claim it’s a lot easier to manage than microservice architecture. The tricky part, however, is managing security and secrets across a mix of legacy and cloud-native infrastructure in a reliable manner.

Join the Conversation on the CyberArk Commons

If you’re interested in this and other open source content, join the conversation on the CyberArk Commons Community. Secretless Broker, Conjur and other open source projects are a part of the CyberArk Commons Community, an open community dedicated to developers, engineers, cybersecurity researchers and other technically minded people. To discuss Kubernetes, Secretless Broker, Conjur, CyberArk Threat Research, join me on the CyberArk Commons discussion forum.ource: lakdskfnasdf.com