Zero-Trust for Next Generation Clouds
Take a look at some of the approaches and best practices that companies are using to implement zero-trust policies for their cloud architectures.
Join the DZone community and get the full member experience.Join For Free
Next-gen clouds mean modern digital cloud architectures that are built using open-source software stacks that are part of the Cloud Native Computing Foundation (CNCF). Zero Trust is a security model that assumes any network is insecure and cannot be trusted and access to any application or service is dependent on the device and user credentials. This allows an individual or employee to access any system on any network provided the device and credentials are presented.
Google shared an influential whitepaper, “BeyondCorp – A new approach to Enterprise security” in 2014 which provided a roadmap for what they were doing to flip their internal IT systems onto the internet and move to a zero-trust model.
How Is This Different from Today?
The distributed nature of cloud-native computing architectures means workloads are running in different locations and networks. And often they are running across different clouds and on-premise as well.
The old model of trusted networks that rely on perimeter security controlled by firewalls is based on the flawed assumption that the attacker is coming from the outside. If the attacker comes from the inside, then the whole trusted perimeter network model falls apart. Security architectures have evolved to include micro-segmentation — a fancy world for SDN, but this isn’t without its own management complexity to deploy and operate. Software-defined firewalls seem to be a better solution which imposes rules on the edge and use LB/NAT translation and tie identity to the source IP address.
In today’s world where more and more cloud-native systems will be deployed on de facto container-managed platforms like Kubernetes, a new solution is badly needed.
Who’s Doing What?
Tigera is a company that has recognized the outdated security models of using the IP address as the main source of identity which doesn’t work in a dynamic and ephemeral environment. Tigera’s product Calico adopts the principle of Zero Trust Networking by abstracting the network by not referencing IP addresses. Again, it builds trust by building multiple sources to generate identity data, for example, cryptographic identity, network policy, K8 labels, and namespace, etc. They build multiple levels of policy enforcement models to get to the pod.
A network policy basically allows two applications to interact regardless of location, from the same data centre, or in separate clouds. It can even secure network access to/from Kubernetes and between Kubernetes pods in the same across multiple clusters and with services outside like AWS DynamoDB.
Aporeto is another company that takes a different approach by creating a database of application IDs, these application IDs provide a unique digital fingerprint to abstract the network and provides just-in-time privileged access management.
Many companies are taking a holistic view of zero trust models and trying to address a variety of problems that start from end user devices to multi-hosted hybrid cloud environments to specifically locking down containers deployed in Kubernetes.
WSO2 and Forgerock are taking another different approach with the idea of a microgateway, which is essentially is a proxy that sits very close to the microservice to enforce and control policies – this idea is similar with a sidecar pattern like Istio.
From this it would appear that there are different interpretations of what we mean by zero trust given the scope. Current initiatives focus on context-aware state of the user device and their access to applications anywhere to network abstraction and sophisticated means of generating unique service identities. This, however, is still not enough and must include code provenance.
A Reference Architecture for Zero Trust in a Cloud-Native World
A 9-Step Roadmap to Zero Trust in a Cloud-Native World.
Unless you are a start-up working in a greenfield environment, an enterprise would find themselves at different levels of maturity to get them to a zero trust cloud-native architecture. It largely depends on how far their existing digital architecture has evolved to date.
- Most digital projects are used to working with GitHub and GitLab repositories – but moving to GitOps requires teams to really adopt a declarative approach to how code is pushed. Tooling like Weaveworks Flux helps to achieve the necessary deployment from Git into Kubernetes.
- As mentioned earlier, zero trust means taking a shift-left approach to security and expanding into DevSecOps and CISO. Security operations cannot operate in a silo and that means security teams must leave behind traditional ways of working and tooling and given important to code provenance.
- Most companies are only now learning the complexities of managing and securing Kubernetes.
- Of the three sidecar implementations mentioned, Istio appears to be a de-facto standard in Kubernetes given its ability to control traffic, security, permissions, and observability but it’s the most complex to deploy.
- Service identity would need to be implemented using certificate-based mTLS (mutual transport layer security).
- Existing API and microservices architectures would need to be rearchitected to implement a service mesh design.
- Existing security solutions that today have an API gateway would find their role would eventually become redundant.
- Existing API identity and access management solutions with customer handlers would also become redundant.
- For those who have already deployed Kubernetes their existing Kubernetes RBAC API would need to be migrated.
All these are challenges that would need to be addressed for an enterprise to then deploy a zero-trust based architecture in a cloud-native architecture. Challenging though it may appear, it is very clear that this approach is underpinned on well-founded principles that will scale.
Addendum 1: Kubernetes
Implementing Kubernetes is not easy, because Kubernetes itself is left open and the expectation is placed firmly on the engineers to secure it by the software layer. By default, your cluster is visible on the internet, and there are hackers that use tools like Shodan to look for well-known Kubernetes ports. The Kubelet API, used by Kubernetes to manage containers on individual nodes and in some clusters, is available unauthenticated. Another possibility is where the Kubernetes RBAC is not setup which allows someone to gain access to a container and then take control of all containers within the cluster. The Centre of Internet Security (CIS) has provided guidance even on how to lock down the Kubernetes cluster in a managed solution like AWS EKS.
Addendum 2: “Beyond” BeyondCorp
By Google’s own admission they did not go far enough with the “BeyondCorp” initiative and recently released a new white paper called “BeyondProd” in Dec 2019, the writer was encouraged that the whitepaper is consistent with this article.
Opinions expressed by DZone contributors are their own.