ZeroTrust security does not rely on perimeters to define trust instead requires that all clients originating requests need to be authenticated & authorized
Introduction
In the current world, a myriad of different businesses is going digital, increasing largely the number of services, applications, data, and workloads that are reaching cloud computing platforms. With the crescent availability of distributed services and business facilities geographically distributed that need to access corporate applications and data, defining a security perimeter has become an unfeasible task.
Zero trust security does not rely on perimeters to define trust but instead requires that every client originating a request needs to be authenticated and authorized before having granted access to corporate workloads.
This granular security control that came to help on the reduction of attack surfaces, assuring the minimal necessary privilege for the consuming actors and avoiding unauthorized lateral movements, is defined as the Micro-Segmentation model.
In this post, we are going to explain how Accuknox implements an identity-based micro-segmentation model that provides secure access to workloads using JWT tokens managed by an external identity provider.
Conceptual Model
In a common scenario, an enterprise asset can be exposed to be remotely accessed by external actors like end-users, other applications or any other entity that needs to request information from workloads. To perform that with a reduced attack surface, the ZTA (Zero Trust Architecture) points out that the enterprise may choose to implement host-based micro-segmentation using software agents [1]. In this model, each individual request that has a secured endpoint as a destination needs to be dynamically scrutinized in order to grant or deny access based on the identity provided by the source.
Cilium Network Policies
At AccuKnox, Cilium has helped us to implement a micro-segmentation model based on network policies [2]. In order to establish trust and authorize access to specific endpoints, we extended the Cilium Network Policy (CNP) in a way that through policy manifests, any individual workload can be secured by making use of requests authorization powered with JSON Web Tokens (JWT) [8].
As Cilium makes use of Envoy as it’s host proxy for enforcing HTTP and other L7 policies [3] we leveraged Envoy’s JWT Authentication filter [4] to implement requests authorization based on identities generated by third-party identity providers.
Let’s say that a client (e.g. web browser) wants to access a web server inside a secured cluster, the life of the request starts when the client requests from a supported identity provider, one JWT token for a set of audiences [9]. This token is then used by the client to issue the actual request. With the correct policy enforced, Cilium will redirect the incoming request to Envoy where the JWT Authentication filter will fetch JSON Web Key Set (JWKS) [10] from the identity provider to authenticate JWT tokens and finally allow or deny the access (authorization) to the intended endpoint.
The restrictions imposed by implementing micro-segmentation for a particular k8s cluster can be now enforced by applying an ingress security policy. The policy is crafted based on the matchJWT object's specification, which was introduced as an extension to the already existing HTTP L7 policy rule. The following fragment shows an example:
CNP fragment showing matchJWT object
This policy configures Envoy’s filter to authorize requests destined to port 8080 of any selected endpoint and contains a valid JWT token provided by Auth0 provider [6] for a couple of audiences.
Client Identity
As a belief that identity is a foundational element to provide authentication and authorization on a zero-trust platform, the use of the micro-segmentation solution in addition to robust identity management plays an important role in the challenge of constantly reducing attack surfaces while keeping the Principle of Least Privilege [7]. While using an identity provider that permits authenticate JWT tokens with signing algorithms is definitively a strong approach, this model used by Accuknox also enables the usage SPIRE/SPIFFE identity solution [5] as an identity provider, offering then a complete microservices aware solution for cloud-native applications built over Zero Trust platforms.
How To
To give you a glimpse of how this model works in practice, we are going to guide you through this tutorial that will expose a simple test scenario to evaluate the micro-segmentation feature.
Create Target Workload
The first step to test a micro-segmentation basic scenario is to create the workload that will be secured with the cilium network policy.
kubectl apply -f test/k8sT/manifests/simple-http-test-server.yaml
simple-http-test-server.yaml
kubectl get pod -A -o wide
Now we have a running server lets poke it:
curl -I 10.11.0.232:7070;echo
After this step, we have created a functional web server that is accepting requests from any client. Now we want to secure this workload making it trust only requests received from a recognized client identity.
Micro-Segmentation Policy
In the policy sample below, we are specifying a Cilium Network Policy that selects the target endpoint using the label component: webserver, the same used to create the web server POD. We also want the specified rules to be applied to network traffic destined to TCP port 7070. We created a test account on Auth0 [6] and used that in the policy as can be noted when we select the supported identity provider with provider: AUTH0 attribute set the provider URI with issuer: "https://dev-8as2ijf5.us.auth0.com/" and also configure the URL for the JWKS fetching in jwksUrl: "https://dev-8as2ijf5.us.auth0.com/.well-known/jwks.json". For last, we will authorize only requests that contain JWT tokens issued for 2 audiences only, Thales-accuknox-1st and Thales-accuknox-2nd.
client-identity.yaml
Figure 6 - Let's now apply the policy and get it enforced:
Kubectl apply -f test/k8sT/manifests/client-identity-yaml
Figure 7 - micro-segmentation cliente-identity policy enforced
Now, with the policy enforced, we repeat the same test as before. As expected, the request is NOT AUTHORIZED (Status 401), because we don’t use a required JWT token on the request. Note that the response is sent to the client by the Envoy proxy
Figure 8 - Jwt is a missing response sent by Envoy
Finally, we want to try using a valid token generated by Auth0 API:
Figure 9 - Request authorized with valid JWT token
Cool! The request was received by Envoy filter, the token was then authenticated using the fetched JWKS and the audience verified and finally, the request was delivered to the actual workload running the web server while the client got its expected response.
PoC
The practical usage of the policy is as straightforward as shown in the HowTo above, but also on this feature video. The objective here is to demonstrate how the authorization mechanism acts on an arbitrary cluster enabling the desired micro-segmentation discussed in this post.
Conclusion
It would now be possible for Accuknox customers to put Authorization rules such that only certain clients/users would be allowed access to a service bringing granular security to cloud-native applications. In practical terms, we are enabling the fundamental pillar for Zero Trust Architecture which is the Micro-Segmentation model.
References
[1]https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
[2]https://docs.cilium.io/en/latest/concepts/kubernetes/policy/#k8s-policy
[3]https://github.com/cilium/proxy
[5]https://accuknox.com/blogs/workload-identity-for-network-security-with-spiffe/
[7]https://accuknox.com/blogs/kubernetes-workload-identity/
[8]https://jwt.io/introduction
[9]https://www.rfc-editor.org/rfc/rfc7519#section-4.1.3
[10]https://auth0.com/docs/security/tokens/json-web-tokens/json-web-key-sets
Now you can protect your workloads in minutes using AccuKnox, it is available to protect your Kubernetes and other cloud workloads using Kernel Native Primitives such as AppArmor, SELinux, and eBPF.
Let us know if you are seeking additional guidance in planning your cloud security program.
Read more blogs from Cloud Security Category here.
