Traditional Security Won’t Cut It for Secure Cloud-Native Applications: Here’s Why

The risks of securing cloud-native with traditional security measures

Traditional security methods such as firewalls, VPNs, and other perimeter-bound approaches were built for monolithic architectures and have not scaled well with virtualization. There are several problems in these approaches.

They lack visibility – in an environment with multiple platforms, integrations, vendors, and technologies, a lot can fall through the cracks. Scanning the network is more complex than it used to be, and technologies that work across one solution may not work across another, resulting in Shadow IT, missed malware and blind spots.

With the physical perimeter obsolete, the security solution needs to be as agile as the environment itself, or it becomes useless. Traditional solutions were not built to follow millions of microservices and virtual machines around an enterprise as DevOps-driven, dynamic applications are built to do. And this is to say nothing of the expensive nature of traditional security protocols, their difficulty scaling or their dependency on large IT teams that are often in short supply.

Therefore, a data-centric, operation-centric or identity-centric approach is needed to fully secure applications at scale in the cloud. For such, we may look to methods like Modern Authentication, data encryption, throughput security, MFA and machine identity protection.

Sponsorships Available

Sponsorships Available

Sponsorships Available

Requirements of a cloud-native security approach

To remedy these issues, new capabilities must be sewn into our existing security architecture, or the architecture must be overhauled and rebuilt completely. However, you get from point A to point B, your cloud-native security solution should be able to do the following, as suggested by IBM:

• Authenticate personnel. Anyone who accesses your cloud resources, from developers to administrators, must be authenticated and authorized securely. Although the classic perimeter no longer exists, identity could be said to be a frontier of the new perimeter, and must be defended as such.
• Authenticate applications at the microservices level. Applications must be authorized and authenticated wholesale as well as on the microservices level.
• Isolate and protect cloud deployments. This solution should be able to provide network isolation and secure connectivity for your cloud solutions.
• Protect against DDoS attacks and other vulnerabilities. To protect against vulnerabilities, a complete asset inventory (and therefore complete asset visibility) is required. Expired certificates present a persistent and easily exploitable threat.
• Isolate and separate critical components at the memory, process and application level.
• Provide gapless data protection. Data should be protected (and that can mean encrypted) at rest and in transit. Provisions should be made so that while not encrypted, cloud-based data is still protected in use.
• Automate vulnerability scans. Considering cloud-based architecture carries myriad microservices, containers and VMs, there will certainly be at least as many machine identities. Your solution should automatically scan for vulnerabilities such as expired or unaccounted for certificates, as well as patches, updates and new releases.
• Log API calls. Have a way to gather, store and access all cloud API calls for the purposes of compliance and audits.
• Provide one central management dashboard. A “single pane of glass” is becoming less luxury and more necessity as cloud applications proliferate and expand the attack surface. Multiple dashboards for multiple areas of your enterprise not only slow down response time but fail to provide a full view of your security posture in context.

Machine Identity Protection for Kubernetes

As microservices, containers and virtual machines expand in the cloud, so does the number of TLS certificates and the need to manage them to maintain security. Jetstack Secure is a solution built for Kubernetes and OpenStack environments that utilizes cert-manager to manage this influx of certificates.

Developed by the Jetstack team at Venafi, cert-manger provides full visibility into each cluster, allowing you to detect poorly implemented security configurations and monitor for ingress. Instead of waiting for threats to come through the perimeter, you can proactively hunt for them within your cluster.

As TLS certificates are found everywhere within Kubernetes, not simply at entry and exit, an effective certificate management tool is necessary to keep your cloud-based applications safe maintain a zero trust environment in the cloud. Learn more about securing Kubernetes in the cloud here.

Related Posts

• How to Achieve Fast and Secure Continuous Delivery of Cloud-Native Applications
• Configuration Drift for Cloud-Native Machine Identities
• The Risks of not Knowing How Many Kubernetes Ingresses your Organization Has

Cloud-native has arrived. But there is a significant difference between gearing your environment to handle cloud applications and making your entire ecosystem run on the cloud. The same differences exist for securing it.

The cloud-native workload is based on several elements: microservices, containerization and the DevOps methodology. New approaches are needed to secure this new development paradigm that runs on virtual machines, containers, and largely, Kubernetes.

“>