As we move further into the Fourth Industrial Revolution, we are seeing the shift from cloud-native and hybrid cloud as an option, to the modus operandi. There is a significant difference between gearing your environment to handlecloud 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.
Traditional security approaches can’t keep pace with modern environments and often fall short as the development landscape evolves organically into the digital age. Therefore, new approaches are needed to secure this new development paradigm; security that runs on virtual machines, containers and, largely, Kubernetes.
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 lingering Shadow IT, missed malware and blind spots.
Simply put, there are no more physical boundaries to build a wall around. 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.
Requirements of a cloud native security approach
To remedy issues that arise during the transformation from traditional to modern environments, new capabilities must be sewn into our existing security architecture. Etiher that, or the architecture must be overhauled and rebuilt completely. However, your organization chooses to get from point A to point B, your cloud native security solution should be architected 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, identitycould 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 control plane 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.
Zero Trust with cert-manager, Istio and Kubernetes
Machine identity management 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. Venafi TLS Protect for Kubernetes is a solution built for Kubernetes and OpenStack environments that utilize cert-manager to manage this influx of certificates.
Developed by the Venafi experts from Jetstack, 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.
Cover every cluster with ease and efficiency.
Related posts