We’re living in a cloud-native world, and the tools and strategies that worked in the pre-cloud era often no longer suffice. That is certainly true of secrets management.
Keep reading for an overview of what the shift to cloud-native means for secrets, and how organizations can adapt their secrets management strategies for cloud-native environments.
What is cloud-native?
Sometimes I hate the term cloud-native, because it lacks a very specific definition (even by the standards of tech buzzwords, which is saying a lot). Ask different people what cloud-native means and you’ll get different answers. To some, it’s basically a generic term for anything that runs in the cloud. To others, it’s about certain technologies associated with the Cloud Native Computing Foundation, such as Kubernetes. For others still, it’s more or less a synonym for DevOps.
For the purposes of this article on cloud-native secrets management, however, we’ll define cloud-native as an IT strategy oriented around the following:
● Continuous delivery of software applications (which hinges on speed and scalability in deployment and updates).
● Flexible, distributed application architectures (which are often based on microservices designs).
● Scalable, software-defined infrastructure that changes rapidly as nodes, containers, and other components spin up and down.
● A heavy reliance on API-driven services to connect distributed applications and infrastructure together.
Cloud-native secrets management challenges
In several ways, secrets management strategies designed before the cloud-native era don’t work in cloud-native environments. Here’s why.
Secrets management must be automated
When applications are deployed as monoliths on static on-premises services, it’s easy enough to manage secrets by hand. Addresses and hostnames are static. There are few or no APIs, so you mostly need to worry only about passwords, and not other types of secrets. And there are just fewer moving pieces overall within the environment that issue authentication and authorization requests.
In cloud-native environments, however, this is not the case. There are many more secrets to manage. The addresses of services and infrastructure components change constantly, and secrets need to change with them.
For these reasons, cloud-native environments require highly automated secrets management. You can’t manage and share secrets manually when your environment consists of a dozen or more microservices hosted on a hundred containers spread across a large cluster of servers. Instead, you need to be able to configure secrets management policies in code to automate the way secrets are stored and shared.
You need to manage secrets of all types (not just passwords)
Before the cloud-native shift, most secrets were passwords. You might also have had some encryption keys in the mix, but API tokens were rarer because APIs did not play as central a role in connecting services.
In cloud-native environments, however, a variety of different types of secrets are used constantly. It’s not just humans logging into systems with usernames and passwords who rely on secrets; applications also use keys and tokens to authenticate and authorize. Secrets management tools and processes must therefore be able to support all types of secrets from a single location. Password managers or key management services aren’t sufficient for this purpose.
Secrets need to be centralized
By definition (at least, by the definition I like), cloud-native environments are distributed across disparate infrastructure. This architecture makes it hard enough just to keep track of all of your applications and infrastructure components. You don’t want your secrets to be spread widely across a variety of locations, too.
Instead, cloud-native secrets management must be centralized. Your entire organization’s secrets should be stored in one place. Secrets centralization makes it easier to enforce security best practices for secrets management. It also allows you to monitor secrets activity from a central vantage point, which is essential for detecting misuse of secrets (either by attackers, or by users who are simply not following best practices).
Conclusion
Thriving in a cloud-native world requires a new approach to secrets management that is oriented around automation, centralization, and comprehensive management of all types of secrets. That’s the only way to handle the demand for speed, scalability, and flexibility that cloud-native creates. Conjur is a great open source secrets management solution for cloud native deployments, it works with Kubernetes and OpenShift cloud native platforms in addition to other DevOps tools and cloud providers, it’s easy to get started with the Conjur quick start tutorial.
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 and related topics, join us on the CyberArk Commons discussion forum.
Chris Tozzi has worked as a journalist and Linux systems administrator. He has particular interests in open source, agile infrastructure and networking. He is Senior Editor of content and a DevOps Analyst at Fixate IO.