Introduction to Cloud-Native Secrets Management
Challenges of Secrets Management
Over the last several years, a massive transition from on-premises to the cloud is taking place, resulting in a significant increase in the adoption of Cloud-Native practices and technologies by many enterprises across various market verticals.
The Cloud-Native eco-system encompass domains such as scheduling & orchestration (i.e. Kubernetes, Docker Swarm and Mesos), coordination & service discovery (i.e. etcd, Consul), host management (i.e. Chef, Puppet), security images (i.e. Aqua, Twistlock) and vaults (i.e. Hashicorp and Conjur).
Cloud-Native methodologies such as DevSecOps, continuous delivery, containers and micro-services are widely adopted and pushed by developers globally, as they are an essential building block in the digital business revolution — allowing enterprises to deliver applications rapidly in response to customer needs, with Cloud-Native solutions fueling a new engine of business growth.
The usage of cloud-native technologies requires use of various secrets — but it’s not the TOP SECRET classification you are most probably familiar from federal documents.
While cloud-native methodologies are highly advantageous and are instrumental to the digitalization of industries, they also pose significant security challenges for secrets management that we just cannot overlook, such as secrets proliferation, decentralization, lack of single secrets control and revocation, segmented visibility into secrets usage and the need to support both legacy IT and Cloud-Native environments. In addition, a cloud-native environment is software-defined by nature lacking architectural fit for hardware items like HSMs that used to provide the high level of trust so far.
Due to lack of proper security of the associated secrets, a hack or secrets leakage can potentially lead to a cyber-attack such as sensitive data, man-in-the-middle attacks, certificates and credentials theft, applications and users spoofing.
Protecting the Secrets in-use
Secrets are used by a broad range of applications ranging from legacy client-server to modern cloud native applications, and everything in between. Whatever software classification we might chose to look at, it being On-Premise/PaaS/IaaS/SaaS, coding language, compiler type, database sort, etc., every type of application needs to use miscellaneous secret types. A basic security requirement from these applications is to protect sensitive information like SSI or PII, and to securely authenticate for using a restricted resource, for example.
When a development team is building an application, they typically have to work with a variety of secrets such as database credentials and session keys. Applications access and use secrets in several instances, yet maintaining the security of secrets remains problematic. For example: hard-coded into the source code, entered via the command-line, obtained from a configuration file, received from environment variables, via user-provided services or by mounted volumes.
As many start to realize the damaging potential of a major security breach, different set of vault-like tools begin to emerge in the Cloud-Native eco-system. Logical vaults, as their physical predecessors, securely store the secrets while within the vault. They encrypt the data while at rest within the vault as well as using TLS for encrypting the secret while being transferred from the vault to the application.
Although utilization of such tools is far better than simply coding the secret into the source code, severe security implications arise from the use, as we’ll exemplify below.
When an application needs to use a certain secret stored within the vault (e.g. connection strings to a database containing sensitive pricing and revenue information for a financial analysis), it first has to authenticate itself with the vault by providing proper credentials (typically just username and password).
Once the access request is authenticated by the vault it reads the secret data from its storage and decrypts it with a key stored on the same storage, or rarely in external HSM. After decrypting the secret, the vault provides it the application in a secure manner via TLS as plain text. Therefore, once out of the vault, the secret that we worked so hard to protect within the vault and in the transit process to the requesting application, suddenly available as clear text, and can be harvested, opening an easy and lucrative attack surface for the potential adversary.
This is a major security issue, with a broad effect on the Cloud-Native industry, as cryptographic keys, credentials and secrets are not strongly secured and exposed when in-use. It strongly contrasts with private keys and credentials in traditional environments that are typically secured in hardware like HSM/TPM, especially in medium to high trust scenarios. This broadly practiced modus operandi opens a possibility for a skilled hacker working for a crime syndicate or rogue state to intercept all secrets being used by the Cloud-Native applications. The security implication of revealing such secrets ranges from the relatively low impact of an attacker revealing a username and password for a low importance system, rising with gaining access to admin credentials, API tokens, leaking personally identifiable information, harvesting private encryption keys, and lastly obtaining biometric identification information (i.e. fingerprint or iris scan), that is impossible to revoke, and the impact of revealing it is life-long.
How to identify containers?
Containers and microservices are growing in popularity as the means to implement applications in the cloud. Microservices are independent components with specific functions that form modular building blocks for cloud applications. They embody the agility, scalability, reusability and resiliency features of the cloud. Each microservice can be deployed, modified or removed without interrupting the other microservices, and lifecycle management is handled by fully automated deployment tools.
Containers are lightweight packages that contain application software and associated libraries that can be run on top of any computing platform sharing an operating system. Containers provide an ideal environment for microservice implementation in terms of speed, management, and lifecycle, and can solve most of the resource efficiency problems in the cloud.
Containers and microservices, with all their benefits, create many more moving parts and introduce new vulnerabilities that can be exploited by hackers. Protection of cloud-native applications requires new container security measures to prevent, intercept and mitigate such attacks.
An often overlooked aspect of container security is container identity and authentication, which is essential to achieving trust. Containers must be trusted not only because they comprise the software that powers business applications, but also because they may have access to sensitive data and other applications.
Without a proper process of container authentication based on a strong identity, the applications built on containerized infrastructure are vulnerable to a new range of attacks. To get a picture of how significant container identity is, imagine a container with malicious code masquerading as a legitimate container with a microservice that analyzes confidential financial data, for example. We wouldn’t want to allow sensitive resources, such as customer’s database, to be accessed by containers that are weakly identified or not at all.
As opposed to traditional monolithic applications running on full-stack platforms, the lightweight and short-lived containers that make up cloud-native applications require new methods of implementing and managing identity. There is a need to address and solve the following challenges — root of trust, segregation of identity credentials, source of entropy and lifespan.
A few tactics are in use today to create container identity and control access such as placing the identity in the image, pushing identity during container creation or labels-based identity. Using cryptography we can overcome the shortcomings of the existing practices, creating strong identity and authentication on a per-container, per-pod or per-service level with proven PKI mechanisms, that are not prone to identity theft and cloning.
Summary
Cloud-Native is transforming application development and allow us to achieve the true benefits of the cloud. But without building a strong security foundation that matches the level of security we’ve achieved in traditional IT environments, we are putting our core business assets at risk. With applications now broken down into small fast-moving and highly distributed parts, the attack surface grows significantly, and it’s essential to assure identity of each of these parts and protect the secrets they contain to prevent future attacks.
