In the first part of the cloud-native blog series we introduced the various types of secrets that need protection in the cloud, the technical challenges and the business implications of security compromises. In the second part we deep-dived into current methods and gaps in securing secrets used by cloud-native applications. In this last part, we discuss the importance of container identity to cloud-native application security, the challenges and available solutions.
Securing The Building Blocks of Cloud-Native Applications
Containers and microservices are growing in popularity as the means to implement applications in the cloud. In a cloud adoption and security survey released by McAfee in 2017, 80% of respondents indicated that their organizations have started using containers.
There’s good reason for this trend: together, microservices and containers can break down nearly all the barriers to optimized cloud use.
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. For example, hackers can launch rogue containers or pods counterfeit with malware that execute remote code (as demonstrated 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 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.
Container identity and authentication help achieve several important security capabilities:
- Security – allowing identification of applications and services minimizes the available attack vectors open for the hacker, who may otherwise exploit weak identification schemes to gain easy access to guarded resources
- Privacy – lack of authentication based on strong identity can lead to severe compromise of sensitive data, such as confidential business information and personal information, breaching regulations like GDPR and HIPAA
- Audit – without having a proper identity management in place, the audit logs won’t contain the information required for accurate forensics needed for post hack analysis
Challenges in Implementing Container Identity
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. Following are some of the challenges we need to address:
| Traditional applications running on full-stack platforms | Cloud-native applications built with microservices running on containers | |
|---|---|---|
| Root of Trust | Platforms typically have a hardware root of trust, which provides the basis for trust in secrets, keys and certificates used to establish application identity. | Containers are platform agnostic and by design we cannot make any assumptions on the availability of a hardware root of trust on the host machine. |
| Segregation of Identity Credentials | Applications run on specific hardware (physical or virtual) and OS, with many options for segregating secrets, e.g. TPM, local disk. | Containers include only the application and stack fractions which are needed for the applications execution, with no good options for secret segregation built-in. |
| Source of Entropy | Have hardware based sources of entropy which can be used for creating unique identities (utilizing available randomness), individual to a specific machine. Virtual machine platforms like Amazon AWS have machine-based APIs for host-level identity, like IAM and KMS). | |
| Lifespan | Typically long lived, therefore allowing to store identity on the underlying server’s TPM. | Short lived, limits the ability to store a unique identity. |
Beyond the specific challenges of achieving strong identity and trust in a containerized environment, another challenge for organizations adopting containers is the integration with legacy IT – how can cloud-native systems (i.e. containers and dockers) securely access resources that are external to the cloud-native environment, and that utilize different identity and authentication schemes?
Current Practices and Their Limitations
A few tactics are in use today to create container identity and control access:
- Placing the identity in the image – One can argue that the most straightforward way to provide an identity is create the container with the identity token/string written in plain-text within the image. From a security point of view, the secret is written in plain-text in the source code, viewable by everybody that has access to it, which is an obvious malpractice. Additionally, containers are created in very large numbers, therefore either the access identity is the same for all containers (raising the question if this is a proper identity) or there is a need to create and manage millions of images.
- Push identity during container creation – Another option is to allow container orchestration & management systems (i.e. Kubernetes, OpenShift) to inject certificates or tokens during the container initialization. The problem is that this automated process is insecure: it can be hijacked as it provides the and prone to a DDoS attack on the identity provider.
- Labels based identity – Labels define which containers can access which resources, requiring a container to have the label of any secret it accesses. Labels allow to consult a predefined policy and authorize containers to receive secrets (i.e. PAL by Cloudflare). Containers and their labels must be bound together using code integrity tools, to confirm that a specific container hash maps.
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
Containers are transforming application development and allow us to achieve the 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 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 to prevent future attacks.
*Shameless Plug*: Be sure to sign up for our Cloud-Native LIVE Webinar – How to Securely Go Cloud Native, on Wednesday Feb 21st at 11 AM ET.
The post Introduction to Cloud-Native Secrets Management: Part III appeared first on Unbound.
