There’s always a balancing act when it comes to building and deploying cloud-native applications in environments like Amazon Web Services (AWS). The whole point of moving production to the cloud is that developers can move faster than ever before, innovating and shipping new features on a daily basis. But that same speed can be an organization’s downfall if development outpaces security processes and accidentally exposes secrets or other credentials to potential attackers.
On the one hand, you’ve got 71% of organizations developing and deploying cloud-native apps, according to the Enterprise Strategy Group’s (ESG) 2023 Technology Spending Intentions Survey. On the other hand, 70% of organizations from another ESG report believe they have more than 50 secrets embedded just in their Git repositories, and 31% experienced a cybersecurity incident where secrets were stolen from a source code repository. Hard-coded secrets or secrets that aren’t properly rotated or revoked can become vulnerabilities that cyberattackers can exploit to gain access to an organization’s critical systems and resources.
Exposure of secrets, whether hard coded or compromised, can have a massive impact on the business. For example, in the recent breach of CircleCI, a continuous integration/continuous deployment (CI/CD) tool, the attacker stole the identity of an employee with privileges to create production access tokens. The attacker was able to exfiltrate data that included customer environment variables, tokens and keys, which could be used to gain access to customer systems. That led to impacted customers having to rotate all secrets stored on CircleCI, a potentially labor-intensive process if they do not have a centralized secrets management solution. Beyond the risk of a potential breach, impacted organizations spent time and resources that could be dedicated to other tasks on quickly revoking access and updating keys across their environments.
Who Owns Cloud-native Secrets Management?
So we know secrets management is a critical task, especially when working in cloud environments like AWS. AWS now has a native tool, AWS Secrets Manager, that many developers use to store application secrets.
It’s not fair or effective to put the burden of securing secrets on solely the developers’ shoulders. They’re trained in building and deploying applications, and their performance is evaluated on how well (and how fast) they can accomplish those projects. Securing secrets, maintaining least privilege access and other security principles aren’t traditionally their responsibility, and expecting them to focus on these security tasks instead of their development priorities can lead to production delays. If different project teams are all managing secrets for their project separately in multiple vaults (or multiple instances of AWS), it can be hard to get visibility, apply consistent policies and audit access across projects and accounts. All that makes it harder to respond to security events like the CircleCI breach when they happen.
A better solution is to have security teams handle secrets management across the enterprise, including for cloud-native applications. However, this can’t be at the risk of slowing developer velocity. Security processes that require code changes or changes to developer workflows will inevitably introduce delays and create frustration for cloud-native developers who need to move fast to meet business directives. Instead, security teams need a way to manage secrets for cloud-native applications in a way that is seamless for developers and meets them where they are (i.e., AWS), rather than trying to force a solution that slows them down or adds more work to their plates.
It’s a balancing act. Security teams want to centralize secrets management across all projects and accounts. Meanwhile, cloud architects and developers want to meet security policies without changing their existing processes by continuing to use native tools such as AWS Secrets Manager.
What Makes an Effective Cloud-Native Secrets Management Solution?
To better manage secrets for cloud-native environments like AWS, security teams need a solution that’s easy to use and leverages existing workflows, processes and tools. That makes it easier for developers to incorporate in their day-to-day operations and doesn’t place undue stress on the security teams trying to manage a large volume of secrets.
An effective secrets management solution for cloud-native environments provides six key benefits:
- It provides visibility, control and management over all secrets across projects and accounts through a single pane of glass, mitigating vault sprawl across multiple AWS instances and projects.
- Management, rotation and synchronization of secrets is simplified in a way that is transparent to developers, so critical functionality isn’t interrupted.
- Security teams can easily find and manage secrets across existing instances of their native cloud secrets management tools like AWS Secrets Manager.
- The developers’ preference for choice is fulfilled, as they can maintain their native user experiences with AWS Secrets Manager.
- Automatic rotation of secrets with cloud-native secrets increases operational efficiency for both security and developers (think of how much time and effort this would save in the event of a security incident like CircleCI’s recent breach).
- Transitioning workloads to AWS is accelerated by enabling the same security policies to be enforced across hybrid and cloud environments.
With a centralized solution that works with native cloud secrets managers instead, security and developers can balance their needs and deliver secure, well-built applications for their organizations. The right solution can help security teams enhance secrets management for AWS-based applications and help mitigate risk.
To learn more, read the analyst report from ESG’s Jack L. Poller, “Enhancing Secrets Management for AWS Applications.“
